Oracle SCN機(jī)制的詳細(xì)解析
Oracle SCN（System Chang Number）是Oracle 中的一個十分重要機(jī)制，在相關(guān)的數(shù)據(jù)恢復(fù)、Data Guard、與Streams復(fù)制、還有RAC節(jié)點(diǎn)間的相關(guān)同步等各個不同功能中起著十分重要作用。
理解SCN的運(yùn)作機(jī)制，可以幫助你更加深入地了解上述功能。
在理解Oracle 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ù)被標(biāo)識為“臟數(shù)據(jù)”，并被寫入log buffer中；
4、 事務(wù)提交，LGWR進(jìn)程將log buffer中的“臟數(shù)據(jù)”寫入redo log file中；
5、 當(dāng)發(fā)生checkpoint，CKPT進(jìn)程更新所有數(shù)據(jù)文件的文件頭中的信息，DBWn進(jìn)程則負(fù)責(zé)將Buffer Cache中的臟數(shù)據(jù)寫入到數(shù)據(jù)文件中。
經(jīng)過上述5個步驟，事務(wù)中的數(shù)據(jù)變化最終被寫入到數(shù)據(jù)文件中。但是，一旦在上述中間環(huán)節(jié)時，數(shù)據(jù)庫意外宕機(jī)了，在重新啟動時如何知道哪些數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)文件、哪些沒有寫呢（同樣，在DG、streams中也存在類似疑問：redo log中哪些是上一次同步已經(jīng)復(fù)制過的數(shù)據(jù)、哪些沒有）？SCN機(jī)制就能比較完善的解決上述問題。
SCN是一個數(shù)字，確切的說是一個只會增加、不會減少的數(shù)字。正是它這種只會增加的特性確保了Oracle 知道哪些應(yīng)該被恢復(fù)、哪些應(yīng)該被復(fù)制。
總共有4中SCN：系統(tǒng)檢查點(diǎn)（System Checkpoint）SCN、數(shù)據(jù)文件檢查點(diǎn)（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ù)庫正常運(yùn)行期間，Stop SCN(通過視圖v$datafile的字段last_change#可以查詢)是一個無窮大的數(shù)字或者說是NULL。
在一個事務(wù)提交后（上述第四個步驟），會在redo log中存在一條redo記錄，同時，系統(tǒng)為其提供一個***的Oracle SCN（通過函數(shù)dbms_flashback.get_system_change_number可以知道當(dāng)前的***SCN），記錄在該條記錄中。
如果該條記錄是在redo log被清空（日志滿做切換時或發(fā)生checkpoint時，所有變化日志已經(jīng)被寫入數(shù)據(jù)文件中），則其SCN被記錄為redo log的low SCN。以后在日志再次被清***寫入的redo記錄中SCN則成為Next SCN。
當(dāng)日志切換或發(fā)生checkpoint（上述第五個步驟）時，從Low SCN到Next SCN之間的所有redo記錄的數(shù)據(jù)就被DBWn進(jìn)程寫入數(shù)據(jù)文件中，而CKPT進(jìn)程則將所有數(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í)際上，這個數(shù)字是由當(dāng)時的timestamp轉(zhuǎn)換過來的。每當(dāng)需要產(chǎn)生一個***的Oracle SCN到redo記錄時，系統(tǒng)獲取當(dā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。
當(dāng)數(shù)據(jù)庫啟動時，Oracle 先檢查控制文件中的每個Datafile Checkpoint SCN和數(shù)據(jù)文件中的Start SCN是否相同，再檢查每個Datafile Checkpoint SCN和Stop SCN是否相同。如果發(fā)現(xiàn)有不同，就從Redo Log中找到丟失的SCN，重新寫入數(shù)據(jù)文件中進(jìn)行恢復(fù)。具體的數(shù)據(jù)恢復(fù)過程這里就不再贅述。
SCN作為Oracle 中的一個重要機(jī)制，在多個重要功能中起著“控制器”的作用。了解SCN的產(chǎn)生和實(shí)現(xiàn)方式，幫助DBA理解和處理恢復(fù)、DG、Streams復(fù)制的問題。
***提一句，利用Oracle SCN機(jī)制，在Oracle 10g、11g中又增加了一些很實(shí)用的功能——數(shù)據(jù)庫閃回、數(shù)據(jù)庫負(fù)載重現(xiàn)等。
【編輯推薦】
