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