checkpoint掃盲

什麼是checkpoint

在資料庫系統中，寫日誌和寫資料檔案是資料庫中IO消耗最大的兩種操作，在這兩種操作中寫資料檔案屬於分散寫，寫日誌檔案是順序寫，因此為了保證資料庫的效能，通常資料庫都是保證在提交（commit）完成之前要先保證日誌都被寫入到日誌檔案中，而髒資料塊著儲存在資料快取（buffer cache）中再不定期的分批寫入到資料檔案中。也就是說日誌寫入和提交操作是同步的，而資料寫入和提交操作是不同步的。這樣就存在一個問題，當一個資料庫崩潰的時候並不能保證快取裡面的髒資料全部寫入到資料檔案中，這樣在例項啟動的時候就要使用日誌檔案進行恢復操作，將資料庫恢復到崩潰之前的狀態，保證資料的一致性。檢查點是這個過程中的重要機制，透過它來確定，恢復時哪些重做日誌應該被掃描並應用於恢復。

一般所說的checkpoint是一個資料庫事件（event），checkpoint事件由checkpoint程式（LGWR/CKPT程式）發出，當checkpoint事件發生時DBWn會將髒塊寫入到磁碟中，同時資料檔案和控制檔案的檔案頭也會被更新以記錄checkpoint資訊。

checkpoint的作用

checkpoint主要2個作用：

1. 保證資料庫的一致性，這是指將髒資料寫入到硬碟，保證記憶體和硬碟上的資料是一樣的；

2. 縮短例項恢復的時間，例項恢復要把例項異常關閉前沒有寫出到硬碟的髒資料透過日誌進行恢復。如果髒塊過多，例項恢復的時間也會很長，檢查點的發生可以減少髒塊的數量，從而提高例項恢復的時間。

通俗的說checkpoint就像word的自動儲存一樣。

檢查點分類

· 完全檢查點（Normal checkpoint）

· 增量檢查點（Incremental checkpoint）

checkpoint相關概念術語

在說明checkpoint工作原理之前我們先了解一些相關的術語。

RBA（Redo Byte Address）, Low RBA（LRBA）, High RBA（HRBA）

RBA就是重做日誌塊（redo log block）的地址，相當與資料檔案中的ROWID，透過這個地址來定位重做日誌塊。RBA由三個部分組成：

1. 日誌檔案序列號（4位元組）

2. 日誌檔案塊編號（4位元組）

3. 重做日誌記錄在日誌塊中的起始偏移位元組數（2位元組）

通常使用RBA的形式有：

LRBA

資料快取（buffer cache）中一個髒塊第一次被更新的時候產生的重做日誌記錄在重做日誌檔案中所對應的位置就稱為LRBA。

HRBA

資料快取（buffer cache）中一個髒塊最近一次被更新的時候產生的重做日誌記錄在重做日誌檔案中所對應的位置就稱為HRBA。

checkpoint RBA

當一個checkpoint事件發生的時候，checkpoint程式會記錄下當時所寫的重做日誌塊的地址即RBA，此時記錄的RBA被稱為checkpoint RBA。從上一個checkpoint RBA到當前的checkpoint RBA之間的日誌所保護的buffer cache中的髒塊接下來將會被寫入到資料檔案當中去。

Buffer checkpoint Queues （BCQ）

Oracle將所有在資料快取中被修改的髒塊按照LRBA順序的組成一個checkpoint佇列，這個佇列主要記錄了buffer cache第一次發生變化的時間順序，然後有DBWn程式根據checkpoint佇列順序將髒塊寫入到資料檔案中，這樣保證了先發生變更的buffer能先被寫入到資料檔案中。BCQ的引入是為了支援增量checkpoint的。

Active checkpoint Queue （ACQ）

ACQ中包含了所有活動的checkpoint請求。每次有新checkpoint請求是都會在ACQ中增加一條記錄，ACQ記錄中包含了相應的checkpoint RBA。checkpoint完成以後相應的記錄將被移出佇列。

完全檢查點（normal checkpoint）

完全檢查點工作過程

一個checkpoint操作可以分成三個不同的階段：

· 第一階段，checkpoint程式開始一個checkpoint事件，並記錄下checkpoint RBA，這個通常是當前的RBA。

