在dataguard备库上找回在主库上被错误的Drop/Truncate/Delete 掉的Table

前提:
- Standby Database Must be in Flashback database mode.
 - Time at which Drop/Truncate/Delete Table happened should be within the db_flashback_retention_target and all the flashback and archive logs should be available
 
 
在dataguard备库上找回在主库上被错误的Drop/Truncate/Delete 掉的Table

参考文章:
How To Recover From A Drop/Truncate/Delete Table Done On Primary Using Flashback On A Standby Database (文档 ID 958557.1)

主库:

[[email protected] ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Fri Jul 31 22:08:19 2015

Copyright (c) 1982, 2008, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select sysdate from dual;

SYSDATE
---------
31-JUL-15

SQL> show parameter format

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_format                   string      %t_%s_%r.dbf
nls_date_format                      string
nls_time_format                      string
nls_time_tz_format                   string
nls_timestamp_format                 string
nls_timestamp_tz_format              string
star_transformation_enabled          string      TRUE
SQL> alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';

Session altered.

SQL> select sysdate from dual;

SYSDATE
-------------------
2015-07-31 22:10:00

SQL> select count(*) from scott.test_tab_1 ;

  COUNT(*)
----------
      2566

SQL> truncate scott.test_tab_1 ;
truncate scott.test_tab_1
              *
ERROR at line 1:
ORA-03290: Invalid truncate command - missing CLUSTER or TABLE keyword

SQL> truncate table scott.test_tab_1 ;

Table truncated.

SQL> 

备库:

SQL> show parameter target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target                   integer     0
db_flashback_retention_target        integer     1440  ------->默认的设置,1440分钟,也就是一天。
fast_start_io_target                 integer     0
fast_start_mttr_target               integer     0
memory_max_target                    big integer 356M
memory_target                        big integer 356M
pga_aggregate_target                 big integer 0
sga_target                           big integer 0
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area  372449280 bytes
Fixed Size                  1313484 bytes
Variable Size             322962740 bytes
Database Buffers           41943040 bytes
Redo Buffers                6230016 bytes
Database mounted.
SQL> flashback database to timestamp to_date('2015-07-31 22:10:00','YYYY-MM-DD HH24:MI:SS');
flashback database to timestamp to_date('2015-07-31 22:10:00','YYYY-MM-DD HH24:MI:SS')
*
ERROR at line 1:
ORA-01153: an incompatible media recovery is active

SQL> alter database recover managed standby database  cancel;

Database altered.

SQL> flashback database to timestamp to_date('2015-07-31 22:10:00','YYYY-MM-DD HH24:MI:SS');

Flashback complete.

SQL> alter database open read only;

Database altered.

SQL> select count(*) from scott.test_tab_1 ;

  COUNT(*)
----------
      2566

SQL> exit

[[email protected] SBDB1]$ export NLS_LANG=american_america.AL32UTF8
[[email protected] SBDB1]$ exp system/oracle file=/home/oracle/test_tab_exp_0730.dmp tables=scott.test_tab_1

Export: Release 11.1.0.7.0 - Production on Fri Jul 31 22:20:03 2015

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in AL32UTF8 character set and AL16UTF16 NCHAR character set

About to export specified tables via Conventional Path ...
Current user changed to SCOTT
. . exporting table                     TEST_TAB_1       2566 rows exported
Export terminated successfully without warnings.
[[email protected] SBDB1]$

备库:

[[email protected] SBDB1]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Fri Jul 31 22:26:46 2015

Copyright (c) 1982, 2008, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  372449280 bytes
Fixed Size                  1313484 bytes
Variable Size             322962740 bytes
Database Buffers           41943040 bytes
Redo Buffers                6230016 bytes
Database mounted.
SQL> recover standby database;
ORA-00279: change 1156098 generated at 07/31/2015 22:10:03 needed for thread 1
ORA-00289: suggestion : /home/oracle/archive/SBDB1/1_100_884907736.dbf
ORA-00280: change 1156098 for thread 1 is in sequence #100

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change 1156325 generated at 07/31/2015 22:14:44 needed for thread 1
ORA-00289: suggestion : /home/oracle/archive/SBDB1/1_101_884907736.dbf
ORA-00280: change 1156325 for thread 1 is in sequence #101
ORA-00278: log file '/home/oracle/archive/SBDB1/1_100_884907736.dbf' no longer
needed for this recovery

ORA-00279: change 1156336 generated at 07/31/2015 22:15:03 needed for thread 1
ORA-00289: suggestion : /home/oracle/archive/SBDB1/1_102_884907736.dbf
ORA-00280: change 1156336 for thread 1 is in sequence #102
ORA-00278: log file '/home/oracle/archive/SBDB1/1_101_884907736.dbf' no longer
needed for this recovery

ORA-00279: change 1156346 generated at 07/31/2015 22:15:13 needed for thread 1
ORA-00289: suggestion : /home/oracle/archive/SBDB1/1_103_884907736.dbf
ORA-00280: change 1156346 for thread 1 is in sequence #103
ORA-00278: log file '/home/oracle/archive/SBDB1/1_102_884907736.dbf' no longer
needed for this recovery

ORA-00308: cannot open archived log
'/home/oracle/archive/SBDB1/1_103_884907736.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

SQL> alter database recover managed standby database disconnect from session;
alter database recover managed standby database disconnect from session
*
ERROR at line 1:
ORA-01153: an incompatible media recovery is active

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database recover managed standby database  using current logfile disconnect from session;

Database altered.

SQL>
时间: 2024-08-29 09:43:50

在dataguard备库上找回在主库上被错误的Drop/Truncate/Delete 掉的Table的相关文章

Oracle 11g Data Guard 物理备库快速配置指南(上)

缘起 最近做了10g和11g的物理备库配置实验,发现 Data Guard 其实很容易,但是缺少好文档.我是参考官方文档做的实验,觉得它写的不是很清楚的. Google 出来两个pdf文档,读了觉得比官方文档强很多.翻译下,也许会对某些朋友有用.翻译的同时我也好更熟悉下这两个文档.好久没翻译过英文了,可以顺便练练手. 原文档下载地址(墙外): Configure Dataguard 11gR2 Physical Standby Part 1 Configure Dataguard 11gR2 P

Oracle 11 g duplicate功能_复制dataguard备库

Qracle 11g duplicate功能 不用备份源库,通过网络复制出standby库 1.在standby上grid用户配置listener 注意是指定oracle用户的家目录: 监听状态: [[email protected] ~]$lsnrctl LSNRCTL for Linux:Version 11.2.0.4.0 - Production on 19-MAY-2014 18:46:15 Copyright (c)1991, 2013, Oracle.  All rights re

【原创】oracle ORA-01157 ORA-01110 DataGuard 备库 临时表空间报错

简要: 当查询数据库数据时,提示临时表空间异常,报错ORA-01157 ORA-01110,经过对数据文件处理后,已经解决此故障. 环境:Oracle 11g RAC For Linux 6,该库为DataGuard备库 1. 查询数据时报错,如下: ERROR:ORA-01157: cannot identify/lock data file 226 - see DBWR trace fileORA-01110: data file 226: '+DG_DATA02/racdb/blsp_te

11gR2 dataguard 备库文件损坏处理一例

延迟标记像极了线段树,不再多说. 区间反转在树伸展到位之后,也变成了简单的递归交换左右儿子. 愈发感觉到伸展树简直太漂亮了,伸展操作更是诱惑到不行 ,总之数据结构太有魅力了. 比较简单,就直接上模板了. #include <algorithm> #include <iostream> #include <cstring> #include <cstdlib> #include <cstdio> #include <queue> #in

DataGuard备库ORA-01196故障恢复一则

问题现象 在使用shutdown abort停DataGuard备库后,备库不能open,报ORA-01196错误. 具体如下: 发现一备库不能应用日志,查看备库日志没发现报错,怀疑是备库应用日志服务停止,于是尝试重启备库: 可能因为备库是读业务比较繁忙,在shutdown immediate关闭备库时等时间过长,于是使用了shutdown abort命令: 但后面在启动备库时发生报错,造成数据文件损坏,控制文件和数据文件的scn号不一致. --启动备库时报错 SQL> startup ORAC

oracle11g dataguard 备库数据同步的检查方法

概述: 一.环境 主库: ip地址:192.168.122.203 oracle根目录:/data/db/oracle SID:qyq 数据文件路径/data/db/oracle/oradata/qyq 归档文件路径:/data/db/oracle/archive' 备库: ip地址:192.168.122.204 oracle根目录:/data/app/oracle SID:qyq 数据文件路径/data/app/oracle/oradata/qyq 归档文件路径:/data/app/orac

ORACLE Physical Standby 级联备库搭建

搭建oracle 级联DG 现在db与dg1是一套DG ,在此基础上搭建级联备库: 数据库版本 11.2.0.4 db_name=prod db为主库,dg1为备库,dg2为级联备库:DB_UNIQUE_NAME DATABASE_ROLEdb primary 10.100.12.10 dg1 standby1 10.100.12.11 dg2 standby2 10.100.12.12 三个库的LOG_FILE_NAME_CONVERT,DB_FILE_NAME_CONVERT路径一致####

pgsql物理复制(pgsql 备库的搭建以及角色互换,提升)

结构图如下: Postgresql早在9.0版本开始支持物理复制,也称为流复制,通过从实例级复制出一个与主库一模一样的备库.流复制同步方式有同步,异步两种,如果主节点和备节点不是很忙,通常异步模式下备库和主库的延迟时间能够控制在毫秒级.物理复制只能复制整个实例. 逻辑复制也成为选择性复制,可以做到基于表级别的复制,选择需要逻辑复制的表,而不是复制实例上的所有数据库的表,10版本不支持内置的逻辑复制,通常使用第三方逻辑复制. WAL日志记录数据库变化,格式为二级制格式,尽管流复制都是基于WAL,但

oracle11g dataguard物理备库搭建

Dataguard 环境: 操作系统:Redhat6.4 Primary数据库: IP 地址:192.168.1.122 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_primary Standby数据库: IP 地址:192.168.1.123 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_standby (注:oracle数据库版本是11.2.0.1.0) 1.Primary端的配置 (1).检查数据库是否支持 Data Guard(企业版