Oracle中的SCN詳解

SCN（System Chang 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中又增加了一些很實用的功能——資料庫閃回、資料庫負載重現等。

1.oracle正常執行時，control檔案的SCN是個很大的數，與redo log檔案、資料檔案的SCN不同，正常關閉時，做完checkpoint後，三者的SCN值相同;Biti:日誌檔案中scn有起始和結束2個（高低），在current log中高scn同樣為無窮大。
2.當一個事務commit成功時，redo log檔案中的SCN+1,當該事務所做的修改寫入資料檔案後，資料檔案的SCN+1；Biti:commit的時候加1，其他很多時候也會加1，只要資料庫發生了變化都會增加。資料寫入資料檔案時scn不是加1而是由ckpt更新，檢查點發生的時候才修改資料檔案頭的檢查點計數並更新scn。
3.疑問：
是不是如果一個事務比較大，在事務提交前就發生redo log entries、data buffer的寫入，此時斷電，則資料檔案、redo log檔案的SCN沒有+1，且相同，但控制檔案SCN不同，資料庫startup時發生回滾。Biti:資料檔案是由ckpt程式更新檔案頭的，scn不是加1，而是更新為檢查點發生那時的scn，回滾是根據回滾段頭的事務表狀態來進行的。

4.資料寫入資料檔案scn不是加1而是ckpt 更新，檢查點發生的時候才修改資料檔案頭的 檢查點計數和更新scn
是不是應該這麼說?:
當ckpt 更新時發生資料寫入，同時修改資料檔案頭的 檢查點計數和更新scn 。當出現其他情況下的資料寫入時（如無空閒緩衝等），不發生ckpt ，但SCN會增加。Biti:這個時候修改的是資料塊但不是資料檔案頭，只有檢查點發生的時候才更新資料檔案頭，也就是說只有ckpt程式更新資料檔案頭（oracle8以前如果沒有ckpt程式就是lgwr更新），dbwr只寫資料塊。

BTW:看樣DBWR只是些資料塊，只有CKPT程式才能更新資料檔案頭；
5.commit的時候加一，其他很多時候也會加1，只要資料庫發生了變化都會增加。
很多時候，能否舉一些例子Biti: dml一發生即使沒有提交也會增加scn, job程式一樣產生scn,只要對資料庫中檔案發生任何的改變都有可能產生scn,SCN: system change number, not system commit number .也就是系統發生變化時所產生的一個時間點

標誌。不是提交的標誌，只是因為提交也是系統的變化之一而已。

6.Biti:檢查點的發生，跟寫日誌檔案是沒有必然聯絡的
檢查點通知 DBWR 寫資料檔案，寫完後ckpt更新控制檔案頭和資料檔案頭。
當DBWR寫資料塊的時候若發現資料塊的相關 RDBA (位於日誌檔案的位置) 的 log block 還沒有被寫入日誌檔案，則在dbwr寫塊之前必須通知lgwr把log buffer 中日誌寫入日誌檔案。

7.data block 裡面的SCN是當 block 被更改的時候的SCN
而資料檔案有那麼多 block，自然不同的 block有不同的SCN
block中存在 block SCN 和 ITL 中的commit SCN

block SCN 又在塊頭和塊尾都有，若不一致意味著block損壞（熱備可能出現這個情況，需要從redo log中複製回來，若是正在修改的過程中由於程式死掉則 pmon負責清理。若 由於一些以外發生這樣的不一致的情況，則查詢的時候出現 1578 錯誤，當然該錯誤號也可能是物理磁碟損壞，這裡表示邏輯的損壞！）這個頭和尾的SCN的檢查時機跟這兩個引數有關：
db_block_checking boolean FALSE
db_block_checksum boolean FALSE

該2引數資訊請查閱

而ITL 中的 commit SCN 則跟 consistent gets and delay block cleanout 有關

資料檔案頭的 SCN 是檢查點發生時更新的
代表著 當 恢復的時候從這個 SCN 點 開始在 log file 中尋找 redo 開始做恢復

8.According to Rama Velpuri's book, CKPT updates controlfiles, not their headers. It makes sense because if you look at a controlfile dump, the header doesn't even have an SCN. But the file body has sections for each datafile, and therefore each of them has an SCN to be updated.

