資料庫災難回復機制第1回——資料庫的高可靠性

資料庫是企業儲存資料的地方，當資料庫停止提供服務，應用程式即無法讀取資料庫的資料，資料也無法寫入資料庫，輕則造成應用程式無法正常運作，若是關鍵應用程式運作受影響，重則造成公司及企業營運的停擺，甚至因而影響供應鏈中上下流企業的整合系統，進而間接造成整體供應鏈作業的延遲，因此在供應鏈運籌帷幄的今天，如何減少資料庫停機的次數，並在停機發生後，降低停機時間，以保持資料庫系統能提供7×24全年無休維運，則是資料庫系統維護的重點訴求。

叢集式架構
在最早期的建置規畫上，資料庫系統架構會採用單一的instance來讀取一個實體的資料庫（如圖1），若Host 1主機無法提供服務時，在這樣的架構下，主機Host1上的instance也就無法正常的運作；此時即使儲存在儲存媒體內的資料庫檔案（Data Files）完好無缺，資料庫系統也是無法提供服務，因此，如何在最短時間內快速置換Host 1主機置換下來，並重新配置一臺可以正常提供服務的主機，以回復資料庫的正常維運，這就是高可靠度（HA，High Availability）設計所關心與討論的議題。

為了解決上述的問題，有些企業會採用叢集（Cluster）式的解決方案，在原來的架構中，再多配置一臺待命（standby）的主機，當運作中instance無法提供服務的時候，則自動將待命（standby）的主機轉換成運作中的主機並且提供服務，以縮短服務停止的時間。不過，由於切換的過程中資料庫系統是停止資料存取的服務，因此，資料庫系統服務停止的問題仍無法避免。

RAC架構
但隨著高可靠度（HA）標準的提高，企業可以接受的資料庫系統停止服務的時間也越來越短（甚至希望可以完全不停機）。在資料庫系統的RAC（Real Application Cluster）技術以及系統叢集技術發展成熟與穩定的今天，大多數的企業為了保障資料庫的服務不停止，則會採用如圖2的這種架構，藉由2臺或3臺以上的主機（每臺主機上都有自己獨立的instance）來同時提供服務。

這些主機內的instance在實體上對應同一個資料庫檔案（單一的一組資料庫系統及資料檔案data files），以保障資料來源及資料儲存的一致性，並且為了避免因使用者在使用「新增」、「修改」、或「刪除」等DML指令後，這些instance彼此暫儲在各別buffer中的資料內容不一致，資料庫系統還要主動溝通協調各個主機，讓所有的instance會自動且即時地將自身所更改或新增的資料，通告其它的instance，以保障所有instance的資料緩衝區的共同資料內容是一致的（不同的instance中buffer所暫儲到的資料並不一定一樣，所以理論上資料庫系統只針對共同擁有的資料來進行內容的同步），如此則可讓所有的主機同時提供服務，並且確保在不同的主機上讀取到的資料的一致性。

當其中一臺主機無法提供服務（例如，Host1主機損毀）時，由於在整個資料庫系統中，其它的主機還是正常的運作並提供服務（例如，Host 2主機上的instance還在正常地提供服務），所以幾乎可以說整個資料庫系統的服務不會停止（停機時間幾乎等同於零），因此這樣子利用多個instance同時對應一個實體的資料庫提供服務的做法，同時大幅度提升了資料庫系統的延展性(Scalability)及可靠性(Availability)。

儲存媒體損毀怎麼辦
利用RAC以及叢集技術在不同的主機上各別建立instance，可以在主機損毀時保障資料庫系統服務的不受影響，但這樣的做法並無法避免所有類型的災難，以圖3為例，當儲放資料庫檔案的儲存媒體發生問題時，所有instance也就無法讀取或寫入資料庫檔案，因此資料庫系統即無法提供服務（此時有再多的多主機instance的規畫也沒用）。

這樣的停機時間會有多長呢？除了估評修復儲存媒體所需的時間以外，也需要估評資料庫系統檔案的回復（Restore）與復原（Recovery）所需時間時間；而且隨著資料庫系統的成長，回復資料庫檔案所需時間也相對地變長，資料庫系統的停機時間也就相對地增長了。

資料庫管理員的課題
其實，不論資料庫系統本身所規畫的架構為何（單一個instance、叢集式Active-Standby、或是RAC式Active-Active的架構），當儲存媒體的存取不正常，資料庫系統的服務也就相對受影響，甚至會停止服務。

因此，如何在儲存媒體發生損毀後，減少資料庫系統的停機時間，以強化資料庫系統的高可靠性？資料庫管理者要思考如何在儲存媒體損毀的時候立即再重新配置一個儲存媒體（或者在災難發生前，就先配置好），並縮短資料庫系統回復與復原的時間，以便在災難發生後於最短時間內再重新提供資料庫系統的服務。

Oracle與RAC
RAC的做法可以說是一種Oracle Instance Redundancy的概念。讓兩個以上的instance 同時提供服務，當一個instance無法提供服務時，資料庫系統還是可以正常提供存取服務。不過，在實做上仍然需要應用程式端配合修改。

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