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 了
