479
Oracle SCN簡述
什麼是SCN？
SCN即system change number，是一個用來維護數據改變版本的數字。其實可以等同於我們所認知的時間，但是若使用我們習慣的時間格式來做比較，數據庫的工作量會很大。基於這一點，Oracle將每個時間轉換成一個SCN號，使用SCN比較時間先後。SCN號可以和時間互相轉換。
SCN特征
1.SCN和時間相關聯，可互相轉換
2.SCN隻會增加，而不會減少。即使調整數據庫服務器的時間，SCN依舊增長
3.SCN號與時間的對應關係，同數據庫關聯。即不同的數據庫服務器，同樣的SCN號，對應的時間不一定相同
SCN號的作用是用來表示時間新舊。SCN號有個最大值，一個正常的數據庫預備的SCN號可以使用500年，然而有些事故的發生會觸發Oracle的某些bug，仍然可能導致SCN號勐增而到達上限，一旦出現這種事故，隻能重建數據庫。
SCN的類型
1.係統SCN號（檢查點SCN）
控製文件記錄係統SCN號，標識數據庫當前的係統時間
2.文件SCN號、起始SCN
每個數據文件頭部記錄著一個SCN，叫做起始SCN
控製文件記錄數據文件的結構，以及數據文件的文件SCN及終止SCN
正常運行期間，係統SCN=文件SCN=起始SCN
3.終止SCN號
數據庫正常關閉，係統SCN=文件SCN=起始SCN=終止SCN
數據庫正常打開，係統SCN、文件SCN、起始SCN相同，而終止SCN為NULL。終止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。
查看SCN
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#
接下來我們切換兩次日誌
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
現在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
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;
最後更新：2017-10-29 23:03:29