oracle的SCN

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或其他的恢復語句