级联DG
版本:11.2.0.4
12c之前是非实时级联DG：只有A库的 log Switch 之后，整个 log sequence 才会被传递到最终C库上。
12c之后支持配置实时的级联DG：以实时的模式将 redo 从B库传递到C数据库。因此在B数据库，Redo 的信息会在被写到 Standby Redolog 后立即传递到C库。
当前环境：A(gbkdb),B(gbkdbdg),C(gbkdbdr)
级联DG的规范配置如下
1、归档传输参数
此配置模式，A库和B库发生switchover也不会影响C库应用日志。
--主 A库：
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(gbkdb,gbkdbdg,gbkdbdr)' SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/gbkarch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=gbkdb' SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_dest_2='SERVICE=gbkdbdg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=gbkdbdg' SCOPE=BOTH SID='*';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=gbkdbdr VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=gbkdbdr';
ALTER SYSTEM SET fal_server='gbkdbdg' SCOPE=BOTH SID='*';
--DG B库：
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(gbkdb,gbkdbdg,gbkdbdr)' SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/gbkarch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=gbkdbdg';
ALTER SYSTEM SET log_archive_dest_2='SERVICE=gbkdb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=gbkdb';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=gbkdbdr VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=gbkdbdr';
ALTER SYSTEM SET fal_server='gbkdb' SCOPE=BOTH SID='*';
--级联DG C库：
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(gbkdb,gbkdbdg,gbkdbdr)' SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/gbkdrarch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=gbkdbdr';
alter system set fal_server='gbkdbdg','gbkdb';
2、convert参数
如果路径都一致，则可以忽略此步骤；也可以选择在搭建阶段手工restore，指定文件newname即可。
如果C库采用A库作为源端进行duplicate，则convert参数需要转换A库的路径；
db_file_name_convert='gbkdb','gbkdbdr'
log_file_name_convert='gbkdb','gbkdbdr'
如果C库采用B库作为源端进行duplicate，则convert参数需要转换B库的路径；
db_file_name_convert='gbkdbdg','gbkdbdr'
log_file_name_convert='gbkdbdg','gbkdbdr'
后期添加数据文件都转换A库的参数
如果转换配置错误，则C库的数据文件默认就加到与A库一致的位置，如果位置不能创建则会报错，处理方式如下：
Sat Mar 18 11:06:19 2023
Media Recovery Log /u01/app/oracle/gbkdrarch/1_137_1128704778.dbf
WARNING: File being created with same name as in Primary
Existing file may be overwritten
Errors in file /u01/app/oracle/diag/rdbms/gbkdbdr/gbkdbdr/trace/gbkdbdr_pr00_3749.trc:
ORA-01119: error in creating database file '/u01/app/oracle/oradata/gbkdb/tstest02.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 13: Permission denied
Additional information: 6
File #9 added to control file as 'UNNAMED00009'.
Originally created as:
'/u01/app/oracle/oradata/gbkdb/tstest02.dbf'
Recovery was unable to create the file as:
'/u01/app/oracle/oradata/gbkdb/tstest02.dbf'
Errors with log /u01/app/oracle/gbkdrarch/1_137_1128704778.dbf
MRP0: Background Media Recovery terminated with error 1274
Errors in file /u01/app/oracle/diag/rdbms/gbkdbdr/gbkdbdr/trace/gbkdbdr_pr00_3749.trc:
ORA-01274: cannot add datafile '/u01/app/oracle/oradata/gbkdb/tstest02.dbf' - file could not be created
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 4568905223
Sat Mar 18 11:06:19 2023
MRP0: Background Media Recovery process shutdown (gbkdbdr)
SQL> select file#,name from v$datafile ;
FILE# NAME
---------- ----------------------------------------------------------------------
1 /u01/app/oracle/oradata/gbkdbdr/system01.dbf
2 /u01/app/oracle/oradata/gbkdbdr/sysaux01.dbf
3 /u01/app/oracle/oradata/gbkdbdr/undotbs01.dbf
4 /u01/app/oracle/oradata/gbkdbdr/users01.dbf
5 /u01/app/oracle/oradata/gbkdbdr/ts_b.dbf
6 /u01/app/oracle/oradata/gbkdbdr/ts_c.dbf
7 /u01/app/oracle/oradata/gbkdbdr/gbkdbdrDB01.dbf
8 /u01/app/oracle/oradata/gbkdbdr/tstest01.dbf
9 /u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00009
9 rows selected.
SQL> alter system set standby_file_management=manual;
System altered.
SQL> alter database create datafile '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00009' as '/u01/app/oracle/oradata/gbkdbdr/tstest02.dbf';
Database altered.
SQL> alter system set standby_file_management=auto;
System altered.
SQL> select file#,name from v$datafile ;
FILE# NAME
---------- ----------------------------------------------------------------------
1 /u01/app/oracle/oradata/gbkdbdr/system01.dbf
2 /u01/app/oracle/oradata/gbkdbdr/sysaux01.dbf
3 /u01/app/oracle/oradata/gbkdbdr/undotbs01.dbf
4 /u01/app/oracle/oradata/gbkdbdr/users01.dbf
5 /u01/app/oracle/oradata/gbkdbdr/ts_b.dbf
6 /u01/app/oracle/oradata/gbkdbdr/ts_c.dbf
7 /u01/app/oracle/oradata/gbkdbdr/gbkdbdrDB01.dbf
8 /u01/app/oracle/oradata/gbkdbdr/tstest01.dbf
9 /u01/app/oracle/oradata/gbkdbdr/tstest02.dbf
9 rows selected.
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL>
级联DG B库failover情况测试
此情况需要闪回A库进行恢复，因为A库的SCN比B和C的都大， reset database to incarnation也不能改变数据库的已经增大的SCN。
如果A没有开启闪回，则需要重新恢复A库。
1、A库down机
SQL> shutdown abort
ORACLE instance shut down.
SQL>
2、B库failover
SQL> alter database recover managed standby database finish;
Database altered.
SQL> select database_role,OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from gv$database;
DATABASE_ROLE OPEN_MODE PROTECTION_MODE
------------------------------------------------ ------------------------------------------------------------ ------------------------------------------------------------
PROTECTION_LEVEL SWITCHOVER_STATUS
------------------------------------------------------------ ------------------------------------------------------------
PHYSICAL STANDBY READ ONLY MAXIMUM PERFORMANCE
MAXIMUM PERFORMANCE TO PRIMARY
SQL> alter database commit to switchover to primary with session shutdown;
Database altered.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=gbkdbdr LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=gbkdbdr';
System altered.
SQL> alter database open;
Database altered.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/gbkarch
Oldest online log sequence 1
Next log sequence to archive 3
Current log sequence 3
SQL> alter system switch logfile;
System altered.
SQL>
--B库化身
RMAN> list incarnation of database gbkdb;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 GBKDB 845494326 PARENT 1 24-AUG-13
2 2 GBKDB 845494326 PARENT 925702 29-DEC-21
3 3 GBKDB 845494326 ORPHAN 4568599459 13-FEB-23
4 4 GBKDB 845494326 PARENT 4568599516 13-FEB-23
5 5 GBKDB 845494326 ORPHAN 4568606764 13-FEB-23
6 6 GBKDB 845494326 PARENT 4568606764 13-FEB-23
7 7 GBKDB 845494326 PARENT 4568627631 13-FEB-23
8 8 GBKDB 845494326 PARENT 4568628222 13-FEB-23
9 9 GBKDB 845494326 CURRENT 4568952372 18-MAR-23
RMAN>
--B库日志
Sat Mar 18 12:24:24 2023
alter database recover managed standby database finish
Attempt to do a Terminal Recovery (gbkdb)
Media Recovery Start: Managed Standby Recovery (gbkdb)
started logmerger process
Sat Mar 18 12:24:24 2023
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Terminal Recovery timestamp is '03/18/2023 12:24:24'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 154 redo required
Terminal Recovery:
Recovery of Online Redo Log: Thread 1 Group 11 Seq 154 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/gbkdbdg/sredo11.log
Identified End-Of-Redo (failover) for thread 1 sequence 154 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 4568952371 time 03/18/2023 12:22:24
Media Recovery Complete (gbkdb)
Terminal Recovery: successful completion
Sat Mar 18 12:24:24 2023
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance gbkdb - Archival Error
ORA-16014: log 11 sequence# 154 not archived, no available destinations
ORA-00312: online log 11 thread 1: '/u01/app/oracle/oradata/gbkdbdg/sredo11.log'
Forcing ARSCN to IRSCN for TR 1:273985075
Attempt to set limbo arscn 1:273985075 irscn 1:273985075
Resetting standby activation ID 884647866 (0x34baa7ba)
Completed: alter database recover managed standby database finish
alter database commit to switchover to primary with session shutdown
ALTER DATABASE SWITCHOVER TO PRIMARY (gbkdb)
Maximum wait for role transition is 15 minutes.
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Sat Mar 18 12:24:33 2023
SMON: disabling cache recovery
Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/gbkdbdg/gbkdb/trace/gbkdb_ora_4783.trc
Standby terminal recovery start SCN: 4568952370
RESETLOGS after incomplete recovery UNTIL CHANGE 4568952371
Online log /u01/app/oracle/oradata/gbkdbdg/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/gbkdbdg/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/gbkdbdg/redo03.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 4568952369
Sat Mar 18 12:24:33 2023
Setting recovery target incarnation to 9
AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
Switchover: Complete - Database mounted as primary
Completed: alter database commit to switchover to primary with session shutdown
Sat Mar 18 12:24:44 2023
idle dispatcher 'D000' terminated, pid = (17, 1)
Sat Mar 18 12:25:25 2023
ARC1: Becoming the 'no SRL' ARCH
Sat Mar 18 12:25:48 2023
Archiver process freed from errors. No longer stopped
Sat Mar 18 12:25:48 2023
ALTER SYSTEM SET log_archive_dest_3='SERVICE=gbkdbdr LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=gbkdbdr' SCOPE=BOTH;
3、C库日志情况
C库无需处理，自动识别B库新的incarnation
--C库化身，自动应用与B库一致
RMAN> list incarnation of database gbkdb;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 GBKDB 845494326 PARENT 1 24-AUG-13
2 2 GBKDB 845494326 PARENT 925702 29-DEC-21
3 3 GBKDB 845494326 ORPHAN 4568599459 13-FEB-23
4 4 GBKDB 845494326 PARENT 4568599516 13-FEB-23
5 5 GBKDB 845494326 ORPHAN 4568606764 13-FEB-23
6 6 GBKDB 845494326 PARENT 4568606764 13-FEB-23
7 7 GBKDB 845494326 PARENT 4568627631 13-FEB-23
8 8 GBKDB 845494326 PARENT 4568628222 13-FEB-23
9 9 GBKDB 845494326 CURRENT 4568952372 18-MAR-23
RMAN>
--C库日志
Sat Mar 18 12:22:27 2023
RFS[2]: Possible network disconnect with primary database
Sat Mar 18 12:26:10 2023
RFS[8]: Assigned to RFS process 4934
RFS[8]: New Archival REDO Branch: 1131798273 Current: 1128704778
RFS[8]: Selected log 12 for thread 1 sequence 1 dbid 845494326 branch 1131798273
A new recovery destination branch has been registered
RFS[8]: New Archival REDO Branch(resetlogs_id): 1131798273 Prior: 1128704778
RFS[8]: Archival Activation ID: 0x34bb010c Current: 0x34baa7ba
RFS[8]: Effect of primary database OPEN RESETLOGS
RFS[8]: Managed Standby Recovery process is active
RFS[8]: Incarnation entry added for Branch(resetlogs_id): 1131798273 (gbkdbdr)
Sat Mar 18 12:26:10 2023
Setting recovery target incarnation to 9
Sat Mar 18 12:26:10 2023
Archived Log entry 28 added for thread 1 sequence 1 ID 0x34bb010c dest 1:
Sat Mar 18 12:26:11 2023
MRP0: Incarnation has changed! Retry recovery...
Errors in file /u01/app/oracle/diag/rdbms/gbkdbdr/gbkdbdr/trace/gbkdbdr_pr00_4864.trc:
ORA-19906: recovery target incarnation changed during recovery
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Sat Mar 18 12:26:11 2023
started logmerger process
Sat Mar 18 12:26:11 2023
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Media Recovery start incarnation depth : 1, target inc# : 9, irscn : 4568952371
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Waiting for thread 1 sequence 154 branch(resetlogs_id) 1128704778
Sat Mar 18 12:26:18 2023
Primary database is in MAXIMUM PERFORMANCE mode
RFS[9]: Assigned to RFS process 4976
RFS[9]: Selected log 12 for thread 1 sequence 3 dbid 845494326 branch 1131798273
Sat Mar 18 12:26:18 2023
RFS[10]: Assigned to RFS process 4978
RFS[10]: Selected log 13 for thread 1 sequence 2 dbid 845494326 branch 1131798273
Sat Mar 18 12:26:18 2023
Archived Log entry 29 added for thread 1 sequence 2 ID 0x34bb010c dest 1:
RFS[10]: Opened log for thread 1 sequence 154 dbid 845494326 branch 1128704778
Archived Log entry 30 added for thread 1 sequence 154 rlc 1128704778 ID 0x34baa7ba dest 3:
Media Recovery Log /u01/app/oracle/gbkdrarch/1_154_1128704778.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 154 at SCN 0x1.1054ae33
Resetting standby activation ID 884647866 (0x34baa7ba)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Log /u01/app/oracle/gbkdrarch/1_1_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkdrarch/1_2_1131798273.dbf
Media Recovery Waiting for thread 1 sequence 3 (in transit)
Recovery of Online Redo Log: Thread 1 Group 12 Seq 3 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/gbkdbdr/sredo12.log
Sat Mar 18 12:26:51 2023
RFS[9]: Selected log 13 for thread 1 sequence 4 dbid 845494326 branch 1131798273
Sat Mar 18 12:26:51 2023
Archived Log entry 31 added for thread 1 sequence 3 ID 0x34bb010c dest 1:
Sat Mar 18 12:26:51 2023
Media Recovery Waiting for thread 1 sequence 4 (in transit)
Recovery of Online Redo Log: Thread 1 Group 13 Seq 4 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/gbkdbdr/sredo13.log
4、A库尝试启动恢复为物理备库
--A库化身情况为8
RMAN> list incarnation of database gbkdb;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 GBKDB 845494326 PARENT 1 2013-08-24 11:37:30
2 2 GBKDB 845494326 PARENT 925702 2021-12-29 22:29:12
3 3 GBKDB 845494326 ORPHAN 4568599459 2023-02-13 14:53:01
4 4 GBKDB 845494326 PARENT 4568599516 2023-02-13 15:05:13
5 5 GBKDB 845494326 ORPHAN 4568606764 2023-02-13 16:54:05
6 6 GBKDB 845494326 PARENT 4568606764 2023-02-13 16:59:56
7 7 GBKDB 845494326 PARENT 4568627631 2023-02-13 17:03:11
8 8 GBKDB 845494326 CURRENT 4568628222 2023-02-13 17:06:18
RMAN>
--此时A和B都是主库，互传日志均报错16009
Sat Mar 18 12:44:14 2023
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
Sat Mar 18 12:44:14 2023
PING[ARC2]: Heartbeat failed to connect to standby 'gbkdbdg'. Error is 16009.
Sat Mar 18 12:44:16 2023
Thread 1 advanced to log sequence 159 (LGWR switch)
Current log# 2 seq# 159 mem# 0: /u01/app/oracle/oradata/gbkdb/redo02.log
Sat Mar 18 12:44:16 2023
Archived Log entry 672 added for thread 1 sequence 158 ID 0x34baa7ba dest 1:
[oracle@linux8 ~]$ oerr ora 16009
16009, 00000, "invalid redo transport destination"
// *Cause: The redo transport destination could not accept redo data because
// it was not a valid redo transport destination type.
// *Action: Verify that all redo transport destinations are either standby
// databases or downstream capture databases.
[oracle@linux8 ~]$
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 626327552 bytes
Fixed Size 2255832 bytes
Variable Size 234882088 bytes
Database Buffers 381681664 bytes
Redo Buffers 7507968 bytes
Database mounted.
SQL> alter database convert to physical standby;
Database altered.
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 626327552 bytes
Fixed Size 2255832 bytes
Variable Size 234882088 bytes
Database Buffers 381681664 bytes
Redo Buffers 7507968 bytes
Database mounted.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
--A库MRP应用日志报错，因为数据文件是孤儿化身
Sat Mar 18 12:58:21 2023
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (gbkdb)
Sat Mar 18 12:58:21 2023
MRP0 started with pid=28, OS id=23805
MRP0: Background Managed Standby Recovery process started (gbkdb)
started logmerger process
Sat Mar 18 12:58:26 2023
Managed Standby Recovery starting Real Time Apply
Warning: Recovery target destination is in a sibling branch
of the controlfile checkpoint. Recovery will only recover
changes to datafiles.
Datafile 1 (ckpscn 4568973958) is orphaned on incarnation#=8
MRP0: Detected orphaned datafiles!
Recovery will possibly be retried after flashback...
Errors in file /u01/app/oracle/diag/rdbms/gbkdb/gbkdb/trace/gbkdb_pr00_23811.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/u01/app/oracle/oradata/gbkdb/system01.dbf'
Managed Standby Recovery not using Real Time Apply
Recovery Slave PR00 previously exited with exception 19909
Completed: alter database recover managed standby database using current logfile disconnect
[oracle@linux8 ~]$ oerr ora 19909
19909, 00000, "datafile %s belongs to an orphan incarnation"
// *Cause: Either the specified datafile was restored from a backup that was
// taken during a period of time that has already been discarded by
// a RESETLOGS operation, or Oracle cannot identify which database
// incarnation the file belongs to. The alert log contains more
// information.
// *Action: Restore a backup of this file that belongs to either the current
// or a prior incarnation of the database. If you are using RMAN
// to restore, RMAN will automatically select a correct backup.
[oracle@linux8 ~]$
--此刻控制文件化身已经变为正常的9，但是数据文件SCN属于化身8之后的另外一个分支，属于孤儿数据文件:MRP0: Detected orphaned datafiles!
并且提示闪回可以尝试恢复，Recovery will possibly be retried after flashback...
RMAN> list incarnation of database gbkdb;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 GBKDB 845494326 PARENT 1 2013-08-24 11:37:30
2 2 GBKDB 845494326 PARENT 925702 2021-12-29 22:29:12
3 3 GBKDB 845494326 ORPHAN 4568599459 2023-02-13 14:53:01
4 4 GBKDB 845494326 PARENT 4568599516 2023-02-13 15:05:13
5 5 GBKDB 845494326 ORPHAN 4568606764 2023-02-13 16:54:05
6 6 GBKDB 845494326 PARENT 4568606764 2023-02-13 16:59:56
7 7 GBKDB 845494326 PARENT 4568627631 2023-02-13 17:03:11
8 8 GBKDB 845494326 PARENT 4568628222 2023-02-13 17:06:18
9 9 GBKDB 845494326 CURRENT 4568952372 2023-03-18 12:24:33
RMAN>
--A库SCN情况如下
SQL> set lines 200
SQL> col checkpoint_change# for 999999999999999999999
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
-----------
4568973957
SQL> select CHECKPOINT_CHANGE#,count(*) from v$datafile group by CHECKPOINT_CHANGE#;
CHECKPOINT_CHANGE# COUNT(*)
---------------------- ----------
4568973958 9
SQL> select CHECKPOINT_CHANGE#,count(*) from v$datafile_header group by CHECKPOINT_CHANGE#;
CHECKPOINT_CHANGE# COUNT(*)
---------------------- ----------
4568973958 9
--此时B库检查SCN
SQL> select STANDBY_BECAME_PRIMARY_SCN from v$database;
STANDBY_BECAME_PRIMARY_SCN
--------------------------
4568952369
--闪回A库到B库成为主库时候的SCN
SQL> select oldest_flashback_scn, to_char(oldest_flashback_time,'yyyy-mm-dd HH24:mi:ss') oldest_flashback_time from v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME
-------------------- ---------------------------------------------------------
4568848690 2023-03-17 10:15:36
SQL> flashback database to scn 4568952369;
Flashback complete.
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL>
--A库恢复正常，并且可以跨越化身进行恢复，先恢复化身8的然后恢复化身9的，完成日志追平
Sat Mar 18 13:12:18 2023
flashback database to scn 4568952369
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Sat Mar 18 13:12:18 2023
SMON: disabling cache recovery
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
Sat Mar 18 13:12:18 2023
Setting recovery target incarnation to 8
started logmerger process
Parallel Media Recovery started with 2 slaves
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_147_1128704778.dbf
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_148_1128704778.dbf
Sat Mar 18 13:12:18 2023
Identified End-Of-Redo (switchover) for thread 1 sequence 148 at SCN 0x1.1054ab5e
Resetting standby activation ID 884686125 (0x34bb3d2d)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_149_1128704778.dbf
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_150_1128704778.dbf
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_151_1128704778.dbf
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_152_1128704778.dbf
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_153_1128704778.dbf
Flashback Media Recovery Log /u01/app/oracle/gbkarch/1_154_1128704778.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 154 at SCN 0x1.1054ae33
Incomplete Recovery applied until change 4568952370 time 03/18/2023 12:24:24
Flashback Media Recovery Complete
Setting recovery target incarnation to 9
Completed: flashback database to scn 4568952369
Sat Mar 18 13:13:18 2023
idle dispatcher 'D000' terminated, pid = (17, 1)
Sat Mar 18 13:13:28 2023
alter database recover managed standby database using current logfile disconnect from session
Attempt to start background Managed Standby Recovery process (gbkdb)
Sat Mar 18 13:13:28 2023
MRP0 started with pid=28, OS id=24735
MRP0: Background Managed Standby Recovery process started (gbkdb)
started logmerger process
Sat Mar 18 13:13:33 2023
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Media Recovery start incarnation depth : 1, target inc# : 9, irscn : 4568952371
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 1 /u01/app/oracle/oradata/gbkdb/redo01.log
Clearing online log 1 of thread 1 sequence number 158
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/app/oracle/oradata/gbkdb/redo02.log
Clearing online log 2 of thread 1 sequence number 159
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /u01/app/oracle/oradata/gbkdb/redo03.log
Clearing online log 3 of thread 1 sequence number 157
Clearing online redo logfile 3 complete
Media Recovery Log /u01/app/oracle/gbkarch/1_154_1128704778.dbf
Identified End-Of-Redo (failover) for thread 1 sequence 154 at SCN 0x1.1054ae33
Resetting standby activation ID 884647866 (0x34baa7ba)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Log /u01/app/oracle/gbkarch/1_1_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_2_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_3_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_4_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_5_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_6_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_7_1131798273.dbf
Completed: alter database recover managed standby database using current logfile disconnect from session
Media Recovery Log /u01/app/oracle/gbkarch/1_8_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_9_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_10_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_11_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_12_1131798273.dbf
Media Recovery Log /u01/app/oracle/gbkarch/1_13_1131798273.dbf
Media Recovery Waiting for thread 1 sequence 14 (in transit)
Recovery of Online Redo Log: Thread 1 Group 11 Seq 14 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/gbkdb/sredo11.log
5、此时调整级联关系B>A>C，如需恢复A>B>C，则A和B执行switchover即可
--B库执行如下即可
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=gbkdbdr VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=gbkdbdr';
System altered.
最后修改时间：2023-03-28 14:14:46
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
