Oracle中SCN與檢查點的示例分析-創(chuàng)新互聯(lián)

這篇文章主要介紹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ù)庫的內部時鐘機制，可被看作邏輯時鐘，每個數(shù)據(jù)庫都有一個全局的 SCN 生成器。

作為數(shù)據(jù)庫內部的邏輯時鐘，數(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內部的時鐘機制， 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ù)讀入內存中（Buffer Cache），修改數(shù)據(jù)的同時，Oracle 會記錄重做信息（Redo）用于恢復。因為有了重做信息的存在，Oracle 不需要在提交時立即將變化的數(shù)據(jù)寫回磁盤（立即寫的效率會很低），重做（Redo）的存在也正是為了在數(shù)據(jù)庫崩潰之后，數(shù)據(jù)可以恢復。

最常見的情況，數(shù)據(jù)庫可能因為斷電而 Crash，那么內存中修改過的、尚未寫入文件的數(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ù)庫內部操作的相關性極強，過于頻繁的檢查點同樣會帶來性能問題，尤其是更新頻繁的數(shù)據(jù)庫。所以數(shù)據(jù)庫的優(yōu)化是一個系統(tǒng)工程，不能草率。

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

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

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

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

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

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

猜你還喜歡下面的內容