在實例經過分配內存結構，加載控制文件后，然后要打開數據庫的時候，需要做到控制文件，數據文件，聯機重做日志保持相互狀態一致性，數據庫才可以打開。當數據庫發生實例不正常關閉時（比如系統掉電或者Shutdown abort?進行關閉），要進行實例恢復，Oracle?數據庫具有相應的機制來實現這一點。

像任何一家公司一樣，不同的員工具有不同的技能專長，負責不同的工作，但是一個成功的項目，需要一個優秀的項目經理，來保持，督促項目中的成員各自工作步調相互一致。在Oracle?實例中，這樣的一個重要角色，被檢查點(CheckPoint)?進程（CKPT）擔任。Oracle?實例在必要的時候，出現檢查點，當檢查點出現時，CKPT?進程一方面催促DBWR?進程及時地把該檢查點時刻前DB_Buffer?中一些被修改過的數據及時寫入數據文件中，寫完之后，CKPT?進程更新相關的數據文件和控制文件的同步時刻點。也就是說，Oracle?實例在運行過程中，需要CKPT?進程來定期同步控制文件、數據文件和聯機日志文件的“時間點”。

大多數關系型數據庫都采用“在提交時并不強迫針對數據塊的修改完成”而是“提交時保證修改記錄（以重做日志的形式）寫入日志文件”的機制，來獲得性能的優勢。這句話的另外一種描述是：當用戶提交事務，寫數據文件是“異步”的，寫日志文件是“同步”的。這就可能導致數據庫實例崩潰時，內存中的DB_Buffer?中的修改過的數據，可能沒有寫入到數據塊中。數據庫在重新打開時，需要進行恢復，來恢復DB Buffer?中的數據狀態，并確保已經提交的數據被寫入到數據塊中。檢查點是這個過程中的重要機制，通過它來確定，恢復時哪些重做日志應該被掃描并應用于恢復。

檢查點和檢查點進程的操作的三個步驟：

A、系統觸發一個檢查點，系統并記錄該檢查點時刻的Checkpoint SCN?號，并記錄該時刻修改的DB Buffer的塊所參考的RBA?作為Checkpoint RBA RBA (Redo Byte Address)。

B、該Checkpoint RBA?之前的日志實體所參考的DB_Buffer?中數據塊的修改，要被寫出到數據文件中。

C、完成２步驟后，CKPT?進程記錄該檢查點完成信息到控制文件。

只有上面三個步驟完成，才表示系統的檢查點已經被推進，推進了日志文件，數據文件，控制文件到一個新的“同步點”。

檢查點只發生在下列情形：

　　管理員使用：Alter system checkpoint?命令；

　　實例被正常的關閉；

　　特別注意：日志切換并不導致一個完全檢查點的發生。

如何確定哪些DB_Buffer中的數據塊需要被寫到磁盤上，是一個蠻復雜的算法。大致思想就是：所有dirty data按照Low RBA?的升序進行鏈接成一個list，當CKPT被喚醒的時候，首先先從控制文件讀取上次check point，把中間這段時間的dirty data?寫到磁盤上。

二、觸發的條件

這里需要明白兩個概念“完全檢查點和增量檢查點”的區別。

增量檢查點（incremental checkpoint）
oracle8以后推出了incremental?checkpoint的機制，在以前的版本里每checkpoint時都會做一個full thread checkpoint,這樣的話所有臟數據會被寫到磁盤，巨大的i/o對系統性能帶來很大影響。為了解決這個問題，oracle引入了checkpoint queue機制，每一個臟塊會被移到檢查點隊列里面去，按照low rdb（第一次對此塊修改對應的redo block address）來排列，靠近檢查點隊列尾端的數據塊的low rba值是最小的，而且如果這些贓塊被再次修改后它在檢查點隊列里的順序也不會改變，這樣就保證了越早修改的塊越早寫入磁盤。每隔3秒鐘ckpt會去更新控制文件和數據文件，記錄checkpoint執行的情況。

在運行的Oracle?數據中，有很多事件、條件或者參數來觸發檢查點。比如
????????l?當已通過正常事務處理或者立即選項關閉例程時；（shutdown immediate或者Shutdown normal;）
???????l??當通過設置初始化參數LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT?和FAST_START_IO_TARGET?強制時；
????????l?當數據庫管理員手動請求時；（ALter system checkpoint）

?l?alter tablespace ... offline;

