Oracle11gDataGuard之角色轉換

來源：懂視網責編：小采時間：2020-11-09 16:29:28

Oracle11gDataGuard之角色轉換

Oracle11gDataGuard之角色轉換:1.1 簡介 Data Guard配置包括1個primary角色的數據庫和1個或者多個standby角色的數據庫，數據庫的角色我們可以通過V$DATABASE中DATABASE_ROLE字段來獲得。另外，Data Guard配置中standby庫的數量、位置、備庫類型以及redo data從主庫傳到備庫的

推薦度：

點擊下載本文 文檔為doc格式

導讀Oracle11gDataGuard之角色轉換:1.1 簡介 Data Guard配置包括1個primary角色的數據庫和1個或者多個standby角色的數據庫，數據庫的角色我們可以通過V$DATABASE中DATABASE_ROLE字段來獲得。另外，Data Guard配置中standby庫的數量、位置、備庫類型以及redo data從主庫傳到備庫的

Switchover允許主庫切換角色到它的某一個備庫，在切換期間不會丟失數據，切換之后，每個數據庫繼續以其新的角色參與Data Guard 配置中。

Failover

Failover用于更改備庫到主庫角色以響應原主庫的故障，如果主庫在故障之前沒有運行在最大保護模式或最大可用性模式下，可能發生數據丟失。如果在主、備庫都允許閃回數據庫，只要故障解決了，原主庫可恢復作為新主庫的備庫。

1.1.1 角色轉換準備工作

角色轉換前，需要做好以下工作：

1.確保主備庫已經正確配置

關于Data Guard 配置的參數、歸檔模式、standby日志等的配置參詳http://blog.csdn.net/u010257584/article/details/51140030，這里略過，standby庫的LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_STATE_n必須配置，這樣角色轉換后，才能接收從新的primary庫傳過來的REDO數據。

2.查詢V$ARCHIVE_DEST_STATUS，確保standby庫沒有REDO傳輸錯誤以及REDO GAPS，比如查詢LOG_ARCHIVE_DEST_2：

SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID =2;

當STATUS的值為VALID、GAP_STATUS為NOGAP方可進行下一步。

3.確保主備庫的臨時文件一致。

4.刪除重做應用的所有延遲，因為這可能會影響備庫轉為主庫角色。

5.RAC主庫轉為物理備庫，務必先只保留其中一個RAC實例為OPEN狀態，其他的實例都關閉，其他關閉的實例待轉換結束后可以重新聯機。

6.即使在切換期間備數據庫上只有一個RAC實例是打開的，所有其它備數據庫實例在打開時，還將自動經歷一個正確轉換到它們的新角色的過程。

7.對于運行在real-time查詢模式下的物理備庫，執行角色轉換之前，可以將備庫的所有實例啟動到mounted而不是open狀態，這樣可以實現最快的角色轉換，并且能在角色轉換之前完全終止所有連接到物理備庫的用戶會話。

1.1.2 選擇角色轉換的目標備庫

對于多備庫的Data Guard配置，角色轉換時選擇目標備庫需要考慮諸多因素，包括：

1.備庫的位置與備庫類型

2.備庫的能力（硬件規格，如CPU數目、可用I/O帶寬等）

3.執行角色轉換所需的時間，這受備庫重做數據的應用快慢，以及數據丟失情況下應用程序的可用性。

角色轉換目標備庫的類型決定了轉換后配置中其他備庫的角色。對于physical備庫，其中一個備庫轉為primary角色，配置中所有的其他的備庫都將變成新primary角色的備庫。而對于logical備庫，其中一個備庫轉為primary角色，配置中所有的其他的備庫都將變成新的primary角色的備庫，但是該配置中的物理備庫將繼續作為舊的primary主庫的備庫而不保護新的主庫。對于后一種情形，如果進行Switchover或者Failover切換回原始主庫，那么當前新主庫的所有備庫將變回原始的角色狀態。綜上所述，對于包含物理與邏輯備庫的配置中，物理備庫是最佳的角色轉換目標。

Data Guard提供了V$DATAGUARD_STATS視圖，該視圖包括每個備庫的數據流量估值、執行角色轉換所需的時間（當所有redo數據都已應用到備庫）。

例如：

SQL> COLUMN NAME FORMAT A24

SQL> COLUMN VALUE FORMAT A16 
 
SQL> COLUMN DATUM_TIME FORMAT A24

SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS;

查詢結果顯示，備庫接收并應用了主庫傳來的所有的redo數據。transport lag、apply lag的值是通過主庫傳來的redo數據估算的，如果主備庫之間的連接出現過中斷，那么這個值就沒有意義。transport lag、apply lag對應的DATUM_TIME列的值如果沒有變化，表明它們沒有被更新，已經無意義，很可能是因為主備庫之間的通信出現了中斷。

1.1.3 Switchover

Switchover通常用于減少計劃內的中斷過程中主庫的停機時間，比如操作系統或者軟件的升級，以及Oracle數據庫軟件或者補丁的滾動升級。

Switchover分為2個階段，第一階段，現有的主庫轉換為備庫角色；第二階段，備庫轉為主庫角色。

如下，主庫為San Francisco，備庫為Boston，轉換前的data guard配置：

當原始主庫已轉換為備庫，但原始備庫還未轉為新的主庫，Data Guard環境如下：

當原始備庫轉換成新的主庫，也就是主庫變成了Boston，備庫變成了San Francisco，Data Guard環境如下：

Switchover之前，以下2點必須滿足：

對于物理備庫的切換，確保主庫是打開的，而且備庫的REDO應用處于active狀態的；

對于邏輯備庫的切換，確保主備庫的實例都是打開的，并且SQL應用時active狀態。

1.1.4 Failovers

當主庫不可用，并且不可能在一個合理的時間內恢復它，Failovers就派上了用場。Failover執行的具體操作取決于是否有邏輯與物理備庫涉及的故障、故障轉移時Data Guard的配置狀態，以及啟動Failover時具體的SQL語句。

Failover San Francisco主庫到物理備庫Boston，結果如下：

再進行failover之前，如果可以，盡可能將所有可用而未被應用的主庫redo數據傳至備庫。

failover角色轉換其他的前提條件如下：

如果備庫運行在最大保護模式下，請先更改為最佳性能模式：

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

轉換結束后，可以根據需要重新設置備庫運行模式。

轉換備庫的運行模式是因為備庫運行在最大保護模式下不能進行failover操作，另外，如果主庫運行在最大保護模式下，并且和備庫還在通信的狀態下，更改備庫到最佳性能模式的SQL操作將不能成功。因為failover操作將主庫移出了dataguard配置，這些特性意在保護運行在最大保護模式下的主庫免受意料之外的failover操作。