· 第二階段，checkpoint程式通知DBWn程式將所有checkpoint RBA之前的buffer cache裡面的髒塊寫入磁碟。

· 確定髒塊都被寫入磁碟以後進入到第三階段，checkpoint程式將checkpoint資訊（SCN）寫入/更新資料檔案和控制檔案中。

更新SCN的操作由CKPT程式完成，在Oracle 8.0之後CKPT程式預設是被啟用的，如果CKPT程式沒有啟用的話那相應的操作將由LGWR程式完成。

什麼時候發生normal checkpoint

下面這些操作將會觸發checkpoint事件：

· 日誌切換，透過ALTER SYSTEM SWITCH LOGFILE。

· DBA發出checkpoint命令，透過ALTER SYSTEM checkpoint。

· 對資料檔案進行熱備時，針對該資料檔案的checkpoint也會進行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。

· 當執行ALTER TABLESPACE/DATAFILE READ ONLY的時候。

· SHUTDOWN命令發出時。

特別注意：

1. 日誌切換會導致checkpoint事件發生，但是checkpoint發生卻不會導致日誌切換。

2. 日誌切換觸發的是normal checkpoint，而不是大家所說的增量checkpoint，只不過log switch checkpoint的優先順序非常低，當一個log switch checkpoint發生的時候它並不會立即的通知DBWn程式去寫資料檔案，但是當有其它原因導致checkpoint或者是寫入資料檔案的RBA超過log switch checkpoint的checkpoint RBA的時候，這次的log switch checkpoint將會被標記成完成狀態，同時更新控制檔案和資料檔案頭。我們隨後可以做個實驗驗證這個說法。

checkpoint和SCN有什麼關係？

在Oracle中SCN相當於它的時鐘，在現實生活中我們用時鐘來記錄和衡量我們的時間，而Oracle就是用SCN來記錄和衡量整個Oracle系統的更改。

Oracle中checkpoint是在一個特定的“時間點”發生的，衡量這個“時間點”用的就是SCN，因此當一個checkpoint發生時SCN會被寫入檔案頭中以記錄這個checkpoint。

增量checkpoint

增量checkpoint工作過程

因為每次完全的checkpoint都需要把buffer cache所有的髒塊都寫入到資料檔案中，這樣就是產生一個很大的IO消耗，頻繁的完全checkpoint操作很對系統的效能有很大的影響，為此Oracle引入的增量checkpoint的概念，buffer cache中的髒塊將會按照BCQ佇列的順序持續不斷的被寫入到磁碟當中，同時CKPT程式將會每3秒中檢查DBWn的寫入進度並將相應的RBA資訊記錄到控制檔案中。

有了增量checkpoint之後在進行例項恢復的時候就不需要再從崩潰前的那個完全checkpoint開始應用重做日誌了，只需要從控制檔案中記錄的RBA開始進行恢復操作，這樣能節省恢復的時間。

發生增量checkpoint的先決條件

· 恢復需求設定（FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）

· LOG_checkpoint_INTERVAL引數值

· LOG_checkpoint_TIMEOUT引數值

· 最小的日誌檔案大小

· buffer cache中的髒塊的數量

增量checkpoint的特點

· 增量checkpoint是一個持續活動的checkpoint。

· 沒有checkpoint RBA，因為這個checkpoint是一直都在進行的，所以不存在normal checkpoint裡面涉及的checkpoint RBA的概念。

· checkpoint advanced in memory only

· 增量checkpoint所完成的RBA資訊被記錄在控制檔案中。

· 增量checkpoint可以減少例項恢復時間。

增量checkpoint相關引數設定

log_checkpoint_interval

設定兩次checkpoint之間重做日誌塊（重做日誌塊和系統資料塊是一樣的）數，當重做日誌塊數量達到設定值的時候將觸發checkpoint。

log_checkpoint_timeout

設定兩次checkpoint之間的間隔時間，當超時值達到時增量checkpoint將被觸發。Oracle建議不用這個引數來控制，因為事務（transaction）大小不是按時間等量分佈的。將此值設定成0時將禁用此項設定。

fast_start_io_target

因為log_checkpoint_interval主要看的時候重做日誌塊的數量，並不能反應buffer cache中髒資料塊的修改，因此Oracle又引入了這個引數來實現當髒資料塊達到一定數量的時候觸發checkpoint，不過此引數實際上控制的是恢復時所需IO的數量。