???l??每次日志切換時;（alter system switch logfile）

需要說明的是，alter system switch logfile也將觸發完全檢查點的發生。

alter database datafile ... offline不會觸發檢查點進程。

如果是單純的offline datafile，那么將不會觸發文件檢查點，只有針對offline tablespace的時候才會觸發文件檢查點，這也是為什么online datafile需要media recovery而online tablespace不需要。

對于表空間的offline后再online這種情況，最好做個強制的checkpoint比較好。

　　上面幾種情況，將觸發完全檢查點，促使DBWR?將檢查點時刻前所有的臟數據寫入數據文件。

另外，一般正常運行期間的數據庫不會產生完全檢查點，下面很多事件將導致增量檢查點，比如：

在聯機熱備份數據文件前，要求該數據文件中被修改的塊從DB_Buffer?寫入數據文件中。所以，發出這樣的命令：

l??ALTER TABLESPACE tablespace_name BIGEN BACKUP & end backup;?也將觸發和該表空間的數據文件有關的局部檢查點；另外，

l??ALTER TABLESPACE tablespace_name READ ONLY;

l??ALTER TABLESPACE tablespace_name OFFLINE NORMAL;

等命令都會觸發增量檢查點。

三、檢查點位置的影響因素

相比傳統檢查點（也就是指那些有明確含義的檢查點）?，增量檢查點可以平緩的、持續的推進日志文件和數據文件的同步點。理解這一點是學習Checlpoint?有關原理的關鍵點。實際上，對于增量檢查點，主要討論的并不是什么時候出現增量檢查點，而是：如何控制增量檢查點推進的速率？檢查點本質上是為了推進寫日志和寫數據.

文件的“異步機制”的同步，我們感興趣的內容終究要歸結到：系統崩潰時，“異步的距離”將需要系統多少時間來進行恢復？事實上，Oracle?正是這樣設計的，數據庫提供了一些參數設置（以oracle 9.2?為例）

A、FAST_START_MTTR_TARGET?參數來控制增量檢查點的推進速率

我們都希望當實例崩潰后，恢復需要讀取的日志流盡可能的短，恢復需要的時間盡可能的短。這樣，我們會將FAST_START_MTTR_TARGET?設置值更小,?增量檢查點會出現的更加密集頻繁。但設置值太小，將顯劇增加DBWR?寫數據文件的工作量，寫數據文件的I/O?的增加將降低系統的性能，降低“寫日志文件和寫數據文件的異步機制”所帶來的性能效益。

難以說明設置FAST_START_MTTR_TARGET?為多少是合適的設置，這和我們各自的數據庫應用業務有關。Oracle?提供了一個視圖V$MTTR_TARGET_ADVICE?作為我們設置參考，從該視圖中，Oracle?會給出一些估計，當您設置不同的FAST_START_MTTR_TARGET?的值時，對應的物理寫數據文件的數量的估計值。我們可以選擇一個合適的值，可以降低恢復時間，但是不讓DBWR?的工作量增加太大。

數據庫在“事務”當中發生變化，Oraccle?數據庫系統使用系統變更號（System Change Number，簡寫為SCN）來記錄數據庫內部的變化。數據庫內部的很多事件，以及用戶通過SQL?語句對數據庫內容進行變化，會讓SCN?值增長。

　　我們知道，當應用程序提交（Commit）某個事務時，先是日志寫入進程（LGWR）將Log Buffer?中的該事務的紀錄寫入到聯機重做日志文件成功后，才由Service Process?通知相關的用戶進程：你的提交已成功。

檢查點出現，將推動檢查點時刻前的日志文件中所參考的數據塊的修改，已經被DBWR?寫入到數據文件中。CKPT進程會紀錄該檢查點的Checkpoint SCN?的信息到數據文件和控制文件中。從而推動了數據庫的一個“同步點”。如果在下一個同步點完成之前，數據庫發生失敗，在數據庫的實例恢復從系統當前檢查點開始，運用后面的日志進行實例恢復。

可以看出，檢查點的出現，可以讓數據庫在運行時，“定期”的維護日志文件，數據文件進行狀態一致性。有些類似于我們生活中：不同的公司定期的賬目結清，當一個檢查點完成后，大家都承認，這個時間之前的一切賬目已經結清。

?

轉載于:https://www.cnblogs.com/rusking/p/4670459.html

總結

以上是生活随笔為你收集整理的Oracle CheckPoint进程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。