oracle介質恢複和執行個體恢複的概念

1、概念

REDO LOG是Oracle為確保已經提交的事務不會丟失而建立的一個機制。實際上REDO LOG的存在是為兩種情境準備的，一種我們稱之為執行個體恢複（INSTANCE RECOVERY），一種我們稱之為介質恢複（MEDIA RECOVERY）。

執行個體恢複的目的是在資料庫發生故障時，確保BUFFER CACHE中的資料不會丟失，不會造成資料庫的不一致。

介質恢複的目的是當資料檔案發生故障時，能夠恢複資料。

雖然這兩種恢複使用的機制類似的，但是這兩種恢複也有著十分本質的不同，這一點也是很多DBA經常會混淆的。

REDO LOG的資料是按照THREAD來組織的，對於單一實例系統來說，只有一個THREAD，對於RAC系統來說，可能存在多個THREAD，每個資料庫執行個體擁有一組獨立的REDO LOG檔案，擁有獨立的LOG BUFFER，某個執行個體的變化會被獨立的記錄到一個THREAD的REDO LOG檔案中。

2、恢複步驟及區別

對於介質恢複和執行個體恢複來說，第一個步驟都是通過REDO LOG的資訊進行前滾，在做前滾的時候，通過REDO LOG檔案裡記錄的資料庫變化向量（稍後我們會詳細的介紹資料庫變化向量CV），根據SCN的比對，提交到相關的資料檔案上，從而使資料檔案的狀態向前滾動。大家要注意的是，UNDO資料表空間的變化也被記錄到REDO LOG裡了，因此UNDO資料表空間相關的資料檔案也會被前滾。當前滾到最後一個可用的REDO LOG或者歸檔日誌的時候，所有的資料庫恢複層面的工作就全部完成了。這個時候，資料庫包含了所有的被記錄的變化，這些變化中有些是已經提交，有些是尚未提交的。在最新狀態的UNDO資料表空間中，我們也可以看到一些尚未提交的事務。

因此資料庫下一步需要做的事情是事務層面的處理，復原那些尚未提交的事務，以確保資料庫的一致性。

本文URL地址：http://www.bianceng.cn/database/Oracle/201410/45404.htm

對於單一實例的系統，執行個體恢複一般是在資料庫執行個體異常故障後資料庫重啟時進行，當資料庫執行了SHUTDOWN ABORT或者由於作業系統、主機等原因宕機重啟後，在ALTER DATABASE OPEN的時候，就會自動做執行個體恢複。而在RAC環境中，如果某個執行個體宕了，或者的執行個體將會接管，替宕掉的執行個體做執行個體恢複。除非是所有的執行個體都宕了，這樣的話，第一個執行ALTER DATABASE OPEN的執行個體將會做執行個體恢複。這也是REDO LOG是執行個體私人的組件，但是REDO LOG檔案必須存放在共用儲存上的原因。

Oracle資料庫的CACHE機制是以效能為導向的，CACHE機制應該最大限度的提高資料庫的效能，因此CACHE被寫入資料檔案總是儘可能的延遲。這種機制大大提高了資料庫的效能，但是當執行個體出現故障時，可能出現一些問題。

首先是在執行個體故障時，可能某些事物對資料檔案的修改並沒有完全寫入磁碟，可能磁碟檔案中丟失了某些已經提交事務對資料檔案的修改資訊。其次是可能某些還沒有提交的事務對資料檔案的修改已經被寫入磁碟檔案了。也有可能某個原子變更的部分資料已經被寫入檔案，而部分資料還沒有被寫入磁碟檔案。執行個體恢複就是要通過ONLINE REDO LOG檔案中記錄的資訊，自動的完成上述資料的修複工作。這個過程是完全自動的，不需要人工幹預。

在這個機制裡，有兩個問題需要解決，第一個是如何確保已經提交的事務不會丟失，第二個是如何在資料庫效能和執行個體恢複所需要的時間上做出平衡，既確保資料庫效能不會下降，又保證執行個體恢複的快速。

解決第一個問題比較簡單，Oracle有一個機制，叫做Log-Force-at-Commit，就是說，在事務提交的時候，和這個事務相關的REDO LOG資料，包括COMMIT記錄，都必須從LOG BUFFER中寫入REDO LOG檔案，此時事務提交成功的訊號才能發送給使用者進程。通過這個機制，可以確保哪怕這個已經提交的事務中的部分BUFFER CACHE還沒有被寫入資料檔案，就發生了執行個體故障，在做執行個體恢複的時候，也可以通過REDO LOG的資訊，將不一致的資料前滾。

解決第二個問題，oracle是通過checkpoint機制來實現的。Oracle資料庫中，對BUFFER CAHCE的修改操作是前台進程完成的，但是前台進程只負責將資料區塊從資料檔案中讀到BUFFER CACHE中，不負責BUFFER CACHE寫入資料檔案。BUFFER CACHE寫入資料檔案的操作是由後台進程DBWR來完成的。DBWR可以根據系統的負載情況以及資料區塊是否被其他進程使用來將一部分資料區塊回寫到資料檔案中。這種機制下，某個資料區塊被寫迴文件的時間可能具有一定的隨機性的，有些先修改的資料區塊可能比較晚才被寫入資料檔案。而CHECKPOINT機制就是對這個機制的一個有效補充，CHECKPOINT發生的時候，CKPT進程會要求DBWR進程將某個SCN以前的所有被修改的塊都被寫回資料檔案。這樣一旦這次CHECKPOINT完成後，這個SCN前的所有資料變更都已經存檔，如果之後發生了執行個體故障，那麼做執行個體恢複的時候，只需要衝這次CHECKPOINT已經完成後的變化量開始就行了，CHECKPOINT之前的變化就不需要再去考慮了。

到目前為止，我們瞭解了執行個體恢複機制的一些基本的原理，我們也可以大體上理解REDO LOG的工作機制了。不過我想我們還需要再更加深入一些。瞭解一些更為深入的內幕。實際上通過上面老白的介紹，大家也許已經覺得對執行個體恢複瞭解的很透徹了，而實際上，有很多問題我們還沒有解決。有些愛動腦筋的讀者可能要問了，有沒有可能資料檔案中的變化已經寫盤，但是REDO LOG資訊還在LOG BUFFER中，沒有寫入REDO LOG呢，這種情況如何恢複呢？

這裡我們又要引入一個名詞：Write-Ahead-Log，就是日誌寫入優先。日誌寫入優先包含兩方面的演算法，第一個方面是，當某個BUFFER CACHE的修改的變化向量還沒有寫入REDO LOG檔案之前，這個修改後的BUFFER CACHE的資料不允許被寫入資料檔案，這樣就確保了再資料檔案中不可能包含未在REDO LOG檔案中記錄的變化；第二個方面是，當對某個資料的UNDO資訊的變化向量沒有被寫入REDO LOG之前，這個BUFFER CACHE的修改不能被寫入資料檔案。

介質恢複和執行個體恢複的機制是類似的，所不同的是，介質恢複是當儲存的資料檔案出現故障的時候進行的，介質恢複無法自動進行，必須手工執行recover Database或者recover datafile命令來實施。一般來說，介質恢複是從一個恢複的資料檔案為起點進行恢複，因此在做介質恢複的時候，需要使用歸檔日誌。

作者：51cto部落格 Oracle小混子