SCN（System Change Number）作為oracle中的一個重要機制，在數據恢復、Data Guard、Streams復制、RAC節點間的同步等各個功能中起著重要作用。理解SCN的運作機制，可以幫助你更加深入地了解上述功能。

在理解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記錄，同時，系統為其提供一個最新的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轉換過來的。每當需要產生一個最新的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復制的問題。

最后提一句，利用SCN機制，在Oracle10g、11g中又增加了一些很實用的功能——數據庫閃回、數據庫負載重現等。

總結

以上就是本文關于淺談oracle SCN機制的全部內容，希望對大家有所幫助。有興趣的朋友可以參閱：Oracle EBS工具選項：關閉其他表單修改方法 、 oracle 數據庫啟動階段分析 、 oracle 虛擬專用數據庫詳細介紹等。有什么問題可以隨時留言，小編會及時回復大家的。感謝大家對腳本之家的支持！