今天看到有一个网友提了一个问题，描述很简短
测试DG时，主库不能宕机，如何测试failover?
其实这个需求从业务层面来说是合理的，一个数据量很大的核心数据库，如果需要做灾难演练，就希望在备库上做一下演练工作，而这个演练其实又不想影响到目前的主库，而且又希望能够尽可能模拟真实的情况，我想这样对于运维部门来说是最具有考核力度，而对于开发业务部门来说是最受欢迎的，因为他们什么都不需要改动。
而从技术角度来看，似乎有一些地方需要考量，如果备库Failover为主库，那么这个主库肯定是可以进行读写操作的，如果把它再切回备库，数据一致性怎么保证，怎么能保证是从上次的断电开始恢复。如果可以做，那真是一大福利。
我们来看看Oracle提供的方式方法，两大法宝，switchover和Failover
Switchover切换的核心脚本如下，
在备库执行，取消日志应用
recover managed standby database cancel;
在主库执行，切换角色
Alter database commit to switchover to physical standby with session shutdown;
而Failover的核心脚本则为：
在备库执行
alter database recover managed standby database finish force;
alter database commit to switchover to primary;
如此来看，要实现上面的部分还是有一些难度。
今天反反复复测试了不下十多次，重建了很多次环境，总算在晚饭过后把这个问题顺利调试好了，虽然思路上是可行的，但是有一个地方总是卡在了下面的错误上。
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/U01/app/oracle/oradata/newtest2/system01.dbf'
明白了原委，解决起来全然不费功夫。
我们先讲讲思路，还是闪回，但是闪回的玩法有一些差别，和reinstate的方式有一些区别。假设是一主一备的环境，备库开启了闪回数据库功能。
我们不动原来的主库，把备库Failover为主库。
然后这个时候Failover的主库可读可写，当然最后还是要切换回备库接收归档，可以使用闪回，同时还需要切换角色，这个地方需要好好琢磨一番改怎么处理。
假设我们的数据库主库为newtest2,备库为snewtest2
在备库snewtest2上开启闪回，在备库上MRP可以实时接受数据变化。
SQL> alter database open;
Database altered.
SQL> SQL> alter database flashback on;
Database altered.
得到一个参考的SCN
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
1765837
查看闪回数据库特性是打开的。
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------------------------
YES
然后我们在备库上开始failover
DGMGRL> DGMGRL> failover to snewtest2;
Performing failover NOW, please wait...
Failover succeeded, new primary is "snewtest2"
DGMGRL>
操作很快完成，我们查看备库此时的状态和角色
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
---------------------------------------- --------------------------------
READ WRITE PRIMARY
当然这个步骤可以做一些读写操作之类的。
然后我们开始计划切回备库。
SQL> shutdown immediate
SQL> startup mount
然后开启闪回数据库，恢复到指定的SCN,这个时候要注意，此时还是主库。
SQL> flashback database to scn 1765837;
Flashback complete.
我们需要切换为备库，这个时候切换的命令就是关键，不是使用switchover的方式。
SQL> alter database convert to physical standby;
Database altered.
当然这个时候数据库在nomount阶段，我们需要重启备库。
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00750: database has been previously mounted and dismounted
SQL> shutdown immediate
SQL> startup mount
重新配置一下DG Broker即可，可以设置dg_broker_start=false,停掉dmon,然后删掉$ORACLE_HOME/dbs下的dr*newtest2.dat的配置文件，重新配置DG Broker即可。
配置起来都是老套路。
简单配置后，DG Broker的检查就正常了。
DGMGRL> DGMGRL> show configuration;
Configuration - dg_newtest2
Protection Mode: MaxPerformance
Databases:
newtest2 - Primary database
snewtest2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL>
对应的数据库日志中可以看到后台已经开始应用日志了。
RFS[2]: Assigned to RFS process 44981
RFS[2]: Selected log 5 for thread 1 sequence 48 dbid 795252212 branch 921251959
Tue Aug 30 21:32:01 2016
Archived Log entry 5 added for thread 1 sequence 48 ID 0x2f7352f8 dest 1:
Tue Aug 30 21:32:01 2016
Media Recovery Log /U01/app/oracle/fast_recovery_area/SNEWTEST2/archivelog/2016_08_30/o1_mf_1_48_cwc2pk57_.arc
Media Recovery Waiting for thread 1 sequence 49 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 49 Reading mem 0
Mem# 0: /U01/app/oracle/fast_recovery_area/SNEWTEST2/onlinelog/o1_mf_4_cwc0lmr7_.log
当实现这个看起来有些特殊的需求的时候，我真心内心充满了喜悦，也着实惊叹Oracle的闪回给备库带来了如此多的改进。
测试DG时，主库不能宕机，如何测试failover?
其实这个需求从业务层面来说是合理的，一个数据量很大的核心数据库，如果需要做灾难演练，就希望在备库上做一下演练工作，而这个演练其实又不想影响到目前的主库，而且又希望能够尽可能模拟真实的情况，我想这样对于运维部门来说是最具有考核力度，而对于开发业务部门来说是最受欢迎的，因为他们什么都不需要改动。
而从技术角度来看，似乎有一些地方需要考量，如果备库Failover为主库，那么这个主库肯定是可以进行读写操作的，如果把它再切回备库，数据一致性怎么保证，怎么能保证是从上次的断电开始恢复。如果可以做，那真是一大福利。
我们来看看Oracle提供的方式方法，两大法宝，switchover和Failover
Switchover切换的核心脚本如下，
在备库执行，取消日志应用
recover managed standby database cancel;
在主库执行，切换角色
Alter database commit to switchover to physical standby with session shutdown;
而Failover的核心脚本则为：
在备库执行
alter database recover managed standby database finish force;
alter database commit to switchover to primary;
如此来看，要实现上面的部分还是有一些难度。
今天反反复复测试了不下十多次，重建了很多次环境，总算在晚饭过后把这个问题顺利调试好了，虽然思路上是可行的，但是有一个地方总是卡在了下面的错误上。
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/U01/app/oracle/oradata/newtest2/system01.dbf'
明白了原委，解决起来全然不费功夫。
我们先讲讲思路，还是闪回，但是闪回的玩法有一些差别，和reinstate的方式有一些区别。假设是一主一备的环境，备库开启了闪回数据库功能。
我们不动原来的主库，把备库Failover为主库。
然后这个时候Failover的主库可读可写，当然最后还是要切换回备库接收归档，可以使用闪回，同时还需要切换角色，这个地方需要好好琢磨一番改怎么处理。
假设我们的数据库主库为newtest2,备库为snewtest2
在备库snewtest2上开启闪回，在备库上MRP可以实时接受数据变化。
SQL> alter database open;
Database altered.
SQL> SQL> alter database flashback on;
Database altered.
得到一个参考的SCN
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
1765837
查看闪回数据库特性是打开的。
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------------------------
YES
然后我们在备库上开始failover
DGMGRL> DGMGRL> failover to snewtest2;
Performing failover NOW, please wait...
Failover succeeded, new primary is "snewtest2"
DGMGRL>
操作很快完成，我们查看备库此时的状态和角色
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
---------------------------------------- --------------------------------
READ WRITE PRIMARY
当然这个步骤可以做一些读写操作之类的。
然后我们开始计划切回备库。
SQL> shutdown immediate
SQL> startup mount
然后开启闪回数据库，恢复到指定的SCN,这个时候要注意，此时还是主库。
SQL> flashback database to scn 1765837;
Flashback complete.
我们需要切换为备库，这个时候切换的命令就是关键，不是使用switchover的方式。
SQL> alter database convert to physical standby;
Database altered.
当然这个时候数据库在nomount阶段，我们需要重启备库。
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00750: database has been previously mounted and dismounted
SQL> shutdown immediate
SQL> startup mount
重新配置一下DG Broker即可，可以设置dg_broker_start=false,停掉dmon,然后删掉$ORACLE_HOME/dbs下的dr*newtest2.dat的配置文件，重新配置DG Broker即可。
配置起来都是老套路。
简单配置后，DG Broker的检查就正常了。
DGMGRL> DGMGRL> show configuration;
Configuration - dg_newtest2
Protection Mode: MaxPerformance
Databases:
newtest2 - Primary database
snewtest2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL>
对应的数据库日志中可以看到后台已经开始应用日志了。
RFS[2]: Assigned to RFS process 44981
RFS[2]: Selected log 5 for thread 1 sequence 48 dbid 795252212 branch 921251959
Tue Aug 30 21:32:01 2016
Archived Log entry 5 added for thread 1 sequence 48 ID 0x2f7352f8 dest 1:
Tue Aug 30 21:32:01 2016
Media Recovery Log /U01/app/oracle/fast_recovery_area/SNEWTEST2/archivelog/2016_08_30/o1_mf_1_48_cwc2pk57_.arc
Media Recovery Waiting for thread 1 sequence 49 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 49 Reading mem 0
Mem# 0: /U01/app/oracle/fast_recovery_area/SNEWTEST2/onlinelog/o1_mf_4_cwc0lmr7_.log
当实现这个看起来有些特殊的需求的时候，我真心内心充满了喜悦，也着实惊叹Oracle的闪回给备库带来了如此多的改进。
