關於SCN的理解
系統檢查點scn(v$database(checkpoint_change#))
數據文件檢查點（v$datafile(checkpoint_change#)）
數據文件終止scn(v$datafile(last_change#))
數據文件中存放的檢查點
啓動scn (v$datafile_header(checkpoint_change#)
1、系統檢查點scn
當一個檢查點動作完成之後，Oracle就把系統檢查點的SCN存儲到控制文件中。
select checkpoint_change# from v$database
2、數據文件檢查點scn
當一個檢查點動作完成後，Oracle就把每個數據文件的scn單獨存放在控制文件中。
select name,checkpoint_change# from v$datafile
3、啓動scn
Oracle把這個檢查點的scn存儲在每個數據文件的文件頭中，這個值稱爲啓動scn，
因爲它用於在數據庫實例啓動時，檢查是否需要執行數據庫恢復。
select name,checkpoint_change# from v$datafile_header
4、終止scn
每個數據文件的終止scn都存儲在控制文件中。
select name,last_change# from v$datafile
在正常的數據庫操作過程中，所有正處於聯機讀寫模式下的數據文件的終止scn都爲null.
5、在數據庫運行期間的scn值
在數據庫打開並運行之後，控制文件中的系統檢查點、控制文件中的數據文件檢查點scn和每個數據文件頭中的啓動scn都是相同的。控制文件中的每個數據文件的終止scn都爲null.
在安全關閉數據庫的過程中，系統會執行一個檢查點動作，這時所有數據文件的終止scn
都會設置成數據文件頭中的那個啓動scn的值。在數據庫重新啓動的時候，
Oracle將文件頭中的那個啓動scn與數據庫文件檢查點scn進行比較，
如果這兩個值相互匹配，oracle接下來還要比較數據文件頭中的啓動scn和控制文件中數據文件的終止scn。如果這兩個值也一致，就意味着所有數據塊多已經提交，所有數據庫的修改都沒有在關閉數據庫的過程中丟失，因此這次啓動數據庫的過程也不需要任何恢復操作，此時數據庫就可以打開了。當所有的數據庫都打開之後，存儲在控制文件中的數據文件終止scn的值再次被更改爲null，這表示數據文件已經打開並能夠正常使用了。
------------------------------------------
澄清幾個概念
1)系統當前SCN並不是在任何的數據庫操作發生時都會改變,SCN是在事務提交或回滾時改變,
2)在控制文件,數據文件頭,數據塊,日誌文件頭,日誌文件change vector中都有SCN,但其作用各不相同
數據文件頭中包含了該數據文件的checkpoint SCN,表示給數據文件最近一次執行檢查點操作時的SCN.日誌文件頭中包含了low scn,next scn,表示給日誌文件包含有從low scn到next scn的redo record.控制文件中包含了每個數據文件的checkpoint SCN,stop SCN,每個日誌文件的low scn,next scn.控制文件中checkpoint scn同數據文件頭中checkpoint scn相同,除非數據文件被手工替換掉.
控制文件中的low scn,next scn同日志文件中low scn和next scn相同。在數據庫正常運行時,控制文件中對應數據文件的stop SCN都是最大值.在正常關閉數據庫的情況下,在關閉前會執行一次檢查點工作當oracle會將數據緩衝區上的內容全部寫回到磁盤中,然後更新控制文件中對應數據文件的stop SCN,使其等於checkpoint SCN
但在異常當機的情況下,由於最後一次檢查點未進行或進行中間被中止,因而在控制文件,就存在部分的數據文件stop SCN爲最大值,在數據庫重新啓動後,會檢查控制文件中對應每個數據文件的stop SCN,如果stop SCN不等於控制文件中對應每個數據文件的checkpoint SCN,就會使用日誌文件redo從checkpoint SCN開頭到stop SCN爲止的全部數據庫操作.在定位到底是使用哪一個redo log文件時,就用到了日誌文件頭中的low scn,next scn,也就是說要使用的redo log的low scn ,next scn必須包含數據文件重做所須的change vector.
在確定了哪個數據文件須redo後,oracle會比較change vector中的SCN和數據文件數據塊中的SCN,如果change vector的SCN小於數據塊的scn,則跳過此change vector,否則redo。
數據塊中ITL中還有SCN,但它的作用是用於產生一致性讀快照
-----------------------------
1: SCN 並不僅僅在 提交或者回滾的時候才改變，DML 發生的時候會改變，提交的時候也會變，還有很多的變化都會改變， 有興趣請去www.ixora.com.au 看看 。證明方法也很容易。
2: 在定位到底使用哪個日誌文件的時候，並不是用 數據文件中的 low scn 去框，在日誌文件的low scn and next scn 之間就利用該日誌文件。而是在數據文件頭中有 RBA 的記錄，RBA 包含了日誌序號、block number 、slot number 。 這樣可以直接定位到日誌文件（歸檔日誌文件）和具體的位置
如果你有興趣，大可去實驗，dump出來看看。
-------------------------------
1、SCN存在redo log文件，control文件、數據文件;
2、oracle正常運行時，control文件的SCN是個很大的數，與redo log文件、數據文件的SCN不同，正常關閉時，做完checkpoint後，三者的SCN值相同;
3、當一個事務commit成功時，redo log文件中的SCN+1,當該事務所做的修改寫入數據文件後，數據文件的SCN+1；
4、所以，當數據庫發現SCN不一致，應該是
redo log文件中的SCN>=數據文件中的SCN
5、疑問：
是不是如果一個事務比較大，在事務提交前就發生redo log entries、data buffer的寫入，此時斷電，則數據文件、redo log文件的SCN沒有+1，且相同，但控制文件SCN不同，數據庫startup時發生回滾。
數據文件是由ckpt進程更新文件頭的，scn不是加1，而是更新爲檢查點發生那時的scn，回滾是根據回滾段頭的事務表狀態來進行的
-----------------------------------------------
數據寫入數據文件scn不是加1而是ckpt 更新，檢查點發生的時候才修改數據文件頭的 檢查點計數和更新scn 是不是應該這麼說?:
當ckpt 更新時發生數據寫入，同時修改數據文件頭的 檢查點計數和更新scn 。當出現其他情況下的數據寫入時（如無空閒緩衝等），不發生ckpt ，但SCN會增加。
commit的時候加一，其他很多時候也會加1，只要數據庫發生了變化都會增加。
很多時候，能否舉一些例子
另，我相信很多人對SCN、CHECKPOINT不太清楚，能否給我們講講，就像回滾段一樣。呵呵，不好意思了。
數據寫入數據文件scn不是加1而是ckpt 更新，檢查點發生的時候才修改數據文件頭的 檢查點計數和更新scn
是不是應該這麼說?:
當ckpt 更新時發生數據寫入，同時修改數據文件頭的 檢查點計數和更新scn 。當出現其他情況下的數據寫入時（如無空閒緩衝等），不發生ckpt ，但SCN會增加。
這個時候修改的是數據塊但不是數據文件頭，只有檢查點發生的時候才更新數據文件頭，也就是說只有 ckpt 進程更新數據文件頭（oracle8以前如果沒有ckpt進程就是lgwr更新），dbwr只寫數據塊
commit的時候加一，其他很多時候也會加1，只要數據庫發生了變化都會增加。
很多時候，能否舉一些例子
dml一發生即使沒有提交也會增加scn, job進程一樣產生scn,只要對數據庫中文件發生任何的改變都有可能產生scn,SCN: system change number, not system commit
數據庫正常關閉啓動
數據庫正常關閉時，系統會執行一個完全檢查點動作，並用該檢查點時的SCN號更新上述4個SCN號，這時所有數據文件的終止SCN號會設置爲數據文件頭的那個啓動SCN（除了離線和只讀的數據文件）
數據庫重新啓動時，Oracle將數據文件頭中的啓動SCN與數據文件檢查點SCN比較，如果這兩個值匹配，Oracle接下來再比較數據文件頭中的SCN和控制文件中數據文件的終止SCN，如果這個值也匹配，就意味着所有數據塊已經提交，因此數據庫不需要進行恢復，此時數據庫直接打開。當所有的數據文件都打開之後，在線且可讀寫的數據文件終止SCN再次被設置爲NULL，表示數據文件已經打開並能夠正常使用了。有些表空間是隻讀的，這時控制文件中的系統檢查點SCN號會不斷增長，而數據文件SCN號和文件頭中的啓動SCN(會停止更新直到表空間又設置爲可讀寫)，顯然這時系統檢查點SCN號會大於數據文件SCN和文件頭啓動SCN。
數據庫非正常關閉
數據庫非正常關閉 ( 或稱爲實例崩潰
) 時，終止 SCN 不會被設置，依然爲 NULL
，這可以通過把數據庫啓動至 mount 狀態查詢出來。 這樣重新啓動時，SMON進程
會執行實例恢復工作，即先執行前滾、回滾操作，再把數據庫打開。
數據文件介質故障
出現介質故障時，數據文件檢查點SCN及系統檢查點SCN比文件頭啓動SCN大。系統發生介質故障時，數據文件被以前的備份代替，控制文件中的數據文件檢查點SCN肯定比文件頭中的啓動SCN要大，這樣Oracle就知道要對這個文件進行介質 恢復
控制文件介質故障
系統檢查點SCN及數據文件SCN比數據文件頭啓動SCN小：
在數據庫恢復時，控制文件可能不是最新的，即把一個較早的控制文件還原爲當前的控制文件，然後再執行恢復操作，這時控制文件中的系統檢查點SCN和數據文件SCN可能比文件頭的啓動SCN小。這時恢復數據庫要用下面命令：recover database using Backup Controlfile或其他的恢復語句。
備份時的實例崩潰
當執行begin backup時實例崩潰：控制文件中的數據文件檢查點SCN號和數據文件頭部檢查點SCN號相同，但是每個可讀寫的在線數據文件之間檢查點SCN號不同，那麼要求介質恢復，例如發出begin backup命令後就會出現這種情況，需要通過end backup命令好纔可以打開數據庫。
