注意：故障轉移會破壞DG的主從關係，使其變為互不相關的2個數據庫，謹慎使用。

（一）故障轉移操作流程圖

（二）故障轉移操作流程
備註：以下操作步驟與上面流程圖步驟一一對應

STEP1：重新整理所有未傳送到備庫的日誌到備庫
如果主庫還可以啟動到mount狀態，則重新整理所有未傳送的歸檔日誌和線上redo日誌到備庫。如果這一步成功了，則可以保證資料零丟失。
如果主庫不能mount，則執行第2步。
使用如下命令重新整理redo日誌到備庫:

SQL> ALTER SYSTEM FLUSH REDO TO 'target_db_name';

其中，target_db_name為備庫的db_unique_name。

STEP2：確認備庫接收到的最新的歸檔日誌檔案
在備庫上使用V$ARCHIVED_LOG檢視，查詢每個例項的最大日誌序列號的日誌，通過查詢出的日誌序列號與主庫的最大日誌序列號比較（主庫的直接到伺服器上去檢視歸檔日誌檔案），可以直到缺失了哪些歸檔日誌檔案

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
THREAD       LAST
---------- ----------
1          100

如果可能，對於還未傳輸到備庫的日誌檔案，直接從主資料庫上拷貝過去，然後註冊日誌，註冊日誌放入如下：

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

STEP3：確認和解決日誌GAP
在備庫上查詢V$ARCHIVE_GAP檢視，確認是否存在日誌GAP，如：

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD#    LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1            90             92

在這個例子中，GAP存在於執行緒1的90，91，92號歸檔日誌上，如果可能，拷貝這些日誌到備庫伺服器上，然後註冊日誌

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

STEP4：重複步驟3直到把所有GAP解決
繼續在備庫上查詢V$ARCHIVE_GAP檢視，直到沒有資料返回，說明沒有GAP。
如果在執行了步驟2到步驟4後，依然無法解決日誌GAP（例如，主伺服器宕機，我們無法訪問主資料庫，導致日誌無法同步到備庫），則執行failover切換後會存在資料丟失。

STEP5：備庫停止日誌應用
執行如下操作：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

STEP6：完成所有已經接收日誌的應用
在備庫上執行如下操作：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

如果這個操作未報錯，則執行步驟7。
如果發生報錯，嘗試解決錯誤，再次執行以上SQL語句，如果報錯無法解決，可以在目標備庫執行以下語句來進行故障轉移（會丟失資料）

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

這個語句完成後跳到第9步執行。

STEP7：確認目標備庫準備切換為主庫
檢視目標備庫v$database檢視的SWITCHOVER_STATUS列

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY

如果SWITCHOVER_STATUS的值為“TO PRIMARY”或者“SESSIONS ACTIVE”，則說明備庫已經準備切換為主庫。如果不是這2個值，確認Redo日誌應用是否還是活躍的，繼續查詢，直到變為這2個值中的一個為止。

STEP8：切換物理備庫為主庫
使用下面的SQL語句進行切換：

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

STEP9：開啟新的主庫

SQL> ALTER DATABASE OPEN;

後續：

1.在開啟資料庫之後，建議做一個完整備份；

2.如果主伺服器/資料庫重新啟動，則需要還原失敗的主資料庫。

【完】