Oracle SCN（System Chang Number）是Oracle 中的一個十分重要機制，在相關的數據恢復、Data Guard、與Streams復制、還有RAC節點間的相關同步等各個不同功能中起著十分重要作用。
理解SCN的運作機制，可以幫助你更加深入地了解上述功能。
在理解Oracle SCN之前，我們先看下Oracle 事務中的數據變化是如何寫入數據文件的：
1、 事務開始；
2、 在buffer cache中找到需要的數據塊，如果沒有找到，則從數據文件中載入buffer cache中；
3、 事務修改buffer cache的數據塊，該數據被標識為“髒數據”，並被寫入log buffer中；
4、 事務提交，LGWR進程將log buffer中的“髒數據”寫入redo log file中；
5、 當發生checkpoint，CKPT進程更新所有數據文件的文件頭中的信息，DBWn進程則負責將Buffer Cache中的髒數據寫入到數據文件中。
經過上述5個步驟，事務中的數據變化最終被寫入到數據文件中。但是，一旦在上述中間環節時，數據庫意外宕機了，在重新啟動時如何知道哪些數據已經寫入數據文件、哪些沒有寫呢（同樣，在DG、streams中也存在類似疑問：redo log中哪些是上一次同步已經復制過的數據、哪些沒有）？SCN機制就能比較完善的解決上述問題。
SCN是一個數字，確切的說是一個只會增加、不會減少的數字。正是它這種只會增加的特性確保了Oracle 知道哪些應該被恢復、哪些應該被復制。
總共有4中SCN：系統檢查點（System Checkpoint）SCN、數據文件檢查點（Datafile Checkpoint）SCN、結束SCN（Stop SCN）、開始SCN（Start SCN）。其中其面3中SCN存在於控制文件中，最後一種則存在於數據文件的文件頭中。
在控制文件中，System Checkpoint SCN是針對整個數據庫全局的，因而只存在一個，而Datafile Checkpoint SCN和Stop SCN是針對每個數據文件的，因而一個數據文件就對應在控制文件中存在一份Datafile Checkpoint SCN和Stop SCN。在數據庫正常運行期間，Stop SCN(通過視圖v$datafile的字段last_change#可以查詢)是一個無窮大的數字或者說是NULL。
在一個事務提交後（上述第四個步驟），會在redo log中存在一條redo記錄，同時，系統為其提供一個最新的Oracle SCN（通過函數dbms_Flashback.get_system_change_number可以知道當前的最新SCN），記錄在該條記錄中。
如果該條記錄是在redo log被清空（日志滿做切換時或發生checkpoint時，所有變化日志已經被寫入數據文件中），則其SCN被記錄為redo log的low SCN。以後在日志再次被清空前寫入的redo記錄中SCN則成為Next SCN。
當日志切換或發生checkpoint（上述第五個步驟）時，從Low SCN到Next SCN之間的所有redo記錄的數據就被DBWn進程寫入數據文件中，而CKPT進程則將所有數據文件（無論redo log中的數據是否影響到該數據文件）的文件頭上記錄的Start SCN(通過視圖v$datafile_header的字段checkpoint_change#可以查詢)更新為Next SCN。
同時將控制文件中的System Checkpoint SCN（通過視圖v$database的字段checkpoint_change#可以查詢）、每個數據文件對應的Datafile Checkpoint（通過視圖v$datafile的字段checkpoint_change#可以查詢）也更新為Next SCN。但是，如果該數據文件所在的表空間被設置為read-only時，數據文件的Start SCN和控制文件中Datafile Checkpoint SCN都不會被更新。
那系統是如何產生一個最新的SCN的？實際上，這個數字是由當時的timestamp轉換過來的。每當需要產生一個最新的Oracle SCN到redo記錄時，系統獲取當時的timestamp，將其轉換為數字作為SCN。我們可以通過函數SCN_TO_TIMESTAMP（10g以後）將其轉換回timestamp：
- SQL> select dbms_Flashback.get_system_change_number,
SCN_TO_TIMESTAMP(dbms_Flashback.get_system_change_number) from dual;- GET_SYSTEM_CHANGE_NUMBER SCN_TO_TIMESTAMP(DBMS_FlashBACK.GET_SYSTEM_CHANGE_NUMBER)
- 2877076756 17-AUG-07 02.15.26.000000000 PM
也可以用函數timestamp_to_scn將一個timestamp轉換為SCN：
- SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
- SCN
- 2877078439
最後，SCN除了作為反映事務數據變化並保持同步外，它還起到系統的“心跳”作用——每隔3秒左右系統會刷新一次系統SCN。
下面，在簡單介紹一下SCN如何在數據庫恢復中起作用。
數據庫在正常關閉（shutdown immediate/normal）時，會先做一次checkpoint，將log file中的數據寫入數據文件中，將控制文件、數據文件中的SCN（包括控制文件中的Stop SCN）都更新為最新的SCN。
數據庫異常/意外關閉不會或者只更新部分Stop SCN。
當數據庫啟動時，Oracle 先檢查控制文件中的每個Datafile Checkpoint SCN和數據文件中的Start SCN是否相同，再檢查每個Datafile Checkpoint SCN和Stop SCN是否相同。如果發現有不同，就從Redo Log中找到丟失的SCN，重新寫入數據文件中進行恢復。具體的數據恢復過程這裡就不再贅述。
SCN作為Oracle 中的一個重要機制，在多個重要功能中起著“控制器”的作用。了解SCN的產生和實現方式，幫助DBA理解和處理恢復、DG、Streams復制的問題。
最後提一句，利用Oracle SCN機制，在Oracle 10g、11g中又增加了一些很實用的功能——數據庫閃回、數據庫負載重現等。
