SCN即system change number，是一個用來維護資料改變版本的數字。其實可以等同于我們所認知的時間，但是若使用我們習慣的時間格式來做比較，資料庫的工作量會很大。基于這一點，Oracle将每個時間轉換成一個SCN号，使用SCN比較時間先後。SCN号可以和時間互相轉換。
1.SCN和時間相關聯，可互相轉換
2.SCN隻會增加，而不會減少。即使調整資料庫伺服器的時間，SCN依舊增長
3.SCN号與時間的對應關系，同資料庫關聯。即不同的資料庫伺服器，同樣的SCN号，對應的時間不一定相同
SCN号的作用是用來表示時間新舊。SCN号有個最大值，一個正常的資料庫預備的SCN号可以使用500年，然而有些事故的發生會觸發Oracle的某些bug，仍然可能導緻SCN号猛增而到達上限，一旦出現這種事故，隻能重建資料庫。
1.系統SCN号（檢查點SCN）
2.檔案SCN号、起始SCN
3.終止SCN号
當資料庫非正常關閉時，很多資料不能及時寫入磁盤，包括應寫入控制檔案的資訊，終止SCN為NULL，資料庫再次啟動時，SMON程序檢查控制檔案記錄的SCN号，發現終止SCN為NULL後，知道資料庫上次未進行正常關閉，SMON馬上對資料庫進行崩潰恢複；對于檔案SCN，若資料庫關閉期間進行了一個資料檔案的restore，那麼控制檔案記錄的資料檔案的檔案SCN肯定要新于restore的資料檔案中的起始SCN，在資料庫打開的時候，Oracle檢測到資料檔案是舊的，那麼我們需要對資料檔案進行recover，恢複到控制檔案中與其它資料檔案相同的狀态；系統SCN号代表資料庫的最新狀态，用來判斷檔案是否是最新的。
4.日志條目SCN
資料庫server process對表的buffe進行DML操作時會産生日志，對每一行資料進行的每一次修改都會産生一條redo log，每條redo log記錄着産生日志的時間，即操作發生的時間。資料庫進行恢複的時候，根據redo log的SCN按操作發生的先後順序進行恢複，即先将日志條目按SCN排好序，再進行恢複
5.first SCN、next SCN
對于current redo日志檔案，first SCN記錄着該檔案中最早的日志的SCN，而next SCN為NULL，當日志寫滿該檔案後，切換到下一組，這時，下一組檔案成為current，之前的current成為active，寫入新的current檔案的最早的日志的SCN記入current檔案的first SCN，同時記入上一組日志的next SCN。通過first SCN和next SCN可以将日志串聯起來，同時記錄着一組日志檔案中日志産生的SCN的範圍
6.送出SCN
每個事物送出時，log buffer寫入事務送出時的系統SCN
檢查更新資料庫中的SCN由檢查點程序CKPT完成，一般來講，redolog中的SCN要大于資料庫中的SCN，雖然redolog記錄的SCN新于資料庫，但是對于一個正常運作的資料庫，系統SCN，檔案SCN以及資料檔案中的起始SCN仍然一緻，SCN号存在的意義就是為了保證資料庫的一緻性，是以沒必要實時更新，并且實時更新對CKPT會産生相當大的工作負載。正常運作期間，系統SCN與控制檔案及資料檔案中記錄的SCN均為redolog file中最早的組（ACTIVE）的first SCN，當redolog file全部用完，需要覆寫使用時，CKPT會将資料庫中一切的SCN号更新為覆寫之後的檔案的first SCN，将資料庫全部重新整理，而資料庫下次重新整理則是在這個檔案再次被覆寫的時候。另外，redolog file被歸檔也會觸發CKPT。
1.檢視系統SCN号
select a.CHECKPOINT_CHANGE# from v$database a;
2.檢視控制檔案記錄的資料檔案的檔案SCN和終止SCN
select CHECKPOINT_CHANGE#,LAST_CHANGE# from v$datafile ;
3.檢視資料檔案頭部記錄的起始SCN
select CHECKPOINT_CHANGE# from v$datafile_header;
我們可以看出，資料庫中的SCN号一緻，由于資料庫處于運作期間，故控制檔案中的last_change#并未記錄資訊，為NULL
4.檢視redolog file的SCN
select group#,status,first_change#,next_change# from v$log;
第二組檔案為current，故next_change#辨別為無窮大
由于資料庫自開啟自現在，一直在使用2号redolog file，故系統SCN及資料庫SCN保持着current redo的first_change#
接下來我們切換兩次日志
現在2号檔案狀态為ACTIVE，而CURRENT 檔案變成了1号，資料庫SCN此時并未改變。一段時間後，ACTIVE被歸檔，如下圖，
此時，再檢視資料庫的SCN，統一更新為6940929
5.檢視歸檔日志的SCN
select a.SEQUENCE#,a.FIRST_CHANGE#,a.NEXT_CHANGE# from v$archived_log a;
使用LogMiner挖掘日志中的SCN
1.查詢目前系統的SCN，即使用timestamp_to_scn将system轉換成SCN
select dbms_flashback.get_system_change_number SCN1,timestamp_to_scn(sysdate) SCN2 from dual;
2.使用scn_to_timestamp将SCN轉換成時間
select to_char(scn_to_timestamp(6940259),'YYYY-MM-DD HH24:MI:SS') from dual;