我常常在想，如果數(shù)據(jù)庫不用考慮數(shù)據(jù)恢復，對我們這些做數(shù)據(jù)庫的人來說，日子也許將變過美好很多。
　　沒有一種軟件會象數(shù)據(jù)庫這樣，需要面對如此惡劣的環(huán)境。你需要考慮各種可能的錯誤和故障，例如系統(tǒng)斷電、磁盤損壞、甚至是地震火災。而給你的目標非常明確：不論發(fā)生何種故障，數(shù)據(jù)都不能被丟失，你可能覺得這有些小題大做，可對于許多商業(yè)應用（如銀行、火車訂票系統(tǒng)等）來說，這只不過是最基本的要求。
　　要保證每一步操作都不會丟失，既無必要，也無可能（除非你能發(fā)明一種和硬盤一樣大，和內(nèi)存一樣快，同時斷電時數(shù)據(jù)不丟失的東東）。因此同并發(fā)控制中一樣，數(shù)據(jù)庫同樣也利用了事務的概念。事務是這樣一組操作，這組操作要么都做，要么都不做（我們通常把這叫做事務的原子性）。而當你決定結束一個事務時，你可能會選擇：是提交（COMMIT）這個事務，還是應該滾回（ROLLBACK）它。如果你選擇提交，那么你在這個事務中所做的全部修改都會被存入數(shù)據(jù)庫中，如果這個數(shù)據(jù)庫系統(tǒng)足夠強壯，它將保證：只要事務提交完成，不管今后發(fā)生何種故障，事務所做的修改都不會丟失。如果你選擇滾回，那么系統(tǒng)將回到事務開始的狀態(tài)，你在該事務中所做的所有修改都將丟失。如果在事務運行當中，系統(tǒng)發(fā)生了任何故障，你會期望它的結果應該和你滾回這個事務一樣。
　　恢復的本質是數(shù)據(jù)的冗余，在眾多的冗余手段中，日志（log）也許是我們最常使用的技術（盡管我們還有許多其它的選擇，如影子頁面等）。在我們對數(shù)據(jù)庫進行修改之前，系統(tǒng)會將數(shù)據(jù)修改前的影象（前項）和你要修改的數(shù)據(jù)影象（后項）保存在日志當中。在這個過程中，有兩點需要保證。一是日志必須先于它對應的修改被寫入數(shù)據(jù)庫，我們把這叫做先寫日志（WAL）協(xié)議，這很容易理解，想象一下，如果修改被先寫入數(shù)據(jù)庫，而系統(tǒng)在日志被寫入之前崩潰了，那么它將無法把該事務恢復到開始的狀態(tài)。二是在事務提交之前，必須將它的日志寫入數(shù)據(jù)庫。否則，系統(tǒng)無法保證后續(xù)的故障不會丟失該事務的修改。我們將不能實現(xiàn)我們在前面對用戶所做出的承諾。
　　我們繼續(xù)上文的討論，看看我們到底有哪些故障需要應付。
　　首先是應用故障，例如用戶不小心錯刪了一張表，或者應用破壞了完整性約束。這種故障的恢復非常簡單，對于前者，你可以顯式地滾回事務（利用日志的前項），如果你不小心提交了事務，那么問題就麻煩了，系統(tǒng)也許只能把它當作介質故障（利用備份）來恢復了；對于后者，系統(tǒng)會強迫把該事務滾回。只要數(shù)據(jù)庫還在運行，在系統(tǒng)看來，事務的滾回與其它正常操作并沒有什么區(qū)別。
　　然后是進程故障，假如在系統(tǒng)運行時，一個client崩潰了，或者網(wǎng)絡斷了（通常服務器無法區(qū)別這兩種狀態(tài)）；或者服務器端的某個進程死了。這時我們恐怕得為系統(tǒng)配置一個監(jiān)視進程，由它來定期地檢查系統(tǒng)狀態(tài)，恢復或清除失敗的進程（連接），同時把對應的事務滾回。我們會希望這個監(jiān)視進程是所有進程的父進程，因此假設連它也死了，我們就能把這種情況歸結到后面將要討論的系統(tǒng)故障。
　　接著是系統(tǒng)故障，假如系統(tǒng)因為內(nèi)部錯誤（例如數(shù)據(jù)庫或操作系統(tǒng)含有bug），或者發(fā)生斷電。這時緩沖區(qū)里的數(shù)據(jù)全部丟失，但幸運地是磁盤上的數(shù)據(jù)還在。因此系統(tǒng)在重新啟動（RESTART）后，首先重做所有事務的修改（利用日志的后項），這就讓數(shù)據(jù)庫回到了發(fā)生故障時的狀態(tài)，這時再將所有在這一點上未提交的事務滾回就完事了。注意這一過程是自動完成的，你完全不需要去關心它。
　　再接著是介質故障，假如磁盤出現(xiàn)了壞磁道，或者整個磁盤報銷了。這時上面的數(shù)據(jù)肯定已經(jīng)丟失了。由于介質故障只能在你試圖再次存取磁盤時被發(fā)現(xiàn)，而這時故障可能早已發(fā)生。因此對介質故障的恢復需要你的參與才能完成。你必須定期地備份（BACKUP）數(shù)據(jù)庫，這樣，當介質故障發(fā)生時，你可以先用備份重新覆蓋整個數(shù)據(jù)庫（RESTORE過程），然后利用日志重做從備份那點到當前的數(shù)據(jù)庫的更新（ROLL-FORWARD過程），接下來的事情就和系統(tǒng)故障完全一樣了。你可能會問，那要是日志也壞了怎么辦呢？沒辦法，雞生蛋、蛋生雞，總得有個頭吧。所以你最好祈禱日志不要壞，為了保證這一點，你應該對日志文件進行鏡象，或者干脆用RAID。
　　除了這種恢復方式，我們還有一種叫做邏輯恢復的方式，也就是利用我們常常在用的IMPROT/EXPORT工具對數(shù)據(jù)進行備份/恢復。當然我們只把它看作是介質故障恢復的一種輔助形式（也許它更適合于恢復我們前面說的那種應用故障），因為你只能把數(shù)據(jù)恢復到你備份的那一點。
　　最后是災難，象發(fā)火災、被人黑了什么的，這時整個系統(tǒng)可能被完全破壞。你當然仍然可以對數(shù)據(jù)庫進行備份，然后把備份（磁盤）放到另一個安全的地方，但這樣做，備份以后數(shù)據(jù)庫所做的修改可能就永久丟失了。一個更為穩(wěn)妥的辦法是我們在遠程建立一個備份系統(tǒng)，所有在本地產(chǎn)生的日志同時也送往這個遠程系統(tǒng)，為了防止網(wǎng)絡發(fā)生故障，本地與遠程系統(tǒng)之間應該同時建立幾條相互獨立的網(wǎng)絡連接。這聽上去好象有點超前，可實際上許多關鍵應用早就用上了。
　　應該明白的是，恢復畢竟是一種非常耗時的工作，特別是進行后三種故障的恢復時，數(shù)據(jù)庫對用戶不可用。而這對象銀行這樣的部門來說，損失實在太大了。因此在很多情況下，我們只把恢復看作是最后的一道防線，我們希望最好永遠也別需要用到它。因此現(xiàn)在就出來了各種各樣的容錯設備，象RAID、雙機系統(tǒng)什么的，它們會把故障發(fā)生的概率降低到一個實際上可能永不發(fā)生的程度。

最新評論