Home > DGCA > failover flashback db带来的问题

failover flashback db带来的问题

都知道如果主库开了flashback db功能,那么在failover之后可以flashback 到原备库变成主库的scn,然后convert为备库,再recover。
假象一个情景,如果在备库脱离了DG关系之后,主库再归档几个日志(虽然一般做failover不太可能出现这种情况),此时本地是有相应归档文件的,然后再flashback+convert+recover,那么会应用自己之前生成的归档还是会忽略呢?
下面做个测试:原主 johnnydb_dg 原备 johnnydb

1.检查两边归档日志情况:
--pri
SQL> select * from (select sequence#,name,applied from v$archived_log order by 1 desc) where rownum /

SEQUENCE# NAME APP
---------- ------------------------------------------------------------ ---
174 /data/arch/johnnydb/1_174_767310934.dbf YES
173 /data/arch/johnnydb/1_173_767310934.dbf YES
172 /data/arch/johnnydb/1_172_767310934.dbf YES
...
2.failover
--stb
SQL> recover managed standby database finish force;
Media recovery complete.
SQL> alter system set log_archive_dest_state_2=defer;

System altered.
SQL> select * from (select sequence#,name,applied from v$archived_log order by 1 desc) where rownum alter database commit to switchover to primary;

Database altered.

SQL> select * from (select sequence#,name,applied from v$archived_log order by 1 desc) where rownumalter database open;

Database altered.
SQL> select STANDBY_BECAME_PRIMARY_SCN from v$database;

STANDBY_BECAME_PRIMARY_SCN
--------------------------
376270
--pri
SQL> alter system set log_archive_dest_state_2=defer;

System altered.

SQL> alter system switch logfile; --切换若干次,生成多个arch log

System altered.

SQL> /
...
SQL> select * from (select sequence#,name,applied from v$archived_log order by 1 desc) where rownum shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 268435456 bytes
Fixed Size 1218892 bytes
Variable Size 88082100 bytes
Database Buffers 176160768 bytes
Redo Buffers 2973696 bytes
Database mounted.
SQL> flashback database to scn 376270;

Flashback complete.

SQL> alter database convert to physical standby;

Database altered.
SQL> shutdown immediate
SQL> startup mount
SQL> select * from (select sequence#,name,applied from v$archived_log order by 1 desc) where rownum recover managed standby database disconnect;
Media recovery complete.
SQL> select * from (select sequence#,name,applied from v$archived_log order by 1 desc) where rownum alter system switch logfile;

System altered.

SQL> /
/
/
/
/
/
/
/
/
/
SQL> select * from (select sequence#,name,applied from v$archived_log order by 1 desc) where rownum=该seq的归档,再recover即可。
--new stb
SQL> flashback database to scn 376269;

Flashback complete.
SQL> recover managed standby database disconnect;
Media recovery complete.
[oracle@localhost johnnydb_dg]$ rm * -rf
[oracle@localhost johnnydb_dg]$ ll
total 0
此时,RTS会自己去解决GAP,重新传输丢失的归档,因为是flashback到STANDBY_BECAME_PRIMARY_SCN之前的时间点,所以恢复的时候会遇到这么一条:
Thu Feb 23 20:55:16 2012
Media Recovery Log /data/arch/johnnydb_dg/1_175_767310934.dbf
Identified End-Of-Redo for thread 1 sequence 175
Thu Feb 23 20:55:17 2012
Media Recovery End-Of-Redo indicator encountered
Thu Feb 23 20:55:17 2012
Media Recovery Applied until change 376289
Thu Feb 23 20:55:17 2012
MRP0: Media Recovery Complete: End-Of-REDO (johnnydb_dg)
Media Recovery archivelogs detected beyond End-Of-REDO
Resetting standby activation ID 988286050 (0x3ae80c62)
Thu Feb 23 20:55:18 2012
MRP0: Background Media Recovery process shutdown (johnnydb_dg)
恢复遇到了新主库的convert点(End-Of-REDO标记),并且MRP自己关了,再次打开MRP进程继续恢复就可以了。
SQL> recover managed standby database disconnect;
Media recovery complete.
alert:
Thu Feb 23 20:56:56 2012
Media Recovery Log /data/arch/johnnydb_dg/1_176_767310934.dbf
Media Recovery Waiting for thread 1 sequence 177
Fetching gap sequence in thread 1, gap sequence 177-177
Thu Feb 23 20:56:58 2012
Archivelog record exists, but no file is found
RFS[1]: Archived Log: '/data/arch/johnnydb_dg/1_177_767310934.dbf'
Thu Feb 23 20:57:28 2012
Media Recovery Log /data/arch/johnnydb_dg/1_177_767310934.dbf
Media Recovery Log /data/arch/johnnydb_dg/1_178_767310934.dbf
Error opening /data/arch/johnnydb_dg/1_178_767310934.dbf
Attempting refetch
Media Recovery Waiting for thread 1 sequence 178
Fetching gap sequence in thread 1, gap sequence 178-178
Thu Feb 23 20:57:30 2012
RFS[1]: Allowing overwrite of partial archivelog for thread 1 sequence 178
RFS[1]: Archived Log: '/data/arch/johnnydb_dg/1_178_767310934.dbf'
...
Categories: DGCA Tags:
  1. No comments yet.
  1. No trackbacks yet.