1． 系統SCN號
查詢系統SCN號的方法：
select dbms_flashback.get_system_change_number from dual
commit后系統SCN號會增長，但是即使沒有commit操作，因為有許多后臺進程在運行，所以系統SCN號也會增長。
2． 檢查點SCN
有4種檢查點SCN，其中除了文件頭中的啟動SCN外，其他三種保存在控制文件中。可以通過：alter system set events ‘immediate trace name controlf level 10’導出控制文件到udump目錄的跟蹤文件，來查看控制文件的內容。
1) 系統檢查點SCN(區別于上面的系統SCN，chekpoint發出后這些SCN號才受影響，如發出：alter system checkpoint),當一個檢查點動作完成后，Oracle就把系統檢查點的SCN存儲到控制文件中，查詢方法：
Select checkpoint_change# from v$database
2) 數據文件檢查點SCN
當一個檢查點動作完成后，Oracle就把每個數據文件的SCN號單獨存放在控制文件中，查詢方法：
Select checkpoint_change# from v$datafile
3) 文件頭中的啟動SCN
Oracle把這個檢查點的SCN號存儲在每一個數據文件的文件頭中。主要用于數據庫實例啟動時，檢查是否需要執行數據庫恢復。查詢方法：
Select name,chekpoint_change# from v$datafile_header
4) 終止SCN
每個數據文件的SCN號都存儲在控制文件中，查詢方法：
Select name,last_change# from v$datafile
在正常的數據庫操作過程中，所有處于聯機讀寫模式下的數據文件的終止SCN都為NULL。
3． 幾個檢查點SCN號的關系
1) 幾個檢查點SCN都相同：在數據庫打開并運行之后，控制文件中的系統檢查點SCN、控制文件中的數據文件檢查點SCN及每個數據文件頭中的啟動SCN都是相同的，控制文件中的每個數據文件的終止SCN都是NULL。
2) 數據庫正常關閉時，系統會執行一個檢查點動作，這時所有數據文件的 終止SCN號會設置為數據文件頭的那個啟動SCN。數據庫重新啟動時，Oracle將數據文件頭中的啟動SCN與數據文件檢查點SCN比較，如果這兩個值匹配，Oracle接下來再比較數據文件頭中的SCN和控制文件中數據文件的終止SCN，如果這個值也匹配，就意味著所有數據塊已經提交，因此數據庫不需要進行恢復，此時數據庫直接打開。當所有的數據文件都打開之后，終止SCN再次被設置為NULL，表示數據文件已經打開并能夠正常使用了。
3) 數據庫非正常關閉(或稱為實例崩潰)時，終止SCN不會被設置，依然為NULL，這可以通過把數據庫啟動至mount狀態查詢出來。這樣Oracle通過這個信息就可以知道實例上次運行時崩潰了，檢查點沒有執行。這樣重新啟動時，Oracle會執行實例恢復工作，即先執行前滾、回滾操作，再把數據庫打開。
4) 數據文件檢查點SCN及系統檢查點SCN比文件頭啟動SCN大：這時的情況是：系統發生介質故障，數據文件被以前的備份代替，控制文件中的數據文件檢查點SCN肯定比文件頭中的啟動SCN要大，這樣Oracle就知道要對這個文件進行介質恢復。這時要通過下面語句恢復數據庫：
recover database ……
5) 系統檢查點SCN比數據文件SCN及文件頭啟動SCN大：
有些表空間是只讀的，這時控制文件中的系統檢查點SCN號會不斷增長，而數據文件SCN號和文件頭中的啟動SCN號會停止更新(直到表空間又設置為可讀寫)，顯然這時系統檢查點SCN號會大于數據文件SCN和文件頭啟動SCN。
6) 系統檢查點SCN及數據文件SCN比文件頭啟動SCN小：
在數據庫恢復時，控制文件可能不是最新的，即把一個較早的控制文件還原為當前的控制文件，然后再執行恢復操作，這時控制文件中的系統檢查點SCN和數據文件SCN可能比文件頭的啟動SCN小。這時恢復數據庫要用下面命令：
recover database using Backup Controlfile或其他的恢復語句