[ADMIN]Something about checkpoint(zz from biti_rainy)

貼主： wanghai

checkpoint小議什麼是checkpoint?
checkpoint是一個資料庫事件，它將已修改的資料從快取記憶體重新整理到磁碟，並更新控制檔案和資料檔案。

什麼時候發生checkpoint?
我們知道了checkpoint會重新整理髒資料，但什麼時候會發生checkpoint呢？以下幾種情況會觸發checkpoint。
1.當發生日誌組切換的時候
2.當符合LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target引數設定的時候
3.當執行ALTER SYSTEM SWITCH LOGFILE的時候
4.當執行ALTER SYSTEM CHECKPOINT的時候
5.當執行alter tablespace XXX begin backup，end backup的時候
6.當執行alter tablespace ,datafile offline的時候;

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

資料字典
完全檢查點
select * from X$KCCRT where indx=0;

ADDR INDX INST_ID RTNUM RTSTA RTCKP_SCN RTCKP_TIM RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB RTOTF RTOTB RTNLF RTLFH RTLFT RTCLN RTSEQ RTENB RTETS RTDIS RTDIT RTLHP RTSID RTOTS
-------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ------------- ------------- ------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------------- -------------------- ---------- ---------------- --------------------
4084B228 0 1 1 15 720368521 06/25/2004 18:49:37 1 949 2 16 0600000000000000 2 0 3 1 3 1 949 1 05/16/2004 13:29:03 0 1389 tbdb2in1 06/12/2004 12:30:50

這裡顯示了上一次的完全檢查點是在06/25/2004 18:49:37發生，所以我們推斷06/25/2004 18:49:37發生了一次日誌切換，再去作業系統上去看生產的歸檔，果然18：49有一個歸檔生產。
-rw-r----- 1 oracle oinstall 83532800 Jun 25 18:49 1_948.dbf




增量檢查點
SQL> select * from X$KCCCP where indx=0;

ADDR INDX INST_ID CPTNO CPSTA CPFLG CPDRT CPRDB CPLRBA_SEQ CPLRBA_BNO CPLRBA_BOF CPODR_SEQ CPODR_BNO CPODR_BOF CPODS CPODT CPODT_I CPHBT CPRLS CPRLC CPMID CPSDR_SEQ CPSDR_BNO CPSDR_ADB
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ---------- ---------------- ---------- ---------- ---------- ---------- ----------
4084B45C 0 1 1 2 0 10762 29753 949 76847 0 949 106814 0 721554970 06/25/2004 21:05:10 529794310 529036227 1 526310932 1413781667 949 1 0

這裡顯示了low-rba,on-disk rba,checkpoint time等資訊。

biti_rainy:

每隔3秒鐘ckpt會去更新控制檔案和資料檔案，記錄checkpoint執行的情況。


這裡應該是隻更新控制檔案，每3秒不是更新資料檔案
說 記錄 checkpoint 的執行情況，這個說法，沒錯，但不夠詳細，應該說，由於增量檢查點和 checkpoint queue 的原理，ckpt 程式每次只是告訴 dbwr ，寫dirty buffer將要一直寫到最新這個位置，僅僅是告訴 dbwr 一個 checkpoint queue 中的結束點，而 ckpt 每3秒中，在控制檔案中報告一下 dbwr 最新寫入的位置。 這樣使得，比如資料庫要做恢復的時候（instance recovery）可以從這個最新位置開始做恢復，而不是從資料檔案中的 checkpoint scn 開始做恢復，這樣將縮短恢復時間，尤其是 instance crash 的情況下啟動更快

另外要注意的是，檢查點發生的時候，ckpt 去更新資料檔案頭和控制檔案，並不是把當前檢查點發生時候的 scn 更新進去，而是把上一次dbwr寫入已經完成的檢查點發生時候的 scn 更新進去 ，也就是說，更新控制檔案和資料檔案頭 是 滯後於檢查點的發生的，這個從恢復的原理也很容易理解，因為檢查點發生的時候 dirty buffer還沒有寫入，自然不能立即更新成當前的 scn 了。

jerrysun 轉：

something about checkpoint queue latchwanghai, the following is just for your reference. :)

Firstly we have two queue structures associated with checkpoints - the checkpoint queue - or thread queue - (CKPTQ), and the file queue.For each buffer to be checkpointed, it is linked to these two queues. The CKPTQ contains all buffers that need to be checkpointed for this instance. The File queue contains all buffers that belong to a specific file that need to be checkpointed. There is one file queue per file. The file queues are used by tablespace checkpoint requests.

Both these queues constitute a set of checkpoint queues.

Before a process can put a buffer on a checkpoint queue, it must make sure that the queue is not being used. There is one checkpoint queue latch per set of checkpoint queues, that is used to control access to these queues. To reduce contention on this latch, the set of thread and file queues is replicated as per the number of working sets for the instance.

The determination of the number of working sets has changed across the DB versions. For 9.2, the default number is calculated
internally as #CPUs / 2 * 8.

The maximum of DBWR's (db_writer_processes) you can have at 9.2 is 20. Working sets are assigned to DBWR's in a round-robin
fashion at startup.

[@more@]So