It's odd that most books and also documentation don't even say CKPT updates controlfiles.

Follow-up to bellsz's original message. In controlfiles, the stop SCN is not a very big number; it's in fact set to infinity when the database is open. Also, SCNs are incremented for many reasons, mostly due to recursive transactions. Read Steve Adams and Hemant Chitale's answers at
9.

系統檢查點scn(v$database(checkpoint_change#))
資料檔案檢查點（v$datafile(checkpoint_change#)）
資料檔案終止scn(v$datafile(last_change#))

資料檔案中存放的檢查點
啟動scn (v$datafile_header(checkpoint_change#)

1>系統檢查點scn
當一個檢查點動作完成之後，Oracle就把系統檢查點的SCN儲存到控制檔案中。
select checkpoint_change# from v$database
2>資料檔案檢查點scn
當一個檢查點動作完成之後，Oracle就把每個資料檔案的scn單獨存放在控制檔案
中。
select name,checkpoint_change# from v$datafile
3>啟動scn
Oracle把這個檢查點的scn儲存在每個資料檔案的檔案頭中，這個值稱為啟動scn，
因為它用於在資料庫例項啟動時，檢查是否需要執行資料庫恢復。
select name,checkpoint_change# from v$datafile_header
4>終止scn
每個資料檔案的終止scn都儲存在控制檔案中。
select name,last_change# from v$datafile
在正常的資料庫操作過程中，所有正處於聯機讀寫模式下的資料檔案的終止scn都為null.
5>在資料庫執行期間的scn值
在資料庫開啟並執行之後，控制檔案中的系統檢查點、控制檔案中的資料檔案檢查點scn
和每個資料檔案頭中的啟動scn都是相同的。控制檔案中的每個資料檔案的終止scn都為null.

在安全關閉資料庫的過程中，系統會執行一個檢查點動作，這時所有資料檔案的終止scn
都會設定成資料檔案頭中的那個啟動scn的值。在資料庫重新啟動的時候，
Oracle將檔案頭中的那個啟動scn與資料庫檔案檢查點scn進行比較，
如果這兩個值相互匹配，oracle接下來還要比較資料檔案頭中的啟動scn和控制檔案
中資料檔案的終止scn。如果這兩個值也一致，就意味著所有資料塊多已經提交，所有
對資料庫的修改都沒有在關閉資料庫的過程中丟失，因此這次啟動資料庫的過程
也不需要任何恢復操作，此時資料庫就可以開啟了。當所有的資料庫都開啟之後，
儲存在控制檔案中的資料檔案終止scn的值再次被更改為null，
這表示資料檔案已經開啟並能夠正常使用了。

10.

找了一些網頁,發現SCN確實不只在事務提交時增加,以下是網頁上的摘要:
1)
SCN means "System Change Number" not "System Commit Number".
However, because the SCN is always incremented at commits and seldom otherwise, it is OK to use the two terms interchangeably.
2)
The SCN is incremented whenever a transaction commits. However, this is not the only source of increments. In a seemingly idle database, the SCN gets incremented also through AQ, SMON, job queues...

1中說了 oracle seldom操作也會引起SCN的增加,2中更明確說了AQ, SMON, job queues... 會導致SCN的增加,因此應該得出結論,在ORACLE中除了COMMIT會導致SCN增加外還有其它的ORACLE後臺程式會導致SCN增加.

但是,是否是普通的DML導致了SCN的增加,還是由於DML操作過程中後臺程式導致了SCN增加的假象?請大家踴躍討論!
還有ORACLE後臺程式在何時,何種情況下導致了SCN增加,也請大家踴躍討論!

Biti:這句話我應該更準確第表達一下
如果一個dml導致產生事務，則會產生一個scn。這個意思是說
如果一個事務包含多個dml，則只有第一個初始產生事務的dml產生scn，提交的時候又是一個scn
如果一個事務只有一個dml，拿看起來就是dml產生一個scn，提交或者回滾產生一個scn
這是經過實驗測試過的，如果你又興趣，不緊緊是要找資料看，還可以動手證明。