關于Oracle實例恢復的前滾和回滾的理解
關于oracle實例恢復的一些理解，一直都有誤區，今天通過查看相關資料和與同學探討，發覺了自己的錯誤，探討結果如下：
實例恢復：當數據庫非正常關閉的時候(斷電或者shu abort等等非一致性關閉)，當你從新啟動數據庫的時候，數據庫相關進程自動進行實例恢復，無須人工干預。
什么時候需要實例恢復
在shutdown normal or shutdown immediate下，也就是所謂的clean shutdown，checkpoint也會自動觸發，并且把SCN紀錄寫回。 當發生checkpoint時，會把SCN寫到四個地方：
三個地方于control file內：
- SYSTEM CHECKPOINT SCN
- Datafile checkpoint SCN
- Stop SCN：就是在實例一致性關閉的時候，更新
一個在datafile header內：
1.Start SCN
正常open的狀態下一致性的數據庫，SYSTEM CHECKPOINT SCN，Datafile checkpoint SCN和數據文件頭Start SCN的這三個SCN是一致，并且儲存在control file中的stop scn就會恢復為NULL值。
Clean shutdown 時
當clean shutdown 時，checkpoint會進行，并且此時datafile的stop scn和控制文件里的start scn會相同， 等到open數據庫時，Oracle檢查datafile header中的start scn和存于control file中的datafile的scn是否相同， 如果相同，接著檢查start scn和stop scn是否相同，如果仍然相同，數據庫就會正常開啟，否則就需要recovery。
等到數據庫開啟后，儲存在control file中的stop scn就會恢復為NULL值，此時表示datafile是open在正常模式下了。
非正常shutdown
如果不正常SHUTDOWN (shutdown abort)，則mount數據庫后，會發現stop scn并不是等于其它位置的scn， 而是等于NULL，這表示Oracle在shutdown時沒有進行checkpoint，下次開機必須進行crash recovery(實例恢復)。
注意一點：
- 啟動數據庫時，如果發現STOP SCN = NULL，表示需要進行crash recovery;
- 啟動數據庫時，如果發現有datafile header的START SCN 不等于儲存于CONTROLFILE的DATAFILE SCN，表示需要進行Media recovery
2.實例恢復的具體過程
當數據庫突然崩潰，而還沒有來得及將buffer cache里的臟數據塊刷新到數據文件里，同時在實例崩潰時正在運行著的事務被突然中斷，則事務為中間狀態，也就是既沒有提交也沒有回滾。這時數據文件里的內容不能體現實例崩潰時的狀態。這樣關閉的數據庫是不一致的。
下次啟動實例時，Oracle會由SMON進程自動進行實例恢復。實例啟動時，SMON進程會去檢查控制文件中所記錄的、每個在線的、可讀寫的數據文件的END SCN號。
數據庫正常運行過程中，該END SCN號始終為NULL，而當數據庫正常關閉時，會進行完全檢查點，并將檢查點SCN號更新該字段，所以可以通過END SCN號是否為null來判斷是不是需要實例恢復。
而崩潰時，Oracle還來不及更新該字段，則該字段仍然為NULL。當SMON進程發現該字段為空時，就知道實例在上次沒有正常關閉，于是由SMON進程就開始進行實例恢復了。
SMON進程進行實例恢復時，會從控制文件中獲得檢查點位置。于是，SMON進程到聯機日志文件中，找到該檢查點位置，然后從該檢查點位置開始往下，應用所有的重做條目，從而在buffer cache里又恢復了實例崩潰那個時間點的狀態。這個過程叫做前滾，前滾完畢以后，buffer cache里既有崩潰時已經提交還沒有寫入數據文件的臟數據塊，也還有事務被突然終止，而導致的既沒有提交又沒有回滾的事務所弄臟的數據塊。
前滾一旦完畢，SMON進程立即打開數據庫。但是，這時的數據庫中還含有那些中間狀態的、既沒有提交又沒有回滾的臟塊，這種臟塊是不能存在于數據庫中的，因為它們并沒有被提交，必須被回滾。打開數據庫以后，SMON進程會在后臺進行回滾。
有時，數據庫打開以后，SMON進程還沒來得及回滾這些中間狀態的數據塊時，就有用戶進程發出讀取這些數據塊的請求。這時，服務器進程在將這些塊返回給用戶之前，由服務器進程負責進行回滾，回滾完畢后，將數據塊的內容返回給用戶。
3.為什么數據庫的實例恢復是先前滾再回滾
回滾段實際上也是以回滾表空間的形式存在的，既然是表空間，那么肯定就有對應的數據文件，同時在buffer cache 中就會存在映像塊，這一點和其他表空間的數據文件相同。
當發生DML操作時，既要生成REDO(針對DML操作本身的REDO Entry)也要生成UNDO(用于回滾該DML操作，記錄在UNDO表空間中)，但是既然UNDO信息也是使用回滾表空間來存放的，那么該DML操作對應的UNDO信息(在BUFFER CACHE生成對應中的UNDO BLOCK)就會首先生成其對應的REDO信息(UNDO BLOCK's REDO Entry)并寫入Log Buffer中。
這樣做的原因是因為Buffer Cache中的有關UNDO表空間的塊也可能因為數據庫故障而丟失，為了保障在下一次啟動時能夠順利進行回滾，首先就必須使用REDO日志來恢復UNDO段(實際上是先回復Buffer Cache中的臟數據塊，然后由Checkpoint寫入UNDO段中)，在數據庫OPEN以后再使用UNDO信息來進行回滾，達到一致性的目的。
生成完UNDO BLOCK's REDO Entry后才輪到該DML語句對應的REDO Entry，最后再修改Buffer Cache中的Block，該Block同時變為臟數據塊。
實際上，簡單點說REDO的作用就是記錄所有的數據庫更改，包括UNDO表空間在內。
總 結
今天最重要的一點我知道了，所謂的前滾，是應用redo來恢復buffer cache的數據，將buffer cache恢復到crash之前狀態，所以此時buffer cache 中既有崩潰時已經提交還沒有寫入數據文件的臟數據塊，也還有事務被突然終止，而導致的既沒有提交又沒有回滾的事務所弄臟的數據塊(也就是沒有commit，但是dbwr已經將改變刷新到底層磁盤)，還有一點是控制文件中還有一個 end scn，用來記錄數據庫正常關閉的時候的數據庫文件頭的scn,并且可以通過這個scn是否為null來判斷需或者不需實例恢復。
