系統scn： ? ? ? ? ? ? ? ? select checkpoint_change# from v$database;
文件scn： ? ? ? ? ? ? ? ? select name,checkpoint_change# from v$datafile;
結束scn： ? ? ? ? ? ? ? ? select name,last_change# from v$datafile;
數據文件頭部scn： ? ? select name,checkpoint_change# from v$datafile_header;
系統scn、文件scn、結束scn，這三者是在控制文件中，數據文件頭部scn在數據文件上。
? ? ?數據庫正常運行，系統scn、文件scn、數據文件頭部scn（也稱為開始scn），這三者是相同的，而結束scn是空，即無窮大（因為正常運行，還未關閉啊），這是正常運行的情況，那么當正常關閉時，四者的scn號是相同的。假如發生非正常關閉，結束scn是空值，那么下次啟動數據庫，oracle發現結束scn是空值，就知道上次是非正常關閉，所以就要進行實例恢復了。實例恢復需要的是redo log，那么oracle是如何確定使用哪個redo log？以及確定之后又該從該redo log哪里進行恢復的呢？下面做個實驗。。。
? ? 當前數據庫的系統scn號：
這是redo log的一些信息：
? ? ? 我們主要關注第一次改變編號和狀態，我們可以看見，第3號日志組，序列號36的FIRST_CHANGE#和當前數據庫的系統scn號一致，為什么呢，FIRST_CHANGE#又是什么呢？從查詢結果我們可以看出，1號日志組是最舊的，2號次之，3號是最新的，這是從FIRST_CHANGE#可以看出來的，有FRIST就應該有NEXT啊，其實不難理解，下一個日志組的FIRST_CHANGE#其實就是這當前日志組的NEXT。所以例如1號日知組，FIRST_CHANGE#是1372964，NEXT是1395875。FIRST_CHANGE#的意義是該日志文件的第一條日志內容的scn號，NEXT就是該日志文件的最后一條內容的scn號了。那么如果此時數據庫崩潰，數據文件的scn號是1398359，而3號日志文件的FIRST_CHANGE#也是1398359，且當3號日志組的狀態是current，恢復就只要恢復3號日志組文件的內容就可以了，因為其他日志文件所記錄的內容已寫入到數據文件中。
? ? ? 還有一種情況，如果三個日志組的狀態是active、active、current，那么數據文件的scn號就會和比較舊的active的日志組的FIRST_CHANGE#一致，這時如果崩潰后恢復，那么三個日志組都會用到。
? ? ? 結論：現在可以理解了，scn號的目的是為了保證數據庫狀態的一致性，而scn和redo log的FIRST_CHANGE#作用是，當實例恢復的時候，確定了該跑哪個日志組，才能將臟塊重現在buffer cache中。而確定日志組后，又該從該日志組的哪條日志開始，就要從控制文件的LRBA中獲取了（在我的上一個隨筆檢查點隊列中有描述）。
