ZT Oracle SCN機制解析

asword發表於2009-02-01
SCNSystem Chang Number)作為中的一個重要機制,在資料恢復、Data GuardStreams複製、RAC節點間的同步等各個功能中起著重要作用。理解SCN的運作機制,可以幫助你更加深入地瞭解上述功能。[@more@]

在理解SCN之前,我們先看下oracle事務中的資料變化是如何寫入資料檔案的:

1、事務開始;

2、buffer cache中找到需要的資料塊,如果沒有找到,則從資料檔案中載入buffer cache中;

3、事務修改buffer cache的資料塊,該資料被標識為“髒資料”,並被寫入log buffer中;

4、事務提交,LGWR程式將log buffer中的“髒資料”寫入redo log file中;

5、當發生checkpointCKPT程式更新所有資料檔案的檔案頭中的資訊,DBWn程式則負責將Buffer Cache中的髒資料寫入到資料檔案中。

經過上述5個步驟,事務中的資料變化最終被寫入到資料檔案中。但是,一旦在上述中間環節時,意外當機了,在重新啟動時如何知道哪些資料已經寫入資料檔案、哪些沒有寫呢(同樣,在DGstreams中也存在類似疑問:redo log中哪些是上一次同步已經複製過的資料、哪些沒有)?SCN機制就能比較完善的解決上述問題。

SCN是一個數字,確切的說是一個只會增加、不會減少的數字。正是它這種只會增加的特性確保了Oracle知道哪些應該被恢復、哪些應該被複制。

總共有4SCN:系統檢查點(System CheckpointSCN、資料檔案檢查點(Datafile CheckpointSCN、結束SCNStop SCN)、開始SCNStart SCN)。其中其面3SCN存在於控制檔案中,最後一種則存在於資料檔案的檔案頭中。

在控制檔案中,System Checkpoint SCN是針對整個資料庫全域性的,因而之存在一個,而Datafile Checkpoint SCNStop SCN是針對每個資料檔案的,因而一個資料檔案就對應在控制檔案中存在一份Datafile Checkpoint SCNStop SCN。在資料庫正常執行期間,Stop SCN(透過檢視v$datafile的欄位last_change#可以查詢)是一個無窮大的數字或者說是NULL

在一個事務提交後(上述第四個步驟),會在redo log中存在一條redo記錄,同時,系統為其提供一個最新的SCN(透過函式dbms_flashback.get_system_change_number可以知道當前的最新SCN),記錄在該條記錄中。如果該條記錄是在redo log被清空(日誌滿做切換時或發生checkpoint時,所有變化日誌已經被寫入資料檔案中),則其SCN被記錄為redo loglow SCN。以後在日誌再次被清空前寫入的redo記錄中SCN則成為Next SCN

當日志切換或發生checkpoint(上述第五個步驟)時,從Low SCNNext 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轉換過來的。每當需要產生一個最新的SCNredo記錄時,系統獲取當時的timestamp,將其轉換為數字作為SCN。我們可以透過函式SCN_TO_TIMESTAMP10g以後)將其轉換回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 SCNStop SCN是否相同。如果發現有不同,就從Redo Log中找到丟失的SCN,重新寫入資料檔案中進行恢復。具體的資料恢復過程這裡就不再贅述。

SCN作為Oracle中的一個重要機制,在多個重要功能中起著“控制器”的作用。瞭解SCN的產生和實現方式,幫助DBA理解和處理恢復、DGStreams複製的問題。

最後提一句,利用SCN機制,在Oracle10g中又增加了一些很實用的功能——資料庫閃回、資料庫負載重現等。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/82387/viewspace-1016541/,如需轉載,請註明出處,否則將追究法律責任。

相關文章