fast_start_mttr_target

· 此引數是在9i中引入用來代替前面的三個引數的，它定義了資料塊崩潰後所需要的例項恢復的時間，Oracle在實際上內在的解釋成兩個引數:fast_start_io_target和log_checkpoint_interval.如果這兩個引數沒有顯式的指定,計算值將生效.。

· fast_start_mttr_target可以設定的最大值是3600，即一個小時。它的最小值沒有設限，但是並不是說可以設定一個任意小的值，這個值會受最小dirty buffer（最小為1000）的限制，同時還會受初始化時間以及檔案開啟時間的限制。

· 在設定此引數的時候要綜合考慮系統的IO，容量以及CPU等資訊，要在系統效能和故障恢復時間之間做好平衡。

· 將此引數設定成0時將禁用 fast-start checkpointing，這樣能見效系統負載但同時會增加系統的恢復時間。

· 如果fast_start_io_target or log_checkpoint_interval被指定，他們會自動覆蓋由fast_start_mttr_target引數計算出來的值。

在10g中，資料庫能根據各種系統引數的設定值來自動調整檢查點的執行頻率，以獲得最好的恢復時間以及系統的正常執行影響最小。透過自動checkpoint調整，Orach能在系統低IO操作的時候將髒塊寫入到資料檔案中，因此即時DBA沒有設定checkpoint相關的引數值或是設定了一個不合理的值的時候系統還是能獲得一個很合理的系統恢復時間。

10g中的增量checkpoint更能體現它持續活動的特點，在10g中，增量checkpoint不是在某一個特定的條件下觸發，而是由資料庫根據系統引數設定自動觸發。

與完全checkpoint的區別

· 完全checkpoint會將checkpoint的資訊寫入到控制檔案以及資料檔案頭中

· 增量checkpoint只會將RBA資訊寫入到控制檔案中。

檢視系統的checkpoint動作

我們可以透過將LOG_checkpointS_TO_ALERT設定成TRUE來開啟checkpoint的trace，這樣就可以跟蹤checkpoint的操作了。

ALTER SYSTEM SET LOG_checkpointS_TO_ALERT=TRUE;

這設定以後系統的checkpoint將會被記錄alert_$SID.log檔案中。

在V$DATAFILE_HEADER裡面也儲存了發生完全checkpoint的時候一些相關資訊，包括checkpoint發生時間、對應SCN已經checkpoint的次數。

select file# NO, status, tablespace_name, name, dbms_flashback.get_system_change_number CUR_SCN,
to_char（resetlogs_time, 'YYYY-MM-DD HH24:MI:SS'） RST_DT, resetlogs_change# RST_SCN,
to_char（checkpoint_time, 'YYYY-MM-DD HH24:MI:SS'） CKPT_DT, checkpoint_change# CKPT_SCN, checkpoint_count CKPT_CNT
from v$datafile_header;

/**
NO STATUS TABLESPACE_NAME CUR_SCN RST_DT RST_SCN CKPT_DT CKPT_SCN CKPT_CNT
--- ------- ---------------- -------- ------------------- -------- ------------------- --------- ---------
1 ONLINE SYSTEM 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 65
2 ONLINE UNDOTBS1 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 28
3 ONLINE SYSAUX 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 65
4 ONLINE USERS 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 64
5 ONLINE EXAMPLE 533541 2008-01-12 16:51:53 446075 2008-08-04 22:03:58 532354 24
*/

完全檢查點

-- 我們先執行一個
ALTER SYSTEM checkpoint;

-- 下面是alert檔案中的資料結果
Mon Aug  4 22:22:08 2008
Beginning global checkpoint up to RBA [0x8.c9d4.10], SCN: 533714
Completed checkpoint up to RBA [0x8.c9d4.10], SCN: 533714
-- 我們能看到完全checkpoint發生的SCN 533714

