Oracle Data Guard 就是為 Oracle Database 建立一個 Standby Database 作為備援之用，當 Primary Database 發生問題或損毀時，還有 Standby Database 可以使用。不論是 Primary Database 或者是 Standby Database 都可使用 Single Instance 或者是 RAC ，所以組合起來總共有四種搭配:
RAC 是由兩台或以上的 Server 來支撐一個資料庫，當其中一個 Server 發生問題還有其它 Server 可以提供服務，而 RAC 的 Server 之間是會放在同一個機房 (Extended RAC 除外) ，因此 RAC 的功用比較像是本地的備援，而 Standby Database 一般都會建立在非本地機房作為異地備援之用，避免本地機房發生不可預期事件造成資料庫損毀並且無法復原時，還有異地的資料庫可以提供緊急使用，在上述的四種搭配當中，對資料庫最好的保護當然就是本地端以及 Standby Database 都使用 RAC ，不過相對的所需付出的硬體成本較高，其次可以選擇本地為 RAC 而 Standby 為 Single Instance ，以節省硬體成本，同時也達到資料庫保護的作用。
Standby Database 不僅僅是只有備援的用途， 它還可以開啟為唯讀模式 (Read Only) ，只有使用 Select 的作業可以將其導到 Standby 端執行，當成報表伺服器使用，或者是資料庫備份也可以由 Standby 端進行備份，這些運用都可以分擔 Primary Database 的負載。
Data Guard 的概念是將 Primary 端的交易日誌 (Redo / Archive Log ) 透過 Oracle Net 傳送到 Standby Database ，然後 Standby 再 Apply 這些交易的異動來達到兩邊資料庫數據的一致， Oracle 資料庫必須為企業版才可以使用此功能，以類型來說可以分為 Physical Standby 與 Logical Standby 兩種 :
Physical Standby : 使用 block-for-block basis 的方式，透過接收 Primary 的 Redo Log 並且進行 Redo Apply (Recover) 來達到與 Primary 數據的一致。
Logical Standby : 透過接收 Primary 的 Redo Log 並且利用 LogMiner 將 Redo Log 的內容轉換為 SQL 語句，然後在 Standby 執行這些 SQL 語句 (SQL Apply) 來達到與 Primary 數據的一致
這兩者最大的不同是， Physical Standby 使用的是 Redo Apply ，由於是屬於 Block Level ，因此 Physical Standby 不允許與 Primary 產生不一致的現象， Physical Standby 只能開啟為唯讀模式 (Read Only) 避免資料的異動；而 Logical Standby 使用的是 SQL Apply ，此時 Logical Standby 必須是讀寫模式 (Read Write) 才可進行 SQL Apply ，由於是讀寫模式，因此 Logical Standby 的資料是有可能被異動的，具有與 Primary 不一致的風險，所以在資料保護的前提之下，大部分的情況都是選擇使用 Physical Standby 以確保與 Primary 的一致性。
除此之外，有一種比較特殊的模式稱作 Snapshot Standby ，這個是 Oracle 11g 開始的新功能，必須在 Physical Standby 的基礎之下才能轉換為 Snapshot Standby ，原本的 Physical Standby 只能以 Read Only 開啟，不過轉換為 Snapshot Standby 之後便可以 Read Write 模式開啟，主要的用途是讓 Standby Database 可以暫時性的進行讀寫，以實際的行為來驗證 Standby Database 的資料是否正確以及功能是否正常。在轉換為 Snapshot Standby 的時候， Standby Database 會自動 Enable Flashback Database 功能並且建立 Restore Point ，在結束 Standby 的驗證之後將 Snapshot Standby 轉換回 Physical Standby 時，便會使用 Flashback Database 的技術將 Standby 回退到當初建立 Restore Point 的時間點，然後再由這個時間點開始進行 Physical Standby 的資料同步， Snapshot Standby 可以說是多提供了一種 Standby Database 的運用方式。
Oracle 11g 除了 Snapshot Standby 的新功能外，另一個新功能就是 Active Data Guard 。傳統 Physical Standby 的 Redo Apply 是藉由不斷的 Recover 這些交易日誌檔來進行資料同步，而資料庫必須處在 mount 模式下才可以進行 Recover ，如果要將 Standby 開啟為 Read Only ，必須停止 Recover 才能夠開啟，不過這個時候 Standby 的資料就停止在這個時間點，而 Active Data Guard 指的是 Standby 在 Read Only 模式下仍然可以進行 Redo Apply (Recover) 的動作，也就是 Standby 開啟至 Read Only 提供查詢服務時，資料仍然是不斷的在更新的，這對於想充分運用 Standby 的使用者來說無疑是一大福音，當 Standby 使用的是 Active Data Guard 模式，在 v$database 裡面的 open_mode 會顯示為 "READ ONLY WITH APPLY" 。
對於資料保護的強度來說， Data Guard 總共有三種模式，最大保護模式 (Maximum Protection) 、 最高可用性模式 (Maximum Availability) ，以及最高性能模式 (Maximum Performance) :
最大保護模式 (Maximum Protection) : 確保 Primary 與 Standby Database 的資料必定完全相同，而且 Standby 不會有任何的資料遺失，在此模式下當 Primary Database 進行 commit 的動作時， commit 會等到這個交易日誌傳送到 Standby 端，並且 Standby 端必須反饋回 Primary 表示已經收到並確認這個交易日誌，此時 Primary 的 commit 動作才會完成。這個模式的好處是 Standby 的資料不會遺失，壞處是當 Standby 不可用時就無法反饋訊息給 Primary ，此時 Primary 的 commit 動作便會無法完成而發生 Hang 的現象，嚴重時也可能導致 Primary Database Crash 。
最高可用性模式 (Maximum Availability) : Primary Database 進行 commit 的動作時， commit 會等到這個交易日誌傳送到 Standby 端後， commit 的動作才會完成，與 Maximum Protection 不同的是， Maximum Availability 不會等到 Standby 端反饋回來，而是 Primary 主觀的確認交易日誌有傳送到 Standby 端便完成 commit 的動作。這個模式的好處是比 Maximum Protection 稍微有彈性一點，壞處是當 Standby 不可用時， Primary 無法單方面確認交易日誌是否能傳送到 Standby 端時，仍然會影響到 Primary Database 的交易，另外由於此模式是不等 Standby 的反饋訊息，因此雖然 Primary Database 主觀認定交易日誌有傳送，但是 Standby 端有可能沒收到，所以還是有一點點的資料遺失的風險在。
最高性能模式 (Maximum Performance) : 這個是 Data Guard 的預設模式， Primary 進行 commit 的動作不會確認交易日誌是否傳送到 Standby 端， Standby 端也無須反饋收到日誌的訊息，這個模式的好處是整個 Data Guard 機制完全不會影響 Primary Database 的運作，壞處是交易日誌沒有傳送到 Standby 端的話， Standby Database 會有資料遺失的風險。
由於我們建立 Standby Database 主要的目的是在多增加一個資料庫的保護，在這個機制下並不希望會影響原本 Primary Database 的運作，因此多數的情況都是使用預設的 Maximum Performance 模式，雖然此模式會有資料遺失的風險，但相較於 Primary Database 的正常運行， Standby 的重要性還是擺在第二順位的。由於 Maximum Protection 與 Maximum Availability 對於 Standby Database 都有高度的依賴性，因此 Primary 與 Standby 的開關順序就很重要，在這兩個模式下，資料庫開啟的順序必須是 Standby 與 Standby 端的 Listener 先啟動，然後再開啟 Primary ；而資料庫關閉的順序則是要先關閉 Primary 之後再關 Standby ，在 Maximum Performance 下則是兩者之間的開關沒有要求一定的順序。
Data Guard 預設都是 Maximum Performance 模式，如果要使用 Maximum Protection 或 Maximum Availability ，則必須在 Primary 端使用 alter database 更改 :
這邊要注意的是， Maximum Performance 不能直接切換為 Maximum Protection ，必須先切換成 Maximum Availability 才能再切換至 Maximum Protection 。
Data Guard 的 Primary Database 與 Standby 兩者的角色可以互相轉換，轉換模式有兩種， Switchover 與 Failover :
Switchover : Primary 與 Standby 的角色互換，原本的 Primary Database 轉換為 Standby ，而原本的 Standby 轉換為 Primary ，兩者角色互換後繼續進行資料的同步， Data Guard 的機制不會因為角色的轉換而有所改變。當 Primary Database 需要短暫的進行停機維護時，就可以利用 Switchover 將主庫切換為 Standby 端，等到維護結束後再切換回來。
Failover : 這個模式主要是將 Standby Activate 起來變為 Primary ，當 Standby Activate 之後， Data Guard 的機制就被破壞，原本的 Primary 與 Standby 關係就不存在了， Failover 主要的用意在於當 Primary 發生問題並且不可用時，緊急的將 Standby Activate 起來作為 Primary 所用，以確保服務能夠在短時間內恢復。由於 Failover 已經破壞原本 Data Guard 的機制，所以要恢復 Data Guard 的話， Standby 端就必須重建。
資料庫是應用系統存放資料的地方，可以說是整個系統架構下最重要的部分，資料庫的保護顯得相當重要， Data Guard 在實務上已經被廣泛地運用，作為一個 Oracle DBA 必須要相當熟悉這個架構。
沒有留言:
張貼留言