oracle checkpoint and the scn）

（轉自：http://space.itpub.net/12361284/viewspace-346）

年初的時候拜讀完了eygle寫的《深入潛出》這本書，感覺收穫很大。
正好可以總結一下SCN和checkpoint這兩個東東。

Checkpoint
很多人都把checkpoint的概念給複雜化了，其實checkpoint這個資料庫概念引入的真正意義就是用來減少在資料庫恢複過程中所花的時間(instance recovery),那麼checkpoint是又誰來做的呢？我們都知道資料庫中有個CKPT進程，這個是個可選進程，但是真正執行檢查點的任務並不是有ckpt來完成的，而是ckpt在更新控制檔案和資料檔案頭的有關資訊後，通知DBWn進程，產生一個檢查點，在產生檢查點的時候，DBWn進程會將buffer cache中的髒資料(當前online redo log對應的髒資料)，寫入我們的資料檔案當中。那麼這個時候如果資料庫此時崩潰（比如我們做個shutdown abort），那麼在進行執行個體恢複的時候就可以不需要當前online redo log的內容了，會很快就做完。因此ckpt進程只是個輔助進程，他的任務更多的是用來在系統做checkpoint的時候更新控制檔案和資料檔案頭中的資訊。其實在oracle 8i的時候呢，ckpt的任務一般都是由lgwr進程來完成，到了8i以後，隨著CKPT進程的引入，lgwr的工作負擔就減輕了很多(commit的速度加快了)
那麼如何來產生檢查點呢？
有三種方法，可以通過
1.alter system checkpoint
2.alter system switch logfile
3.DBWn進程寫出髒塊

SCN
在Oracle中理解為一個內部同步時鐘，是系統改變號的縮寫（system change number）,在Oracle資料庫中我們可以通過dbms_flashback包來查詢當前系統的改變號：select dbms_flashback.get_system_change_number from dual;一般來講SCN主要是用來標識資料庫所做的所有改變，這個SCN的改變是只能前進，不能回退，除非我們打算重建庫，資料庫中的SCN永遠不會歸0，一般來說SCN的前進觸發是由commit來進行的，除了這些據我觀察每隔3秒種系統也都會重新整理一次SCN.

需要注意的是：
1.CKPT一定是是在checkpoint發生的時候將資料庫當前的SCN更新入資料庫檔案頭和控制檔案當中，同時DBWn進程將buffer cache中的髒資料區塊（dirty block）寫到資料檔案當中(這個髒資料也一定是當前online redo log保護的那一部分)。

2.同時CKPT進程還會在控制檔案當中記錄(redo block address)RBA，這個地址用來標誌恢複的時候需要從日誌中的那個位置開始。

在Oracle資料庫中和checkpoint相關的SCN總共有4個
1.System checkpoint SCN  (存在於控制檔案)
在系統執行checkpoint後，Oracle會更新當前控制檔案中的System checkpoint SCN。
我們可以通過
select checkpoint_change# from v$database:
來查看

2.Datafile checkpoint SCN (存在於控制檔案)
由於控制檔案中記錄了Oracle中各個資料庫檔案的位置和資訊，其中當然也包括了Datafile checkpoint SCN，因此在執行checkpoint的時候，Oracle還會去更新控制檔案中所記錄的各個資料檔案的datafile checkpoint SCN.
我們可以通過
select checkpoint_change#  from v$datafile;
來查看

3.Start SCN (存在於各個資料檔案頭)
在執行checkpoint時，Oracle會更新存放在各個實際的資料檔案頭的Start SCN（注意絕對不會是控制檔案中），這個SCN存在的目的是用於檢查資料庫啟動過程中是否需要做media recovery(介質恢複)
我們可以通過
select checkpoint_change# from v$datafile_header;

4.End SCN(存在於控制檔案)
最後一類SCN,End SCN他也是記錄在控制檔案當中，每一個所記錄的資料檔案頭都有一個對應的End SCN,這個End SCN一定是存在於控制檔案當中。這個SCN存在的絕對意義主要是用來去驗證資料庫啟動過程中是否需要做instance recovery。我們可以通過
select name,last_change# from v$datafile
那麼其實在資料庫正常啟動並執行情況下，對於read/write的online 資料檔案這個SCN號為#FFFFFF(NULL).