-- 下面我們再對照下V$DATAFILE_HEADER中的結果
NO  STATUS  TABLESPACE_NAME  CUR_SCN  RST_DT   RST_SCN  CKPT_DT CKPT_SCN  CKPT_CNT
--- ------- ---------------- -------- ------------------- -------- ------------------- --------- ---------
1 ONLINE  SYSTEM 533790 2008-01-12 16:51:53 446075 2008-08-04 22:22:08 533714   66
2 ONLINE  UNDOTBS1 533790 2008-01-12 16:51:53 446075 2008-08-04 22:22:08 533714   29
3 ONLINE  SYSAUX 533790 2008-01-12 16:51:53 446075 2008-08-04 22:22:08 533714   66
4 ONLINE  USERS   533790 2008-01-12 16:51:53 446075 2008-08-04 22:22:08 533714   65
5 ONLINE  EXAMPLE   533790 2008-01-12 16:51:53 446075 2008-08-04 22:22:08 533714   25

-- 看到了麼，checkpoint時間和checkpoint的SCN已經被記錄到資料檔案頭中了。

日誌切換時的檢查點

-- 我們先做一次日誌切換
ALTER SYSTEM SWITCH LOGFILE;

-- 然後看看alert裡面的記錄
Mon Aug  4 22:31:39 2008
Beginning log switch checkpoint up to RBA [0x9.2.10], SCN: 534450
Thread 1 advanced to log sequence 9
  Current log# 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.log
Mon Aug  4 22:35:58 2008
Completed checkpoint up to RBA [0x9.2.10], SCN: 534450

-- 我們能看到checkpoint是在過了一段時間（這裡是4分鐘）之後才完成的

-- 接著我們來看下V$DATAFILE_HEADER中的結果
NO  STATUS  TABLESPACE_NAME  CUR_SCN  RST_DT   RST_SCN  CKPT_DT CKPT_SCN  CKPT_CNT
--- ------- ---------------- -------- ------------------- -------- ------------------- --------- ---------
1 ONLINE  SYSTEM 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450   67
2 ONLINE  UNDOTBS1 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450   30
3 ONLINE  SYSAUX 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450   67
4 ONLINE  USERS   534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450   66
5 ONLINE  EXAMPLE   534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450   26

-- 在這裡我們能發現下V$DATAFILE_HEADER裡面記錄的SCN和日誌切換髮生的checkpoint的SCN是一樣的，
-- 這就證明了日誌切換是會更新資料檔案頭的，同時日誌切換的checkpoint是一個級別比較低的操作，
-- 它不會立即完成，這也是出於效能上考慮的。

增量checkpoint檢視

當前所知只有在LOG_checkpoint_TIMEOUT設定了非0值之後觸發的增量checkpoint會在alert檔案中有記錄，其他條件觸發的增量checkpoint都不會記錄在alert檔案中。

-- 下面是當LOG_checkpoint_TIMEOUT設定為1800s的時候所產生的增量checkpoint記錄
Sun Aug 3 19:08:56 2008
Incremental checkpoint up to RBA [0x8.e17.0], current log tail at RBA [0x8.1056.0]
Sun Aug 3 19:39:00 2008
Incremental checkpoint up to RBA [0x8.1be0.0], current log tail at RBA [0x8.1c6e.0]
Sun Aug 3 20:09:04 2008
Incremental checkpoint up to RBA [0x8.2af5.0], current log tail at RBA [0x8.2b6a.0]
Sun Aug 3 20:39:07 2008
Incremental checkpoint up to RBA [0x8.3798.0], current log tail at RBA [0x8.3851.0]
Sun Aug 3 21:09:10 2008
Incremental checkpoint up to RBA [0x8.47b9.0], current log tail at RBA [0x8.48bb.0]
Sun Aug 3 21:39:14 2008
Incremental checkpoint up to RBA [0x8.548d.0], current log tail at RBA [0x8.5522.0]
Mon Aug 4 21:05:18 2008

檢視fast_start_mttr_target

透過檢視V$INSTANCE_RECOVERY動態效能檢視可以檢視一些MTTR相關的資訊。

SELECT TARGET_MTTR,ESTIMATED_MTTR,CKPT_BLOCK_WRITES,CKPT_BLOCK_WRITES FROM V$INSTANCE_RECOVERY

TARGET_MTTR

使用者設定的引數FAST_START_MTTR_TARGET的值.

ESTIMATED_MTTR

根據目前髒塊數目和日誌塊數目,評估的現在進行恢復所需要的時間.

CKPT_BLOCK_WRITES

檢查點寫完的塊數目.

CKPT_BLOCK_WRITES

