關於INSTANCE RECOVERY過程的理解

關於INSTANCE RECOVERY你要是想說的簡單可以把它描述的十分簡單 就是REDO+UNDO

可是具體ORACLE是如何實現的就不清楚了 下面是幾個人對於這個過程的描述

wanghai－－－

1. 增量檢查點
在checkpoint queue的基礎上實現了增量檢查點，每3秒發生一次checkpoint heartbeat，記錄dbwr上次寫成功的最大RBA(redo block address)。這樣的話做instance recovery的時候就從這個rba開始，而不是從上次checkpoint scn開始，大大節省了恢復時間。
 
2. twice scan of redo log
在應用redo之前，redo將會被操作兩次，第一次去掃描哪些redo record需要被應用，因為9i在redo裡新增了dbwr寫資料塊的資訊，所以dbwr發生前的日誌將不會被應用。第二步就是選出需要被應用的日誌然後開始rollforward。
 
3. rollforward
在做instance recovery時必須先定位到redo log 然後應用所有日誌到datafile，這時候包括了committed和uncommitted的資料。當做完rollward，資料庫就可以open了。
 
4. rollback
因為rollforward產生了uncommitted資料，所以必須回滾這些資料。這將由smon和on-demand rollback來實現。smon將會掃描undo segment header去標誌所有活動事務為dead，然後會逐漸去回滾這些事務。另外on-demand rollback提供了前臺程式進行rollback，當前臺程式企圖獲得被dead事務佔用row lock，這時候前臺程式將會去undo segment取得before image去回滾這個塊，至於其他被這個dead事務lock的塊就等待smon去回滾。

kamus－－－

1. 一個資料塊發生更新，必然寫回滾
2. 回滾段的block變化也記錄在redo中

一份未提交的資料必定在回滾中有相應的前映象，任何正常的恢復都一定會把這些變化重新構建出來。

想像一下

1. update事務1更新了block 1
2. 回滾段1記錄了block1的前映象
3. checkpoint
4. update事務2更新了block2
5. 回滾段2記錄了block2的前映象
6. instance crash

現在重啟資料庫

1. 根據redo重新構建block2
2. 根據redo重新構建回滾段2
3. database open
4. SMON用回滾段2的資料回滾block2，SMON用回滾段1的資料回滾block1

最後一步也可能是
在另外一個select檢索到block1或者block2的時候，發現這兩個block的資料都是未提交的，此時再回滾block1和block2。

所以，只要有相應的回滾資料存在，無論什麼時候oracle都可以找到一致的資料，oracle只需要知道這個事務是提交了的還是沒提交了的，而這點在block header ITL中有記錄。