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

在理解SCN之前，我們先看下oracle事務(wù)中的數(shù)據(jù)變化是如何寫入數(shù)據(jù)文件的：

1、事務(wù)開始；

2、在buffer cache中找到需要的數(shù)據(jù)塊，如果沒有找到，則從數(shù)據(jù)文件中載入buffer cache中；

3、事務(wù)修改buffer cache的數(shù)據(jù)塊，該數(shù)據(jù)被標識為“臟數(shù)據(jù)”，并被寫入log buffer中；

4、事務(wù)提交，LGWR進程將log buffer中的“臟數(shù)據(jù)”寫入redo log file中；

5、當發(fā)生checkpoint，CKPT進程更新所有數(shù)據(jù)文件的文件頭中的信息，DBWn進程則負責將Buffer Cache中的臟數(shù)據(jù)寫入到數(shù)據(jù)文件中。

經(jīng)過上述5個步驟，事務(wù)中的數(shù)據(jù)變化最終被寫入到數(shù)據(jù)文件中。但是，一旦在上述中間環(huán)節(jié)時，數(shù)據(jù)庫意外宕機了，在重新啟動時如何知道哪些數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)文件、哪些沒有寫呢（同樣，在DG、streams中也存在類似疑問：redo log中哪些是上一次同步已經(jīng)復(fù)制過的數(shù)據(jù)、哪些沒有）？SCN機制就能比較完善的解決上述問題。

SCN是一個數(shù)字，確切的說是一個只會增加、不會減少的數(shù)字。正是它這種只會增加的特性確保了Oracle知道哪些應(yīng)該被恢復(fù)、哪些應(yīng)該被復(fù)制。

總共有4中SCN：系統(tǒng)檢查點（System Checkpoint）SCN、數(shù)據(jù)文件檢查點（Datafile Checkpoint）SCN、結(jié)束SCN（Stop SCN）、開始SCN（Start SCN）。其中其面3中SCN存在于控制文件中，最后一種則存在于數(shù)據(jù)文件的文件頭中。

在控制文件中，System Checkpoint SCN是針對整個數(shù)據(jù)庫全局的，因而之存在一個，而Datafile Checkpoint SCN和Stop SCN是針對每個數(shù)據(jù)文件的，因而一個數(shù)據(jù)文件就對應(yīng)在控制文件中存在一份Datafile Checkpoint SCN和Stop SCN。在數(shù)據(jù)庫正常運行期間，Stop SCN(通過視圖v$datafile的字段last_change#可以查詢)是一個無窮大的數(shù)字或者說是NULL。

在一個事務(wù)提交后（上述第四個步驟），會在redo log中存在一條redo記錄，同時，系統(tǒng)為其提供一個最新的SCN（通過函數(shù)dbms_flashback.get_system_change_number可以知道當前的最新SCN），記錄在該條記錄中。如果該條記錄是在redo log被清空（日志滿做切換時或發(fā)生checkpoint時，所有變化日志已經(jīng)被寫入數(shù)據(jù)文件中），則其SCN被記錄為redo log的low SCN。以后在日志再次被清空前寫入的redo記錄中SCN則成為Next SCN。

當日志切換或發(fā)生checkpoint（上述第五個步驟）時，從Low SCN到Next SCN之間的所有redo記錄的數(shù)據(jù)就被DBWn進程寫入數(shù)據(jù)文件中，而CKPT進程則將所有數(shù)據(jù)文件（無論redo log中的數(shù)據(jù)是否影響到該數(shù)據(jù)文件）的文件頭上記錄的Start SCN(通過視圖v$datafile_header的字段checkpoint_change#可以查詢)更新為Next SCN，同時將控制文件中的System Checkpoint SCN（通過視圖v$database的字段checkpoint_change#可以查詢）、每個數(shù)據(jù)文件對應(yīng)的Datafile Checkpoint（通過視圖v$datafile的字段checkpoint_change#可以查詢）也更新為Next SCN。但是，如果該數(shù)據(jù)文件所在的表空間被設(shè)置為read-only時，數(shù)據(jù)文件的Start SCN和控制文件中Datafile Checkpoint SCN都不會被更新。

那系統(tǒng)是如何產(chǎn)生一個最新的SCN的？實際上，這個數(shù)字是由當時的timestamp轉(zhuǎn)換過來的。每當需要產(chǎn)生一個最新的SCN到redo記錄時，系統(tǒng)獲取當時的timestamp，將其轉(zhuǎn)換為數(shù)字作為SCN。我們可以通過函數(shù)SCN_TO_TIMESTAMP（10g以后）將其轉(zhuǎn)換回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

也可以用函數(shù)timestamp_to_scn將一個timestamp轉(zhuǎn)換為SCN：

SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
 
  SCN
----------
2877078439

最后，SCN除了作為反映事務(wù)數(shù)據(jù)變化并保持同步外，它還起到系統(tǒng)的“心跳”作用——每隔3秒左右系統(tǒng)會刷新一次系統(tǒng)SCN。

下面，在簡單介紹一下SCN如何在數(shù)據(jù)庫恢復(fù)中起作用。

數(shù)據(jù)庫在正常關(guān)閉（shutdown immediate/normal）時，會先做一次checkpoint，將log file中的數(shù)據(jù)寫入數(shù)據(jù)文件中，將控制文件、數(shù)據(jù)文件中的SCN（包括控制文件中的Stop SCN）都更新為最新的SCN。

數(shù)據(jù)庫異常/意外關(guān)閉不會或者只更新部分Stop SCN。

當數(shù)據(jù)庫啟動時，Oracle先檢查控制文件中的每個Datafile Checkpoint SCN和數(shù)據(jù)文件中的Start SCN是否相同，再檢查每個Datafile Checkpoint SCN和Stop SCN是否相同。如果發(fā)現(xiàn)有不同，就從Redo Log中找到丟失的SCN，重新寫入數(shù)據(jù)文件中進行恢復(fù)。具體的數(shù)據(jù)恢復(fù)過程這里就不再贅述。

SCN作為Oracle中的一個重要機制，在多個重要功能中起著“控制器”的作用。了解SCN的產(chǎn)生和實現(xiàn)方式，幫助DBA理解和處理恢復(fù)、DG、Streams復(fù)制的問題。

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

總結(jié)

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

最新評論