五、failover
一般情況下執行failover都是主庫已經game over。故障轉移將備庫轉換為主庫，但不把原主庫（有故障，無法正常工作）切換為備庫。當故障轉移發生后，你必須重建主庫，或者使用閃回數據庫功能將主庫回退到故障發生前，然后轉換其為備庫並啟用日志應用。
執行failover有幾個前提條件如下
1.執行failover的前提
(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 數據庫此
時已經無法打開，甚至無法訪問,那只好聽天由命了，但是如果可以到mounted，則可以傳輸歸檔日志。
所以應該在primary機器crashed之前做好准備。
加入此時結果是：
THREAD# A
---------- ----------
1 87
從庫最大為87，主庫也執行，如果也是87則ok，如果不一致需要scp 然后執行register
（3）如果當前備庫是處於最大保護（maximum protection）模式，要進行故障轉移，必須先修改為最大性能
（maximum performance）模式。修改方法：
SQL> alter database set standby database to maximize performance;
2,。執行切換
(1)在備庫停止日志應用：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
(2)結束應用任何日志：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
或者：
SQL> alter database recover managed standbydatabase finish force;
FORCE 關鍵字將會停止當前活動的 RFS 進程，以便立刻執行 failover。
(3)轉換備庫為主庫
SQL> alter database commit to switchover to primary with session shutdown;
SQL> alter database open;
注意這個時候主庫已經不在dataguard中了。
3.使用閃回重建數據庫
(1)獲得原備庫轉換為主庫時的 SCN。查詢現主庫102：
SQL> SELECT to_char(STANDBY_BECAME_PRIMARY_SCN) from V$DATABASE;
(2)在原主庫101上執行：
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN &standby_became_primary_scn;輸入之前查詢到的SCN號
如果沒有開始閃回日志，最后一條命令會報錯 ORA-38726: Flashback database logging is not on.，
無法進行閃回。你就需要重新從新主庫復制數據，重建原主庫為備庫。
如果命令成功執行，原主庫101就可以使用新主庫102的日志進行恢復。將原主庫101轉換成物理備庫，並啟動日志應用進程：
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
4.客戶端故障轉移
我很喜歡的一個功能是，當主備切換或故障轉移發生后，客戶端能夠自動重連。在你的系統里，做下述實驗，看結果如何。
orcl 是主庫，orcldg 是備庫。客戶端使用支持故障轉移的 orcl_RW 服務名。
首先，用 SYSTEM 用戶和 orcl_RW 服務名在 SQL*Plus 里登錄主庫：
SQL> connect system@orcl_rw
SQL> select db_unique_name from v$database;
查詢應該返回主庫名 orcl。然后做一次主備切換，在將備庫轉換為主庫
alter database commit to switchover to primary with session shutdown; 這一步時，主備庫均處於 MOUNT 狀態。
然后執行查詢：
SQL> select db_unique_name from v$database;
這時查詢應該掛住，這是因為客戶端正在嘗試尋找主庫，但當前又沒有可用的主庫。然后繼續完成主備切換。
當主備切換完成后，客戶端應該會重連並重新執行查詢，查詢完成后成功返回結果 orcldg，因為現在主庫已經切換為 orcldg，
不再是orcl。
另一個很酷的測試方法是，執行一個執行時間非常長的查詢，當查詢結果返回，屏幕一直滾動時開始主備切換。
你應該會看到屏幕暫停滾動一段時間，當切換完成后，又會繼續滾動。
5.活動數據衛士（active dataguard)
活動數據衛士是 11g 的新功能，它允許你的物理備庫在應用日志時處於只讀打開狀態。這明顯是一個很有用的功能。
能夠允許主庫有一個物理備庫作為備份，並能在保持備庫數據更新的同時讀取備庫，這是一個很好的功能。
調整備庫為“READ ONLY WITH APPLY”狀態，這體現的便是Oracle 11g物理Active Data Guard功能中的“Active”真實含義。
在實際工作中，這個功能非常好用，經常用於檢查實時數據同步情況。
(1)查看備庫openmode
sql>select open_mode from v$database;--MOUNTED
(2)取消備庫的自動恢復
sql>alter database recover managed standby database cancel;
sql>alter database open;
sql>select open_mode from v$database; --這時候為READ ONLY
(3)read only下備庫恢復
sql>alter database recover managed standby database using current logfile disconnect;
sql>select open_mode from v$database; --這時為READ ONLY WITH APPLY
6.11g standby的一些變化：
(1)standby數據庫可以直接執行
startup --就是read only打開數據庫
startup mount --就是mount standby數據庫
(2)read only的情況下可以執行managed recover standby命令。
SQL>startup
SQL>alter database recover managed standby database disconnect;
7.關於備份的引申
有了 Data Guard，你的 RMAN 備份在主庫或者備庫都可以執行。但既然你已經配置了物理備庫，你應該減輕點主庫的負載。
基本上，能在主庫執行的標准的備份命令或腳本，也能在備庫執行，但也有幾個值得注意地方。這些 Oracle 官方文檔都有，
我只提幾個關鍵的事情：
你應該使用恢復目錄（Recovery Catalog）。這是因為主庫需要知道備庫已經存在了哪些備份文件。你不需要在恢復目錄中
注冊備庫，恢復目錄能認出它是備庫。
你不能備份備庫的控制文件，所以不要在主庫關掉所有的備份，至少需要在主庫備份控制文件和參數文件。
備份和恢復可以寫一整篇文章，我只是講下我是如何配置備份的，讓你能從這里開始，修改並形成自己的策略。
測試下，確認你能從你當前實現的備份設置中恢復。在運行備份前，你需要配置一些基本的東西。
(1)確認開啟控制文件和 spfile 自動備份：
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
(2)根據你的需要設置備份文件保留策略：
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
(3)如果一個文件已經有備份，並且檢查點 SCN 相同，就不備份：
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
(4)只在主庫的歸檔日志已經在備庫應用（或者配置為已經傳輸到備份）后才刪除：
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
(5)允許 RMAN 在主備間重新同步：
RMAN> CONFIGURE DB_UNIQUE_NAME P10AC CONNECT IDENTIFIER ‘JED’;
RMAN> CONFIGURE DB_UNIQUE_NAME P11AC CONNECT IDENTIFIER 'JED2';
在主庫我仍然備份歸檔日志。首先，在主備庫都備份歸檔提供了冗余。其次，當發生需要恢復的事件（比如數據文件下線等）后，
我在主庫已經有歸檔了。我需要刪除過期的歸檔，以清理磁盤空間。
在 Data Guard 環境下，不能使用標准的在單機刪除歸檔的命令，兩者有一點小區別。因為我們必須使用恢復目錄，
我創建了一個全局腳本（global script）：
create global script dg_primary_arch
{
backup archivelog all;
delete noprompt archivelog all completed before 'sysdate-.5';
delete noprompt backup of archivelog all completed before 'sysdate-2';
}
在備庫我運行標准的全庫和歸檔備份，並刪除過期的備份集。在 Data Guard 環境下，將備份歸檔包含在備份全庫的命令里，
會經常導致報錯 RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process。
為避免此報錯，你應該將備份歸檔放在單獨的命令里。我還是創建一個全局腳本：
create global script dg_standby_full
{
backup database plus archivelog;
delete noprompt archivelog all completed before 'sysdate-1';
delete noprompt obsolete;
}
另外一個有用的技巧是，如果可能，使用共享文件系統進行備份。這樣你在兩台服務器上都可以訪問備份文件。
這樣，當你需要恢復時，你不需要從另一台服務器上復制文件了。但如果使用共享文件系統的話，你的歸檔備份雖然有兩份，
卻都放在一個文件系統里，如果硬盤出現故障，兩份備份都會丟失。
參考文檔：
1.《Oracle 11g Data Guard 物理備庫快速配置指南》
2.《三思筆記：一步一步學dataguard》
3.《Red_HatOracle11gDataGuard配置寶典》
4.其他網絡資料