物理standby的failover
注意幾點：
l failover之後，原primary數據庫默認不再是data guard配置的一部分。
l 多數情況下，其它邏輯/物理standby數據庫不直接參與failover的過程，因此這些數據庫不需要做任何操作。
l 某些情況下，新的primary數據庫配置之後，需要重新創建其它所有的standby數據庫。
另外，如果待轉換角色的standby處於maximum protection或maximum availability模式的話，歸檔日誌應該是連續存在的，這種情況下你可以直接從第3步執行，否則建議你按照操作步驟從第1步開始執行。
一般情況下failover都是表示primary數據庫癱瘓，最起碼也是起不來了，因此這種類型的切換基本上不需要primary數據庫做什麼操作。所以下列步驟中如果有提到primary和standby執行的，只是建議你如果primary還可以用，那就執行一下，即使它能用你卻不執行，也沒關係，不影響standby數據庫的切換:)
1、檢查歸檔文件是否連續
查詢待轉換standby數據庫的V$ARCHIVE_GAP視圖，確認歸檔文件是否連接：
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
未選定行
如果返回的有記錄，按照列出的記錄號複製對應的歸檔文件到待轉換的standby服務器。這一步非常重要，必須確保所有已生成的歸檔文件均已存在於standby服務器，不然可能會數據不一致造成轉換時報錯。文件複製之後，通過下列命令將其加入數據字典：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
2、檢查歸檔文件是否完整
分別在primary/standby執行下列語句：
SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
該語句取得當前數據庫各線程已歸檔文件最大序號，如果primary與standby最大序號不相同，必須將多出的序號對應的歸檔文件複製到待轉換的standby服務器。不過既然是failover，有可能primary數據庫此時已經無法打開，甚至無法訪問，那你只好聽天由命嘍，三思在這裏替你默唸：蒼天啊，大地啊，哪路的神仙大姐能來保佑俺們不丟數據呀！
3、啓動failover
執行下列語句：
SQL> alter database recover managed standby database finish force;
數據庫已更改。
FORCE關鍵字將會停止當前活動的RFS進程，以便立刻執行failover。
剩下的步驟就與前面switchover很相似了
4、切換物理standby角色爲primary
SQL> alter database commit to switchover to primary;
數據庫已更改。
5、啓動新的primary數據庫。
如果當前數據庫已mount,直接open即可，如果處於read-only模式，需要首先shutdown immediate，然後再直接startup。
SQL> alter database open;
數據庫已更改。
角色轉換工作完成。剩下的是補救措施(針對原primary數據庫)，由於此時primary數據庫已經不再是data guard配置的一部分，我們需要做的就是嘗試看看能否恢復原primary數據庫，將其改造爲新的standby服務器。具體操作方式可以分爲二類：1.重建 2.備份恢復。所涉及的技術前面的系列文章中均有涉及，此處不再贅述。