關於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內：
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
實例恢復的具體過程
當數據庫突然崩潰，而還沒有來得及將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進程還沒來得及回滾這些中間狀態的數據塊時，就有用戶進程發出讀取這些數據塊的請求。這時，服務器進程在將這些塊返回給用戶之前，由服務器進程負責進行回滾，回滾完畢後，將數據塊的內容返回給用戶。
為什麽數據庫的實例恢復是先前滾再回滾
回滾段實際上也是以回滾表空間的形式存在的，既然是表空間，那麽肯定就有對應的數據文件，同時在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來判斷需或者不需實例恢復。
本文出自 “Linux Oracle MariaDB” 博客，請務必保留此出處http://wangergui.blog.51cto.com/8504247/1932114
關於oracle實例恢復的前滾和回滾的理解