資料庫災難回復機制第3回——2種資料庫備援機制比較

前一期的文章中，我們以Flash Recovery Area來說明資料庫快閃備份技術。對於熟悉Oracle資料庫災難回復的讀者而言，一定會想到另一種復原方式──Data Guard。我們就以這2種機制為例，比較一下不同的資料庫復原機制的差異。

Oracle Data Guard簡介
Oracle Data Guard的設計主要是根據修復資料庫而來，需先準備一組環境雷同的系統（該系統環境會有自己獨立的主機及儲存媒體），做為備援的資料庫服務系統。這個備援的資料庫服務系統有獨立的instance（稱為standby instance），平時（recovery模式下）負責接收營運中的資料庫系統的交易內容差異記錄（記錄時間差的資料差異），並依資料庫管理師的規畫，定期地補足（apply）差異資料，讓備援資料庫的資料內容維持最新，減少與營運中資料庫的差異程度。

當營運中的資料庫損毀時，資料庫管理者就可以直接改變備援資料庫的狀況，讓Instance由原先的Standby Mode轉換為Open Mode（不過，實務上大多數人還是會試著再做一次到兩次的資料復原），此時資料系統即可提供正常的服務了。

上述的作法與叢集架構下的待機設計不同，叢集架構下必須共用儲存媒體，因此叢集的「Fail over」主要是針對主機損毀時的轉移，若儲存媒體嚴重毀損，還是有可能造成資料庫系統服務必須長時間停止；但在Data Guard的架構下，待命中的資料庫是獨立於營運中資料庫之外的（不論是Host主機或是儲存媒體），因此災難發生時（不論問題點發生在Host主機或是儲存媒體上），Data Guard架構下的「Fail over」則是指整座資料庫服務系統（主機及儲存媒體）的轉移，是故若要預防因儲存媒體的災難而導致的資料庫系統停機，Data Guard與Flash Recovery Area都能達到縮短停機時間的要求。

作業模式比較
Data Guard需先在備援的儲存媒體中存一份完整的資料庫檔案，不過在概念上，Data Guard所使用的儲存空間隸屬於備援主機（不同於營運中資料庫的儲存空間），而Flash Recovery Area與營運中資料庫檔案所存放的儲存媒體則同時隸屬相同的主機。

所以概念上Data Guard的作法是利用主機與主機所連接的網路，將資料庫檔案（Data file、Control file、redo log file以及記錄時間差的異動資料的Archive log file）傳送到備援的儲存媒體上面；若採行的是Flash Recovery Area備份策略，則是在同一個主機下搬移檔案或區塊（block）。因此在一般的情況下，Flash Recovery Area傳送資料庫檔案的速度會比Data Guard快，而在災難發生的時候，Data Guard可能遺失的資料量因而相對地可能比Flash Recovery Area多。

功能比較
Data Guard自Oracle Database第7版時提出的方案（那時名為Standby Database），因此發展至今，不論是在管理工具或是功能的成熟度上都較為完善，因此管理Data Guard會比Flash Recovery Area來得容易。就整體備份策略而言Flash Recovery Area是一個不錯的想法，實務上筆者自己測試過也沒有問題，不過，可能這是Oracle Database 10g才提出的做法，目前在資料庫管理面上的某些細節， Oracle 並沒有提供相對應的功能，因此，在實做上，如果要達到比較完善的管理，還是需要輔寫一些OS script或是PL/SQL。

架構比較
Flash Recovery Area的備份建議策略是用RMAN（Recovery Manager）復原資料庫備份檔案；而Data Guard則需起一個instance，並讓它在Automatic Recovery Manager Mode下，來將營運中資料庫所傳送過來的Archive log file，進行備援資料庫的復原。

Data Guard的模式，會建置另一臺主機，讓Standby Instance獨立運作，因此，若營運中的資料庫同時只以一臺主機、一個instance提供服務（並且沒有其他叢集備援主機）的情況下，適合採用Data Guard 方案。若資料庫系統同時有兩個或以上的instance，就可以考慮採用Flash Recovery Area的備份策略，讓Flash Recovery Area的儲存媒體來扮演備援儲存媒體的角色，來縮短因儲存媒體所產生的停機時間。

系統需求比較
在儲存空間上，基本上兩種解決方案都需要先有一組完整的資料庫檔案備份，以及儲存Archive log files的空間，因此兩者差異不大。不過，Flash log也必須存放在Flash Recovery Area（供資料庫等級的Flash Back使用），實際上Flash Recovery Area所需硬碟空間會多一點。

在記憶體的使用上，Data Guard由instance負責資料庫復原，因此基本上要建置備援資料庫，最少需要256 MB的記憶體空間（如果還需要Enterprise Manager，要再加上256MB）。而Flash Recovery Area是利用RMAN來完成，理論上不需要太多額外的記憶體空間，只要給與營運中資料庫instance中的Large Pool足夠的記憶體空間即可。因此，在記憶體資源的使用上，Data Guard會比Flash Recovery Area高很多，在多臺線上資料庫系統同時運轉，而共用使用一臺備援主機的情況下，記憶體佔用量大會更為明顯。

除此，前面已經提過，如果使用Data Guard的話，一般建議建置在另一臺主機上（不過，當然可以有多組線上資料庫共用一臺備援主機）。因此Data Guard的建置至少會多出主機的成本支出；而Flash Recovery Area則沒有。

備援距離比較
Data Guard模式下，營運中資料庫與備援資料庫兩者間透過網路溝通、傳送與補足資料內容交易記錄，所以在網路穩定的前提之下，Data Guard可以提供距離較長的資料庫備援機制。

在Flash Recovery Area模式下，一般會建議儲存媒體透過SCSI介面或是SAN儲存區域網路連結，因此距離上的彈性比網路低；對於遠距離的資料庫系統備份回復機制（異地備源），Data Guard則會是比較好的選擇；而對於本地端的資料庫系統備份回復機制，在妥善的規畫下，可以考慮使用Flash Recovery Area的備份策略來取代。

從備援的角度思考，Flash Recovery Area Standby著眼點只在儲存媒體上面，而Data Guard除了儲存媒體之外，還有自己獨立的主機與Instance。所以，對於尚未有Instance Standby或備援架構的資料庫服務系統而言，以Data Guard建制資料庫災難回復機制會是比較好的選擇；相反的，當資料庫服務系統已經有建制規畫妥善的Instance Standby或備援機制時，在成本考量下，可以使用Flash Recovery Area。值得一提的是Flash Recovery Area是資料庫備份策略的一部分，而Data Guard則是著重於異地備援的考量，因此在整體資料庫系統架構的規畫上，資料庫管理者應先思考資料庫備份的策略，再來考慮資料庫的異地備援。

Non-Cluster Standby Database
雖然Cluster與Oracle Data Guard所提出的「standby database」都是指一個待命中的資料庫，可以在災難發生的時候來取代運行中的資料，但由於所採用的技術方法不同，所能面對的災難也不相同，因此為了區分兩者，有些管理者則會稱Oracle Data Guard的待命資料庫為「Non-Cluster Standby Database」。

《作者簡介》杜奕鋒
艾群科技技術顧問，畢業於中央大學。
專精於商業流程設計、資料庫管理、T-SQL及軟體整合，通過OCP(8i/9i)、RHCE、SCSA、SCNA認證。曾任職於104人力銀行，負責eHRPortal及WorkFlow系統整合；曾任職於紡拓會，負責紡織業ERP系統導入；亦曾擔任臺灣護理學會系統整點導入顧問。並曾任教於關渡基督書院、永達技術學院。