Oracle恢複內部原理（執行個體恢複）

執行個體恢複用於恢複崩潰失敗或者並行伺服器環境中的執行個體失敗，所以執行個體恢複既可以指崩潰恢複也可以指並行伺服器環境中的執行個體恢複（只要有一個存活的執行個體就可以恢複其他一個或多個失敗的執行個體）。

執行個體恢複的目標就是還原失敗執行個體在資料緩衝區中的資料區塊並關閉還開著的線程。執行個體恢複只用聯機歸檔日誌和當前聯機資料檔案（不需要還原曆史備份）。執行個體恢複一次只能恢複一個線程，它從該線程最近的線程檢查點開始恢複直至線程的結束。

系列文章：Oracle恢複內部原理 http://www.bkjia.com/search.aspx?where=nkey&keyword=19824

5.1  檢測是否需要執行個體恢複

當Oracle核心發現一個執行個體死掉而對應線程在控制檔案中的線程開啟狀態位還是開的時候會自動進行執行個體恢複。執行個體恢複在下面兩種情形下自動進行：

1.      崩潰失敗後第一次開啟資料庫。

2.      並行伺服器個別執行個體（不是所有的）失敗了。

在並行伺服器環境中，存活的執行個體通過下列方法檢測到一個或多個執行個體失敗需要進行執行個體恢複：

1.      存活執行個體的一個前台進程在將資料檔案中的塊讀入資料緩衝區時檢測到“Invalid block lock” 。這個多發生在另一個執行個體已經將該塊讀入資料緩衝區並用鎖保護了該塊‘髒資料’，然後該執行個體失敗了。

2.      存活執行個體的前台進程通知它的SMON進程查看失敗的執行個體。

3.      存活執行個體可以申請死亡執行個體的線程開啟標誌鎖從而發現該執行個體已經死亡。

存活執行個體的SMON進程得到一個死亡執行個體的列表和錯誤的資料區塊列表。註：當執行個體恢複結束後，這些列表中的鎖都會被清掉。

5.2  Thread-at-a-Time Redo Application

執行個體恢複同一時間只能處理一個線程，因此同一時間也只能恢複一個執行個體。在處理下一個線程之前，執行個體恢複會將每個線程的所有重做日誌（從該線程的線程檢查點開始到線程結束）應用到資料檔案上。這個演算法的正確性取決於同一時刻只有一個執行個體能修改資料緩衝中的塊。在不同的執行個體修改同一塊之間，該塊會被寫回磁碟。因此，執行個體恢複時從磁碟中讀入資料緩衝中塊只需要某一個線程就夠了，那個線程包含了該塊最新的修改日誌。

執行個體恢複總是能夠只要該線程的聯機日誌就可以完成。崩潰恢複首先處理線程檢查點最低的那個線程，按照線程檢查點SCN遞增的順序進行恢複。保證了資料庫檢查點是由每個恢複過的線程推進的。

5.3  當前聯機資料檔案

檢查點計數器用於校正資料檔案是當前聯機資料檔案而不是曆史備份。如果資料檔案是從備份中還原出來的，則需要首先進行介質恢複。

當資料檔案是從備份中還原出來的時候，即使只要聯機重做日誌就可以恢複，介質恢複仍然不可避免。理由是崩潰恢複在處理每個線程的時候都是應用該線程檢查點以後的重做日誌。崩潰恢複能夠用這種重做演算法是因為每個塊只需要最多一個線程的重做日誌。

然而，如果在還原的備份上進行恢複時，無法斷定要哪些線程的重做日誌。因此一次一個線程的演算法在這種情況下不起作用。在備份上恢複需要將多個線程的重做合并。如把資料檔案檢查點後的所有重做日誌，按照SCN遞增的順序合并各個線程中的重做日誌。這種線程合并重做演算法只有介質恢複才會用（見第6節）。

崩潰恢複如果使用線程合并重做演算法恢複一個備份，即使資料檔案的檢查點跟資料庫檢查點一致，依然會失敗。原因是在所有的線程中，崩潰恢複會遺失資料庫檢查點和最高的檢查點之間的重做日誌。相比之下，介質恢複會從資料檔案檢查點開始應用重做程式。而且，即使崩潰恢複也從資料檔案檢查點開始應用重做程式，還是會失敗。因為它只會去找聯機重做日誌。而所有線程可能都已經將其重做日誌歸檔了並重用了聯機日誌。

如果使用了命令STARTUP RECOVER ，崩潰恢複會因為資料檔案需要介質恢複而失敗。此時在資料庫開啟之前會自動調用RECOVER DATABASE進行介質恢複。

5.4  檢查點

執行個體恢複不會嘗試應用資料檔案檢查點之前的重做日誌（資料檔案頭部的檢查點SCN不能決定是否需要執行個體恢複）。

執行個體恢複讀取從資料檔案檢查點之後到線程結束之際的重做日誌，找到該線程分配的最大的SCN。用於關閉線程和推進線程檢查點。執行個體恢複結束後也會推進資料檔案檢查點和檢查點計數器。

5.5  崩潰恢複完成

崩潰恢複完成時，所有資料檔案的聯機模糊位，熱備份模糊位，介質恢複模糊位都將被清除掉，然後在重做日誌中寫入一筆特殊的重做記錄，標記崩潰恢複的結束。這條記錄用於通知介質恢複在恢複時何時可以清除資料檔案的聯機模糊位和熱備份模糊位。