Oracle - Flashback standby after resetlogs on primary

一、概述

本文将给大家介绍主库使用rman做不完全恢复后，备库如何通过flashback，继续同步

二、正式实验

本次实验采用的是oracle 11g 单实例 + oracle 11g 单实例dg

1. dg的搭建（略）

实验的前提条件是你已经有了一个正在同步的dg环境，关于dg如何搭建不在本文讨论范围内

2. 打开dg的闪回功能

SQL> alter system set db_recovery_file_dest_size = 4G;
SQL> alter system set db_recovery_file_dest = '/u01/app/oracle/fast_recovery_area';

# 需要先关闭mrp进程，才能打开dg闪回功能
SQL> alter database recover managed standby database cancel;
SQL> alter database flashback on;
SQL> alter database recover managed standby database using current logfile disconnect from session;

3. 主库进行备份

RMAN> backup database;

4. 主库查询scn

SQL> select current_scn from v$database;   

CURRENT_SCN
-----------
     940486

5. 主库做一系列的操作

SQL> create table scott.test1 as select * from scott.emp;
SQL> alter system switch logfile;
SQL> create table scott.test2 as select * from scott.emp;
SQL> alter system switch logfile;
SQL> create table scott.test3 as select * from scott.emp;
SQL> alter system switch logfile;
SQL> create table scott.test4 as select * from scott.emp;   

6. 主库还原恢复

现在我要回退主库到scn 940486，将第5步中的操作全部回退

SQL> shutdown immediate;
SQL> startup mount;
RMAN> restore database;
RMAN> recover database until scn 940486;
SQL> alter database open resetlogs;
SQL> select resetlogs_change# from v$database;

RESETLOGS_CHANGE#
-----------------
           940487

可以看到主库是回退到了940486，resetlogs的scn号是940487

7. 观察dg的alert日志

以下是dg的alert日志的节选

Tue Aug 25 11:33:38 2020
RFS[5]: Assigned to RFS process 1972
RFS[5]: Selected log 23 for thread 1 sequence 1 dbid -1499891995 branch 1049369616
RFS[5]: Standby in the future of new recovery destinationBranch(resetlogs_id) 1049369616
Incomplete Recovery SCN: 941492
Resetlogs SCN: 940487
Flashback database to SCN 940486 to follow new branch
Flashback database to SCN 940486 to follow new branch
RFS[5]: New Archival REDO Branch(resetlogs_id): 1049369616  Prior: 1047566949
RFS[5]: Archival Activation ID: 0xa6b56927 Current: 0xa69921e5
RFS[5]: Effect of primary database OPEN RESETLOGS
RFS[5]: Managed Standby Recovery process is active
RFS[5]: Incarnation entry added for Branch(resetlogs_id): 1049369616 (dgorcltest)
...
MRP0: Background Media Recovery process shutdown (dgorcltest)

可以看到dg库已经知道主库做了resetlogs，也提示dg需要flashback才能继续同步。这里提示dg需要flashback到940486，也就是主库做不完全恢复的点，但实际测试下来，需要flashback更早一点才行，即940486-1=940485
同时dg的mrp进程自动就shutdown了

8. dg闪回

SQL> flashback database to scn 940485;
SQL> alter database open;
SQL> alter database recover managed standby database using current logfile disconnect from session;

9. 主库做修改

SQL> create table scott.test5 as select * from scott.emp;
SQL> alter system switch logfile;

10. 从库查询

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

  COUNT(*)
----------
        14

可以看到dg又正常同步主库了。

三、总结

从上面的例子可以看到
940486 --> 主库不完全恢复的点
940487 --> 主库resetlogs的点
940485 --> dg闪回的点
也就是dg必须闪回到主库不完全恢复的点的前面，dg闪回的点可以通过下面sql在主库中查询得到。

SQL> select resetlogs_change#-2 from v$database;

RESETLOGS_CHANGE#-2
-------------------
             940485