額外的因為檢查點引起的資料庫寫入操作（因為不必要的檢查點的產生,設定一個非常小的系統恢復時間將會對效能產生負面影響,為了幫助管理員監測這個引數設定較小時對資料庫的影響,這個檢視顯示了這個列）

相關檢視

V$檢視

V$DATAFILE_HEADER

檢視資料檔案的完全checkpoint資訊。

V$INSTANCE_RECOVERY

檢視fast_start_mttr_target設定以及系統MTTR相關資訊。

X$檢視

X$BH

用於檢視髒塊的LRBA和HRBA（There is also a recovery RBA which is used to record the progress of partial block recovery by PMON.）。

X$TARGETRBA

檢視增量checkpoint RBA，target RBA和on-disk RBA。

X$KCCCP

這裡面也有增量checkpoint RBA，target RBA的資訊。

X$KCCRT

完全checkpoint（full thread checkpoint）RBA資訊。

補充說明

寫完這篇文章之後又看了寫在itpub上的討論，更新下觀點。(http://www.itpub.net/viewthread.php?tid=1053847)

關於增量checkpoint和完全的checkpoint的區別這方面的爭論裡來不少，特別是對於日誌切換到底是增量還是完全的爭論更是如此，但是其實翻遍Oracle的文件就沒有發現有提到增量checkpoint(incremental checkpoint)或是完全checkpoint(full checkpoint)這兩個概念。

我的觀點是根本就沒有必要可以的區分是增量還是完全，真正要理解的是不同情況下的checkpoint都會有些什麼樣的行為，然後根據這些行為來對資料庫進行配置，設定相應的引數，制定相應的備份/恢復策略，就此而已。
下面列出寫常見的checkpoint行為：

1. 類似於alter system checkpoint這樣的語句所產生的，先記錄下當前的scn，然後推動DBWn程式去寫髒資料，當寫到所記錄的scn時候檢查點結束，然後ckpt程式將記錄的scn寫入到控制檔案和資料檔案頭。

2. 設定引數log_checkpoint_timeout之後產生的，在超時值達到的時候，ckpt程式記錄當時DBWn寫髒資料的進度，也就是寫到那個scn了，此時檢查點資訊只記錄到控制檔案中，同時如果設定了LOG_checkpointS_TO_ALERT的話我們會在alert中得到這樣的資訊：

Sun Aug 3 19:08:56 2008
Incremental checkpoint up to RBA [0x8.e17.0], current log tail at RBA [0x8.1056.0]

3. ckpt程式每3s起來一次記錄checkpoint的進度到控制檔案中，這種情況跟上面的類似，只不過在alert裡面是看不到的，而且也不是每次喚醒都會寫控制檔案的，而是有就記，沒有就拉倒。

4. 類似於alter system switch logfile所產生的，先記錄下發出命令時刻的scn，ckpt程式不會推動DBWn去寫髒資料，而是讓DBWn按照自己的狀態去寫髒資料，等到寫到記錄的scn時，chpt程式再去更新控制檔案和資料檔案頭。這種情況在alert也能看到資訊：

Mon Aug 4 22:31:39 2008
Beginning log switch checkpoint up to RBA [0x9.2.10], SCN: 534450
Thread 1 advanced to log sequence 9
Current log# 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.log
Mon Aug 4 22:35:58 2008
Completed checkpoint up to RBA [0x9.2.10], SCN: 534450

參考文件

· Metalink: Automatic checkpoint Tuning

· Metalink: checkpoint Tuning and Troubleshooting Guide

· Metalink: 8i Parameters that Influence checkpoints

· 《Oracle 9i&10G程式設計藝術》

· 《checkpointing in Oracle》
/files/Checkpointing_in_Oracle.pdf

· Redo Byte Address （RBA）
]

· 關於fast_start_io_target，log_checkpoint_interval，log_checkpoint_time的一點看法
http://www.itpub.net/148219.html

· Oracle 9i新特性研究系列之七

· checkpoint說明
http://airlgc.blog.51cto.com/161810/26175

· Oracle checkpoint

本文采用知識共享釋出，轉載請保留此資訊
作者：馬齒莧 | 連結：本文轉自http://www.cnblogs.com/sopost/archive/2011/06/22/2190033.html

Oracle checkpoint詳解

相關文章