這篇文章主要介紹Oracle中SCN與檢查點的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比曲沃網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式曲沃網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋曲沃地區(qū)。費用合理售后完善，10余年實體公司更值得信賴。

1．SCN 的定義

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

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

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

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

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

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

2．SCN 的獲取方式

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

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

3．SCN 的進一步說明

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

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

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

4．檢查點

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

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

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

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

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

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

Checkpoint SCN 可以從數(shù)據(jù)庫中查詢得到：

SQL> select file#,NAME,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy -mm-dd hh34:mi:ss') CPT from v$datafile; 
   FILE# NAME                                       CHECKPOINT_CHANGE# CPT
---------- -------------------------------------------------------------------------------- ------------------ --------------------
     1 /u01/app/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:32
8 rows selected

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

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

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

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

以上是“Oracle中SCN與檢查點的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

網(wǎng)頁題目：Oracle中SCN與檢查點的示例分析-創(chuàng)新互聯(lián)
本文地址：http://jinyejixie.com/article12/pejdc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、響應式網(wǎng)站、動態(tài)網(wǎng)站、云服務器、網(wǎng)站內(nèi)鏈、品牌網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)