暂无图片
暂无图片
4
暂无图片
暂无图片
2
暂无图片
首页 / 级联DG——常见问题

级联DG——常见问题

原创 董宏伟 云和恩墨 2023-03-18
2113

级联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.

复制
oracle级联dg墨力计划
最后修改时间：2023-03-28 14:14:46
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
4人已赞赏
皮
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

文章被以下合辑收录

Oracle高可用（共13篇）
Oracle高可用

评论

筱悦星辰
暂无图片
2年前
评论
暂无图片 0
有一种幸福，叫做家人是你的依靠；有一种自豪，叫做你正尽己所能为他们遮风挡雨。
2年前
暂无图片 点赞
评论
Oracle6
暂无图片
2年前
评论
暂无图片 0
路过学习
2年前
暂无图片 点赞
评论

相关阅读

【专家有话说第五期】在不同年龄段，DBA应该怎样规划自己的职业发展？
墨天轮编辑部
1270次阅读
2025-03-13 11:40:53
Oracle RAC ASM 磁盘组满了，无法扩容怎么在线处理？
Lucifer三思而后行
766次阅读
2025-03-17 11:33:53
Oracle+Deepseek+Dify 实现数据库数据实时分析
bicewow
681次阅读
2025-03-06 09:41:49
【ORACLE】ORACLE19C在19.13版本前的一个严重BUG-24761824
DarkAthena
564次阅读
2025-03-04 14:33:31
Oracle避坑指南｜同名表导出难题：如何精准排除指定用户下的表？
szrsu
512次阅读
2025-03-05 00:42:34
2月“墨力原创作者计划”获奖名单公布
墨天轮编辑部
452次阅读
2025-03-13 14:38:19
Ogg23ai高手必看-MySQL Innodb Cluster跟oracle的亲密接触
曹海峰
446次阅读
2025-03-04 21:56:13
【ORACLE】char类型和sql优化器发生的“错误”反应
DarkAthena
404次阅读
2025-03-04 23:05:01
什么，oracle 主机用户被删了？原来是虚惊一场！
Lucifer三思而后行
401次阅读
2025-03-03 21:12:09
Oracle 如何修改 db_unique_name？强迫症福音！
Lucifer三思而后行
340次阅读
2025-03-12 21:27:56
董宏伟
暂无图片
关注
38
文章
105
粉丝
47K+
浏览量
暂无图片
获得了149次点赞
暂无图片
内容获得22次评论
暂无图片
获得了154次收藏
TA的专栏
MogDB
收录7篇内容
Oracle高可用
收录13篇内容
热门文章
Linux 8.3下Oracle11.2.0.4单机安装（官方新增认证）
2022-12-27 5605浏览
Oracle数据文件迁移 | 从一个磁盘组到另一个磁盘组
2022-11-04 4303浏览
Oracle LOB——基本概念
2023-01-06 4115浏览
OBCP V3.0考试经验分享
2023-05-05 2710浏览
故障案例--19c建库识别不到磁盘组
2023-04-12 2651浏览
在线实训环境入口
Oracle 18C 在线实训环境
查看详情
最新文章
12c+统一审计
2024-01-10 258浏览
使用本地函数DML操作远程表时报错ORA-02069
2023-10-27 272浏览
PDB添加服务报错之修改数据库唯一名
2023-10-25 598浏览
Linux文件中文存储字符编码浅析
2023-10-12 499浏览
故障案例--物化视图增量刷新报错ORA-12034
2023-08-29 451浏览
目录
  • 级联DG
  • 级联DG的规范配置如下
    • 1、归档传输参数
    • 2、convert参数
      • 搭建阶段
      • 后期添加数据文件阶段
  • 级联DG B库failover情况测试
    • 1、A库down机
    • 2、B库failover
    • 3、C库日志情况
    • 4、A库尝试启动恢复为物理备库
    • 5、此时调整级联关系B>A>C，如需恢复A>B>C，则A和B执行switchover即可