下面來聊一聊SCN號於資料庫的啟動

1.在資料庫的啟動過程中，當System Checkpoint SCN=Datafile Checkpoint SCN=Start SCN的時候，Oracle資料庫是可以正常啟動的，而不需要做任何的media recovery。而如果三者當中有一個不同的話，則需要做media recovery

2.那什麼時候需要做instance recovery呢？其實在正常open資料庫的時候，oracle會將記錄在控制檔案中的每一個資料檔案頭的End SCN都設定為#FFFFFF(NULL)，那麼如果資料庫進行了正常關閉比如(shutdown or shutdown immediate)這個時候，系統會執行一個檢查點，這個檢查點會將控制檔案中記錄的各個資料檔案頭的End SCN更新為當前online資料檔案的各個資料檔案頭的Start SCN,也就是End SCN=Start SCN,如果再次啟動資料庫的時候發現二者相等，則直接開啟資料庫，並再次將End SCN設定為#FFFFFF(NULL),那麼如果資料庫是異常關閉，那麼checkpoint就不會執行，因此再次開啟資料庫的時候End SCN<>Start SCN這個時候就需要做執行個體恢複。

說了那麼多更新SCN操作什麼的，這個更新操作到底是由誰做的呢？其實剛才已經說過了，就是我們的CKPT進程，他不僅僅會更新SCN，而且還會通知DBWn做他的事情。

再說一下System Checkpoint SCN和Datafile Checkpoint SCN,這兩個SCN都是記錄在控制檔案當中的。但是這兩個SCN有什麼作用呢？
logzgh有段論述，我自己的想了一下，還是學習一下他的結論：

1.對唯讀資料表空間，其資料檔案的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。這三個SCN在資料表空間處於唯讀期間都將被凍結。

2.如果控制檔案不是當前的控制檔案(其實就是說，想比當前redo log的SCN來講，控制檔案已經過時了)，則System checkpoint SCN會小於Start SCN(Start SCN是來自實際的資料檔案頭，有比較依據)。記錄這些SCN號，可以區分控制檔案是否是當前的控制檔案。當有一個Start SCN(從當前各個線上資料檔案中獲得)號超過了System Checkpoit SCN號時，則說明控制檔案不是當前的控制檔案，因此在做recovery時需要採用using backup controlfile。這是為什麼需要記錄SystemCheckpoint SCN的原因之一。

當我們重建控制檔案的時候，重建方式分兩種（resetlogs 和 noresetlogs）

1.使用resetlogs選項時，System Checkpoint SCN為被歸為0，而其中記錄的各個資料檔案的Datafile Checkpoint SCN則來自於Start SCN（也就是說可能會從冷備份的資料檔案的資料檔案頭中擷取）。根據上述的描述，此時需要採用using backup controlfile做recovery. 因此情況是 System Checkpoint SCN=0 < Start SCN = Datafile Checkpoint SCN

2.使用noresetlogs選項時，有一個前提就是：一定要有online redo log的存在。否則就要使用resetlogs選項。這個時候控制檔案重建好時，其system checkpoint SCN=Datafile Checkpoint SCN=Lastest Checkpoint SCN in online redo log,我們可以看到Datafile Checkpoint SCN並沒有從Start SCN中讀取。而是讀取了最新的記錄檔中的SCN作為自己的資料。此時重建的控制檔案在恢複中的作用跟最新的控制檔案類似，System Checkpoint SCN(已經讀取最新的redo log的checkpoint SCN資訊)可能會>Start SCN （因為資料檔案可能會從冷備份中恢複），恢複時就不需要加using backup controlfile子句了

關於backup controlfile的補充：backup controlfile只有備份時刻的archive log資訊，並沒有DB crash時刻的archive log資訊，所以並不會自動應用online redo log,而是提示找不到序號為Lastest Archive log sequence + 1 的archive log,儘管你可以手動指定online redo log來實現完全恢複，但因為一旦使用了using backup controlfile子句，Oracle就視為不完全恢複，必須open resetlogs! 實際上，假如你有舊的控制檔案又不想resetlogs，那很簡單，使用舊的控制檔案mount然後 backup to trace ，然後手工建立控制檔案，使用 reuse database ... noresetlogs .這樣就可以 recover database 自動回復並open database 而不用 resetlogs 了