1．SCN 的定義

SCN（System Change Number ），也就是通常所說的系統改變號，是數據庫中非常重要的 一個數據結構。

SCN 用以標識數據庫在某個確切時刻提交的版本。在事務提交時，它被賦予一個惟一的 標識事務的SCN。SCN 同時被作為 Oracle數據庫的內部時鐘機制，可被看作邏輯時鐘，每個 數據庫都有一個全局的 SCN 生成器。

作為數據庫內部的邏輯時鐘，數據庫事務依 SCN 而排序，Oracle 也依據 SCN 來實現一致性讀 （Read Consistency ）等重要數據庫功能。另外對于分布式事務（Distributed Transactions）， SCN 也極為重要，這里不作更多介紹。

SCN 在數據庫中是惟一的，并隨時間而增加，但是可能并不連貫。除非重建數據庫，SCN 的值永遠不會被重置為 0。

一直以來，對于 SCN 有很多爭議，很多人認為 SCN 是指 System Commit Number ，而通常 SCN 在提交時才變化，所以很多時候，這兩個名詞經常在文檔中反復出現。即使在Oracle 的 官方文檔中，SCN 也常以 System Change/Commit Number 兩種形式出現。 到底是哪個詞其實不是最重要的，重要的是需要知道 SCN 是Oracle內部的時鐘機制， Oracle通過SCN 來維護數據庫的一致性，并通過 SCN 實施Oracle至關重要的恢復機制。 SCN 在數據庫中是無處不在的，常見的事務表、控制文件、數據文件頭、日志文件、數 據塊頭等都記錄有 SCN 值。

冠以不同前綴，SCN 也有了不同的名稱，如檢查點SCN（Checkpoint SCN ）、Resetlogs SCN 等。

2．SCN 的獲取方式

可以通過如下幾種方式獲得數據庫的當前或近似 SCN。

SQL> SELECT dbms_flashback.get_system_change_number FROM DUAL; GET_SYSTEM_CHANGE_NUMBER------------------------      6051905241299SQL>

3．SCN 的進一步說明

系統當前SCN 并不是在任何的數據庫操作發生時都會改變，SCN 通常在事務提交或回滾 時改變。在控制文件、數據文件頭、數據塊、日志文件頭、日志文件 change vector 中都有 SCN，但其作用各不相同。

（1）數據文件頭中包含了該數據文件的 Checkpoint SCN，表示該數據文件最近一次執行 檢查點操作時的 SCN。

對于每一個數據文件都包含一個這樣的條目，記錄該文件的檢查點 SCN 的值以及檢查點 發生的時間，這里的Checkpoint SCN 、Stop SCN以及 Checkpoint Cnt 都是非常重要的數據 結構.

4．檢查點

許多文檔把Checkpoint 描述得非常復雜，為我們正確理解檢查點帶來了障礙，結果現在 檢查點變成了一個非常復雜的問題。實際上，檢查點只是一個數據庫事件，它存在的根本意 義在于減少崩潰恢復（Crash Recovery ）時間。

當修改數據時，需要首先將數據讀入內存中（Buffer Cache），修改數據的同時，Oracle 會記錄重做信息（Redo）用于恢復。因為有了重做信息的存在，Oracle 不需要在提交時立即 將變化的數據寫回磁盤（立即寫的效率會很低），重做（Redo）的存在也正是為了在數據庫崩 潰之后，數據可以恢復。

最常見的情況，數據庫可能因為斷電而 Crash，那么內存中修改過的、尚未寫入文件的 數據將會丟失。在下一次數據庫啟動之后，Oracle 可以通過重做日志（Redo）進行事務重演 （也就是進行前滾），將數據庫恢復到崩潰之前的狀態，然后數據庫可以打開提供使用，之后 Oracle可以將未提交的事務進行回滾。

在這個過程中，通常大家最關心的是數據庫要經歷多久才能打開。也就是需要讀取多少 重做日志才能完成前滾。當然用戶希望這個時間越短越好，Oracle 也正是通過各種手段在不 斷優化這個過程，縮短恢復時間。

檢查點的存在就是為了縮短這個恢復時間。

當檢查點發生時（此時的SCN 被稱為Checkpoint SCN ），Oracle會通知DBWR進程，把 修改過的數據，也就是此Checkpoint SCN之前的臟數據（Dirty Data）從Buffer Cache 寫入磁盤，當寫入完成之后，CKPT進程更新控制文件和數據文件頭，記錄檢查點信息，標 識變更。

Checkpoint SCN 可以從數據庫中查詢得到：

SQL> select file#,NAME,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy -mm-dd hh24:mi:ss') CPT from v$datafile;    FILE# NAME                                       CHECKPOINT_CHANGE# CPT---------- -------------------------------------------------------------------------------- ------------------ --------------------     1 /u01/app/oracle/120379.html">oracle/oradata/orcl/system01.dbf                       6051905239995 2016 -05-05 04:14:32     2 /u01/app/oracle/oradata/orcl/sysaux01.dbf                       6051905239995 2016 -05-05 04:14:32     3 /u01/app/oracle/oradata/orcl/undotbs01.dbf                      6051905239995 2016 -05-05 04:14:32     4 /u01/app/oracle/oradata/orcl/users01.dbf                       6051905239995 2016 -05-05 04:14:32     5 /u01/app/oracle/oradata/orcl/example01.dbf                      6051905239995 2016 -05-05 04:14:32     6 /u01/app/oracle/oradata/orcl/DEV_odi_user.dbf                     6051905239995 2016 -05-05 04:14:32     7 /u01/app/oracle/oradata/orcl/apex_01.dbf                       6051905239995 2016 -05-05 04:14:32     8 /u01/app/oracle/oradata/orcl/APEX_6121090681146232.dbf                6051905239995 2016 -05-05 04:14:328 rows selected

在檢查點完成之后，此檢查點之前修改過的數據都已經寫回磁盤，重做日志文件中的相 應重做記錄對于崩潰/實例恢復不再有用。

檢查點的頻度對于數據庫的恢復時間具有極大的影響， 如果檢查點的頻率高，那么恢復時需要應用的重做日志就相對得少，恢復時間就可以縮短。 然而，需要注意的是，數據庫內部操作的相關性極強，過于頻繁的檢查點同樣會帶來性能問 題，尤其是更新頻繁的數據庫。所以數據庫的優化是一個系統工程，不能草率。

更進一步可以知道，如果Oracle 可以在性能允許的情況下，使得檢查點的SCN 逐漸逼近 Redo的最新變更，那么最終可以獲得一個最佳平衡點，使得 Oracle 可以最大化的減少恢復 時間。

為了實現這個目標，Oracle 在不同版本中一直在改進檢查點的算法。

總結

以上就是本文關于Oracle SCN與檢查點詳解的全部內容，希望對大家有所幫助。有什么問題可以隨時留言，小編會及時回復大家的。