今天看到有一個網友提了一個問題，描述很簡短 測試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的閃回給備庫帶來了如此多的改進。