資料庫災難回復機制第2回——探究資料庫快閃復原策略

不論資料庫系統架構為何，無法正常存取儲存媒體的資料時，資料庫系統的服務就會停止。是故我們必須思考如何在儲存媒體損毀的災難發生時，減少系統停止服務的時間，以強化資料庫系統的高可靠性。

資料庫階層式備份策略
不論使用者選擇了哪一種資料庫備份方式（RMAN、Alter tablespace、begin backup、或冷備份），資料庫系統災難復原的工作主要在於「資料庫回復（restore）」及「資料庫復原（recovery）」兩個部分，縮短這兩個部分所需時間，即是縮短資料庫停機時間的關鍵。其中資料庫回復是指將過去某個時間點所備份的資料檔案（data files），重新存放回資料庫系統所配置的目錄路徑與檔案名稱上；而資料庫復原即是指利用過去歷史的資料交易紀錄檔案（redo log以及archive log），將所回復的資料庫復原到離災難發生最近的時間點。

過去為了節省硬體成本的支出，許多的企業會以磁帶來備份資料庫。通常是定期一個禮拜或每天備份一次；不過由於磁帶讀寫速度較慢，所以備份時間比較長，找尋資料檔案的時間較長，由磁帶來回復資料的時間也相對較長，因此資料庫系統的停機時間會增加，而且隨著資料量增加情況會更嚴重。

在預算充足的情況下，為了縮短資料庫停機時間，一般會建議平時先將資料檔案備份到讀寫速度比磁帶還要快的磁碟系統，如此不論是備份或是回復都比較快，因而停機時間也會縮短，而後再依企業的需求定期將磁碟系統的歷史資料備份到磁帶保存。

資料庫快閃復原方式
Oracle便將上述的備份資料儲存區，納入Oracle Database 10g資料庫管理系統，稱為Flash Recovery Area。

在Oracle 10g Database使用dbca（Database Configuration Assistant）建立一個資料庫的過程中，預設要啟動Flash Recovery Area這項功能，資料庫管理員必須為Flash Recovery Area配置儲存路徑及空間（若是儲存在磁碟儲存系統，就是指定磁碟儲存系統的路徑及儲存空間），而資料庫系統回復與復原的策略及方法也將隨之調整。

資料庫系統災難復原時，由於Flash Recovery Area上已有一組完整的資料庫檔案備份，其與運行中的資料庫檔案的差異，就是兩者時間差之間的資料交易異動，假如，資料庫管理員在2月5日做了一次資料庫系統的完整備份，而當資料庫持續運行到2月15日時，運行中的資料庫資料檔案，與2月5日所備份的完整備份，其資料差異就有10天的時間差。而Archive log檔案會記錄所有的資料交易記錄，理論上如果能在災難發生前將Archive log檔案所記錄的資料交易異動，先套用到已經執行的資料庫完整備份檔案，如此可以縮小備份檔與現行資料檔的差異，就能縮短資料庫復原時間。如前述，2月15日系統發生故障導致資料庫系統停機，如果我們事先剛好在2月14日，將2月5日至2月14日這9天來的資料差異套用至2月5日所製作的完整備份，如此一來，理論上我們會有一份最新的2月14日的完整備份，若2月15日系統故障，我們手上擁有的完整備份與災難發生的時間差就只有1天，因此資料庫系統要回復這1天的時間差所造成的資料異動，絕對會比回復10天來的資料異動還要快速。

Oracle自Oracle Database 10開始提供Flash Recovery Area這樣的備份策略，10g之後的版本，都可以利用RMAN來備份一組完整的影像備份（image copy），並存於Flash Recovery Area所在的儲存媒體中，平時災難未發生時，定期或不定期執行復原以縮小資料時間差的差異，就能縮短災難發生後所需要的資料庫復原時間。

在Oracle Database 10g以前的版本，資料庫系統所提供的RMAN（Recovery Manager）工具只能夠復原現行的（有自己獨立instance 的）資料庫檔案。

災難發生時快速轉換資料庫
縮短資料庫復原時間，是否就代表資料庫備份策略已經完美無缺呢？其實還有個重點不能被忽略：儲存媒體發生故障。不論資料庫本身的復原設計可以如何地縮短時間，資料庫本身儲存資料檔案的儲存媒體故障就沒輒。因此整個資料庫備份策略還要從根本思考儲存媒體的回復或備援方案。

或許有讀者已經想到了，能直接用Flash Recovery Area的備份資料檔來替代嗎？ 由於Flash Recovery Area中已經有一份完整的資料庫檔案備份，再加上利用RMAN定期或不定期地補足與現行資料庫的資料內容差異，在災難發生時，直接用這份完整的備份來啟動資料庫，不謹同時解決儲存媒體損毀的問題，甚至也可節省連資料庫回復與復原的時間。

就備份策略的考量，上述做法能將資料庫服務停機時間降到最短，因為在整個資料庫檔案轉換的過程中，不需要複製任何的實體檔案。（不過就操作面而言，應該至少要再做一次recovery，以儘量把資料庫的備份時間點拉近災難發生時間點。）

結論
因此，不論採行何種資料庫可靠度架構，資料庫管理員思考資料庫備份策略時，仍必須考量軟硬體、人為、及天災等不可預期的因素，全盤考量造成資料庫系統停機的風險，並採取任何能盡量縮短停機時間的措施，對於要求高可靠度、不允許停機時間的應用而言，快閃復原技術能補強資料庫系統的高可靠度。

以磁帶備份資料庫面臨瓶頸
過去，一個資料庫的資料量頂多是用Gigabyte來計算，或許只有幾Gigabyte的資料量，所以備份或回復所需要的時間還是可以被接受；如今，隨著資料庫應用的廣泛，很多企業的資料量可以成長到幾百個Gigabyte，而且也達到Terabyte等級－幾十個Terabyte，甚至更大，而對於這種巨型的資料庫而言，它所需要的備份與回復的時間也相對的劇增。因此，使用磁帶來備份，不僅面臨讀寫速度的瓶頸，隨著資料庫系統越來越大，磁帶備份也將面臨儲存容量的瓶頸。

差異備份整合並非縮短回復時間
Oracle Database 10g之後的版本，就可以利用RMAN來備份一組完整的影像備份（image copy），並存於Flash Recovery Area中，平時災難未發生時，不定期執行復原以縮小資料差異，就能縮短災難發生後所需要的資料庫復原時間。

這樣子的做法實際上並不是由縮短資料庫回復（recovery）時間來下手，而是將災難發生後所需要做的差異備份整合至完整備份的事，先在災難未發生前就先執行。所以，整體加起來所需要時間極有可能是一樣的，只不過，我們事先先做了準備，所以到時候災難發生，這一部份時間則可說是節省下來了。

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