一、檢查點概述
大多數關係型數據庫都採用 “ 在提交時並不強迫針對數據塊的修改完成 ” 而是 “ 提交時保證修改記錄（以重做日誌的形式）寫入日誌文件 ” 的機制，來獲得性能的優勢。這句話的另外一種描述是：當用戶提交事務，寫數據文件是 “ 異步 ” 的，寫日誌文件是 “ 同步 ” 的。這就可能導致數據庫實例崩潰時，內存中的 DB_Buffer 中的修改過的數據，可能沒有寫入到數據塊中。數據庫在重新打開時，需要進行恢復，來恢復 DB Buffer 中的數據狀態，並確保已經提交的數據被寫入到數據塊中。檢查點是這個過程中的重要機制，通過它來確定，恢復時哪些重做日誌應該被掃描並應用於恢復。
要了解這個檢查點，首先要知道
checkpoint queu
概念，檢查點發生後，觸發
dbwn
，
CKPT
獲取發生檢查點時對應的
SCN
，通知
DBWn
要寫到這個
SCN
爲止，
dbwr
寫
dirty buffer
是根據
buffer
在被首次
modify
的時候的時間的順序寫出，也就是
buffer
被
modify
的時候會進入一個
queue
（
checkpoint queue
），
dbwr
就根據
queue
從其中批量地寫到數據文件。
由於這裏有一個順序的關係，所以
dbwr
的寫的進度就是可衡量的，寫到哪個
buffer
的時候該
buffer
的首次變化時候的
scn
就是當前所有數據文件
block
的最新
scn
，但是由於無法適時的將
dbwr
的進度記錄下來，所以
oracle
選擇了一些策略。
其中就包括
ckpt
進程的檢查點和心跳。
但 oracle 考慮到檢查點 scn 的間隔還是太大了，因爲檢查點的觸發條件有限，週期可能比較長，有些情況下比如檢查點需要 5 分鐘才觸發，那這個時候系統 crash 再重新啓動就意味着很可能系統需要 5 分鐘才能啓動。
於是 oracle 採用了一個 心跳的概念，以 3 秒的頻率將 dbwr 寫的進度反應到控制文件中，這樣系統 crash 重新啓動的時候將從更近的一個 時間點開始恢復。
再這裏同樣需要說明的一點是 dbwr 並不是只有當 檢查點發生的時候才寫，它大約有 10 幾種條件觸發寫操作
所以這個問題，我們需要理解的是 oracle 爲什麼要這麼做？
oracle 的目的就是縮短崩潰恢復時間！
oracle 如何縮短恢復時間？
1 ： 檢查點機制
2
：
心跳機制
oracle
爲什麼不適時的將
dbwr
寫進度反應到文件中？
適時反應成本太高！
3
秒種是一個合適的值，可以接受，代價不高又能大大縮短崩潰後恢復時間。
檢查點發生以後， CKPT 進程檢查 checkpoint queue( 也就是髒塊鏈表 ) 是否過長，如果是，則觸發 DBWn ，將一部分髒塊寫入數據文件，從而縮短 checkpoint queue 。
checkpoint 發生時，一方面通知 dbwr 進行下一批寫操作，（ dbwr 寫入的時候，一次寫的塊數是有一個批量寫的隱藏參數控制的。） 另一方面， oracle 採用了一個心跳的概念，以 3 秒的頻率將 dbwr 寫的進度反應到控制文件中，也就是把 dbwr 當前剛寫完的 dirty buffer 對應的 scn 寫入數據文件頭和控制文件，這就是檢查點 scn 。
這個 3 秒和增量檢查點不是一個概念， 3 秒只是在控制文件中， ckpt 進程去更新當前 dbwr 寫到哪裏了，這個對於 ckpt 進程來說叫 heartbeat ， heartbeat 是 3 秒一次， 3 秒可以看作不停的檢查並記錄檢查點執行情況（ DBWR 的寫進度） 。
檢查點發生之後數據庫的數據文件、控制文件處於一致狀態的含義 是不需要進行 介質恢復，只表示數據文件頭一致，但是並不表示數據文件內容一致 ，因爲數據文件內容可能在沒有發生檢查點的其他情況下的 dbwr 寫數據文件，這樣數據文件內容就不一致，若掉電需要進行崩潰恢復。
二、觸發的條件
這裏需要明白兩個概念 “ 完全檢查點和增量檢查點 ” 的區別。
增量檢查點（ incremental checkpoint ）
oracle8 之前，那時候沒有 chekpoint queue ，也沒有增量的概念， dirty buffer 的寫出是無順的，就是凍結所有 dml 等候所有 dirty buffer 被寫出。後來隨着數據庫規模的擴展和 buffer cache 的不斷增大， oracle 意識到這個機制已經滿足不了需要，所以提出增量檢查點的概念，建立了 checkpoint queue ，讓 dirty buffer header 根據首次變化時候的順序排列在 queue 裏面。 這樣 dbwr 只要順着 queue 的順序寫，而其他進程不必等候 dbwr 的寫操作完成 就可以繼續。
自從有了 checkpoint queue 之後 ，檢查點就成爲一個短暫的動作，就是通知 dbwr 你要繼續寫 dirty buffer 到 當前檢查點發生時候的 scn ，然後將當前 dbwr 剛寫完的 dirty buffer 對應的 scn ，寫進數據文件和控制文件【 增量檢查點時不寫數據文件頭 】 ( 比如日誌切換這種動作引起的檢查點動作等）。然後檢查點動作就結束了。 剩下的工作就交給 DBWn 了， 檢查點進程也不必等候 dbwr 的完成。
ckpt 進程通知 dbwr 之後並不需要等待 dbwr 寫到當前這個檢查點對應的時間點。所以 ckpt 可以將已經完成的最後一個檢查點 scn 寫到控制文件和數據文件（可能是上一個，也可能是上上個，總之 dbwr 完成了哪個算哪個）。 這樣本次需要寫進數據文件的 dirty buffer 可能在下一次檢查點發生的時候已經寫完了，這樣下一次檢查點發生的時候就把本次的檢查點 scn 更新到控制文件和數據文件。
在 oracle 8 之前，沒有 ckpt queue ，只有 LRU list ，而 LRU list 裏面的 Dirty Buffer 是不按時間順序排列的 ，所以 checkpoint 時都會做一個 full thread checkpoint ， 將 LRU list 中的所有 buffer 寫到數據文件。
在
oracle8i
以後，當發生
FULL CHECKPOINT
時
,oracle
只是獲取系統當前的
SCN,
然後將這個
SCN
之前的髒數據塊寫入磁盤
,
後續的
DML
髒數據塊繼續入隊
,
他並不是保證整個緩衝區沒有髒塊
,
只是保證
此
檢查點發生之前
這段距離間沒有髒塊
,
而在
checkpoint
點之後的
DML
可以正常操作。
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;
等命令都會觸發增量檢查點。
注意：
每隔三秒也會觸發檢查點，但是 並沒有被 oracle 正式作爲一種檢查點的觸發方式列入文檔 , 並且這個 3 秒是記錄 dbwr 進度而不是通知 dbwr 寫。
這是三秒觸發的檢查點與其它條件觸發檢查點不同的地方。
三：關於 low cache rba 與 on disk rba 的理解：
簡單說： low cache rba 就是 CKPT 記錄的 DBWR 寫的進度。
on disk rba 就是 LGWR 的寫進度。
如果數據庫 carsh ， low cache rba 是恢復的起點， on disk rba 是恢復的終點。
闡述一下： dbwr 成功寫完後並不把此刻 scn 信息寫到控制文件中，只有 CKPT 才更新控制文件和數據文件頭， dbwr 只要成功將 dirty data 寫入數據文件就是成功， CKPT 只要能將最新 DBWR 寫完的 SCN 更新到控制文件和數據文件頭就算成功。但是由於 CKPT 進程不是實時更新 dbwr 寫完的 scn 到控制文件中，而是採用每 3 妙更新一次的策略，因此最後有 ckpt 進程寫進控制文件的 scn 信息有可能不是當前 dbwr 剛剛寫完的 scn 值。這點應該注意，也就是說 dbwr 寫的進度與 ckpt 進程更新控制文件的進度是不同的。
關於檢查點的一點具體應用討論：
Commit 成功後，數據還會丟失嗎？
對於
Oracle
來說，用戶所做的
DML
操作一旦被提交，則先是在
database buffer cache
中進行修改，同時在修改之前會將數據的前鏡像保存在回滾段中，然後將修改之前和修改之後的數據都寫入到
redo log buffer
中，當接收到
commit
命令之後，則
redo log buffer
開始寫
redo log file
，並且記錄此時的
scn
，當
redo log file
寫完了之後，表示這次事務提交操作已經確認被數據庫記錄了，只有當
redo log file
寫成功了，纔會給用戶
Commit completed
的成功字樣。而對於
Database buffer cache
中的
dirty buffer
則會等待觸發
DBWn
才寫入，但是如果此時斷電，則數據已經被記錄到了
redo log file
中，系統在重新啓動的時候，會自動進行嵌滾和回滾來保證數據的一致。所以，只要是
commit
成功的了，數據不會丟失！
數據庫發生一次
DBWn
，是否將所有
buffer cache
中的
dirty buffer
都寫入，還是先將髒隊列中的數據寫入？
這話看起來有道理，但實際上， dbwr 在寫的時候又不斷地在產生 dirty buffer , 所以說檢查點發生的時候是期望把該時間點之前的所有髒緩衝區寫入數據文件。
所有的 buffer ，不在 LRU list 上就在 dirty list 上 , dbwr 寫入的時候，一次寫的塊數是有一個批量寫的隱藏參數控制的。
所以說要是 dbwr 將 dirty list 也好， lru list 上的也好，要實現全部寫入，都是一個現實系統中很難存在的現象。 dirty 總是在不斷的產生， dbwr 總是在不斷地寫 , 增量檢查點發生的時候也並不意味着一定要更新數據文件頭，檢查點開始的時候只表示該次檢查點結束的時候要更新數據文件頭的話數據文件頭具有該時間點的一致性 。
data block 裏面不是也有 SCN 嗎？和文件頭裏面的 SCN 有什麼關係？什麼時候被更新？代表的是是什麼含義？
data block 裏面的 SCN 是當 block 被更改的時候的 SCN
而數據文件有那麼多 block ，自然不同的 block 有不同的 SCN
block 中存在 block SCN 和 ITL 中的 commit SCN
block SCN 又在塊頭和塊位都有，若不一致意味着 block 損壞（熱碑可能出現這個情況，需要從 redo log 中拷貝回來，若是正在修改的過程中由於進程死掉則 pmon 負責清理。若 由於一些以外發生這樣的不一致的情況，則查詢的時候出現 1578 錯誤，當然該錯誤號也可能是 物理磁盤損壞，這裏表示邏輯的損壞！）
這個頭和尾的
SCN
的檢查時機跟這兩個參數有關：
db_block_checking boolean FALSE
db_block_checksum boolean FALSE
該
2
參數信息請查閱
http://tahiti.oracle.com
而 ITL 中的 commit SCN 則跟 consistent gets and delay block cleanout 有關
數據文件頭的 SCN 是檢查點發生時更新的 ，代表着 當 恢復的時候從這個 SCN 點 開始在 log file 中尋找 redo 開始做恢復。
看下面的操作！
___________________________________________________________
sys @ DBAP01 > select max ( ktuxescnw * power ( 2 , 32 )+ ktuxescnb ) from x$ktuxe ;
MAX
(
KTUXESCNW
*
POWER
(
2
,
32
)+
KTUX
------------------------------
52211024
已用時間
:
00
:
00
:
00.00
sys
@
DBAP01
>
alter system checkpoint
;
系統已更改。
已用時間
:
00
:
00
:
00.06
sys
@
DBAP01
>
select CHECKPOINT_CHANGE
# from v$database;
CHECKPOINT_CHANGE
#
------------------
52211055
已用時間
:
00
:
00
:
00.00
sys
@
DBAP01
>
select max
(
ktuxescnw
*
power
(
2
,
32
)+
ktuxescnb
)
from x$ktuxe
;
MAX
(
KTUXESCNW
*
POWER
(
2
,
32
)+
KTUX
------------------------------
52211053
已用時間
:
00
:
00
:
00.00
sys
@
DBAP01
>
怎麼解釋這個現象？
解答： x$ktuxe 計算出來的是已經結束的最新的事務的 commit scn ，所以可小於當前系統 scn 。 檢查點 scn 自然也小於當前系統 scn 。 但是 檢查點 scn 和 x$ktuxe 計算出來的大小卻倚賴於 系統狀況了。
current scn 是 系統當前所產生的最大 scn ，可能是當前未結束事務所產生的 scn 。 在 9i 的 dbms_flashback.get_system_number 可以得到這個值，這個值應該是大於等於 x$ktuxe SCN ( 這個 view 記錄的是 當前數據庫結束事務的最大 scn)
關於 SCN 的一些理解：
在控制文件 , 數據文件頭 , 數據塊 , 日誌文件頭 , 日誌文件 change vector 中都有 SCN, 但其作用各不相同。
數據文件頭中包含了該數據文件的 checkpoint SCN, 表示給數據文件最近一次執行檢查點操作時的 SCN.
日誌文件頭中包含了 low scn,next scn, 表示給日誌文件包含有從 low scn 到 next scn 的 redo record.
控制文件中包含了每個數據文件的 checkpoint SCN,stop SCN, 每個日誌文件的 low scn,next scn 。控制文件中 checkpoint scn 同數據文件頭中 checkpoint scn 相同 , 除非數據文件被手工替換掉 . 控制文件中的 low scn,next scn 同日志文件中 low scn 和 next scn 相同。
在數據庫正常運行時 , 控制文件中對應數據文件的 stop SCN 都是最大值 .
在正常關閉數據庫的情況下 , 在關閉前會執行一次檢查點工作當 oracle 會將數據緩衝區上的內容全部寫回到磁盤中 , 然後更新控制文件中對應數據文件的 stop SCN, 使其等於 checkpoint SCN 。
但在異常當機的情況下 , 由於最後一次檢查點未進行或進行中間被中止 , 因而在控制文件 , 就存在部分的數據文件 stop SCN 爲最大值。
在數據庫重新啓動後 , 會檢查控制文件中對應每個數據文件的 stop SCN, 如果 stop SCN 不等於控制文件中對應每個數據文件的 checkpoint SCN, 就會使用日誌文件 redo 從 checkpoint SCN 開頭到 stop SCN 爲止的全部數據庫操作 .
在定位到底使用哪個日誌文件的時候，並不是用數據文件中的 low scn 去框，也不是 只要在日誌文件的 low scn and next scn 之間就利用該日誌文件。而是在數據文件頭中有 RBA 的記錄， RBA 包含了日誌序號、 block number 、 slot number 。 這樣可以直接定位到日誌文件（歸檔日誌文件）和具體的位置 。
在確定了哪個數據文件須 redo 後 ,oracle 會比較 change vector （向量）中的 SCN 和數據文件數據塊中的 SCN, 如果 change vector 的 SCN 小於數據塊的 scn, 則跳過此 change vector, 否則 redo 數據塊中 ITL 中還有 SCN, 但它的作用是用於產生一致性讀快照。
commit
的時候加一，其他很多時候也會加
1
，只要數據庫發生了變化都會增加。
很多時候，能否舉一些例子
dml 一發生即使沒有提交也會增加 scn, job 進程一樣產生 scn, 只要對數據庫中文件發生任何的改變都有可能產生 scn,SCN: system change number, not system commit number . 也就是 系統發生變化 所產生的一個時間點標誌。不是提交的標誌，只是因爲提交也是系統的變化之一而已。
這句話我應該更準確第表達一下：
如果一個
dml
導致產生事務，則會產生一個
scn
。這個意思是說
如果一個事務包含多個
dml
，則只有第一個初始產生事務的
dml
產生
scn
，提交的時候又是一個
scn
。
如果一個事務只有一個
dml
，那麼看起來就是
dml
產生一個
scn
，提交或者回滾產生一個
scn
。
所以可以把結論定義爲 事務的開始 和事務的結束都會導致 SCN 的增加，同一個 block 上在一個事務中連續發生 255 個 DML 後 scn 也會增加。
檢查點的發生和日誌的關係：
解答：
檢查點的發生，跟寫日誌文件是沒有必然聯繫的。
檢查點發生，通知
DBWR
寫數據文件，寫完後
ckpt
更新控制文件和數據文件頭。
當 DBWR 寫 數據塊的時候若發現 數據塊的 相關 RDBA ( 位於日誌文件的位置 ) 的 log block 還沒有被寫入日誌文件，則在 dbwr 寫塊之前必須通知 lgwr 把 log buffer 中日誌寫入日誌文件。
關於檢查點等待事件：
有些事件的產生必須等待檢查點的完成，才能開始數據庫的其它操作：
日誌文件切換就是其中一個事件， 日誌切換必須等待檢查點完成 。
log file switch (checkpoint incomplete) 這個等待事件本身也說明，日誌切換時產生的檢查點是需要等待的，這個日誌文件所對應髒塊全部寫完後，檢查點進程更新控制文件和數據頭，然後這個檢查點才能算完成。
也就是說 日誌切換必須等待檢查點完成，而檢查點在等待 DBWn 完成。
這種等待 DBWn 完成的檢查點，最後一步寫入控制文件和數據文件頭的 SCN ，肯定是 DBWn 完成的最後一塊的 SCN 。
檢查點爲什麼要等待 dbwr 完成後才進行切換（ log switch ）？
log switch 時，是不能立即 switch 到 active 狀態的日誌文件的，此時切換進程必須等待。 active 表示該 log group 還沒有完成歸檔（歸檔模式下）或者該 log group 有進行 instance recovery 需要用到的日誌 。所以當 checkpoint 發生時，如果 dbwr 還沒有寫完它該寫完的 dirty buffers （該 checkpoint 時間點以前產生的 dirty buffers, 靠 scn 判斷），則該 log group 處於 active 狀態，不會進行日誌切換，當然也不會發生日誌文件被覆蓋的問題了。
如果沒有設置 archive log ，在檢查點發生後，發生 log switch 一個輪迴， log file 是否會被覆蓋掉？
當檢查點發生後，會觸發 lgwr ， lgwr 會把此時 SCN 以前在 redo buffer 中的所有操作寫到 redo log file ，同時 lgwr 也會觸發 dbwr 進程， dbwr 也開始把此刻以前 database buffer 中的 dirty buffer 隊列中的操作寫入 data file 。
其實檢查點發生後，就是 lgwr 和 dbwr 寫 buffer 到磁盤文件的過程，但是兩者的讀寫速度時不同的， dbwr 寫 buffer 到數據文件的過程相對較慢，因爲 dbwr 寫過程是一個隨機讀取存儲的過程。 Lgwr 寫 buffer 到 redo 文件的過程比 dbwr 要快很多，因爲 lgwr 是順序讀取寫入的。
由於以上 lgwr 和 dbwr 寫操作的速度不同，就產生了一個等待問題。即當 lgwr
輪循一圈後，要進行日誌切換，覆蓋 redo log file ，但是此時 dbwr 還沒有寫完，那麼 lgwr 就會出現等待， oracle 也會 hang 在那裏，同時 alter 文件中會提示一個相應的提示 checkpoint not complete 。等檢查點完成後數據庫自動恢復正常。
當 log switch 時，會觸發檢查點 ，標記檢查點時， DBWR 要把 log file 中 covered by the log being checkpointed 的數據寫入到數據文件上，如果 Dbwr 沒有寫完，那麼前一個 logfile 是不能被覆蓋的。因此 必須等檢查點完畢，也可以說是將 要被覆蓋的日誌相關的數據塊全部寫入數據文件後，該日誌文件才能被覆蓋！
如果這種情況出現， alert 文件中會記錄 checkpoint not complete 事件，這通常表明你的 dbwr 寫入過慢或者 logfile 組數過少或 log file 太小。
檢查點發生時，出現日誌切換，但是 dbwr 還沒有寫完，是否會覆蓋 redo log file ，如果此時掉電， dbwr 掛起，會出現丟失數據嗎？
答：不會覆蓋 redo 文件，要等待 dbwr 寫完才覆蓋。或者說要等待檢查點完成才覆蓋。
如果
DBWn
正在寫的髒塊是指對應到即將被覆蓋的那個日誌文件的，那麼，因爲在這些操作完成之前，不可能有覆蓋這件事發生，假設你預料的掉電發生了，不會有什麼問題，實例恢復時的前滾從剛纔準備覆蓋的那個日誌文件開始。
如果正在寫的髒塊是指對應到剛剛被寫滿的那個日誌文件的，肯定一時半會也寫不完，日誌切換也不會等它，如果切換成功後 dbwr 掛了，後面的寫髒塊操作估計也還沒完成，但是，剛寫滿的那個文件並沒有被覆蓋，也不會有任何問題。
因此不會出現數據丟失！
當一個很大的 dml 發生時，用戶在 commit 後，需要將 redo log buffer 中的髒數據寫入 redo log file 中。如果在寫的過程中，發現一個 redo log file 寫不下的話，需要寫另外一個 redo log file ，這時應該觸發 checkpoint ，接着觸發 DBWn ，將髒數據寫入 datafile ，這時發生掉電，導致 DBWR 失敗。這時其實就可以說 commit 失敗了。以上所述其實就是 commit 沒有提交成功。
alter systen switch logfile 會觸發完全檢查點 ; 但是爲什麼，日誌切換以後檢查點只能記錄到上一次歸檔日誌產生的時間呢？而不是現在歸檔日誌產生的時間呢？
因爲這時的 checkpoint enqueue 隊列中，也就是髒塊隊列中髒塊還不夠多，還不足以觸發 DBWn 寫髒塊。所以，內存裏需要寫入的髒塊所對應的 redo 還存在於上一個 redo log 裏，這時你去看該 redo log 的 status 爲 active 。
下面操作日誌中出現當前 redo log 的 status 爲 current ，而上一個 redo log 的 status 爲 active 就說明了這一切。上一個 redo log 的 status 爲 active 正是說明在 上一個 redo log 中 還存在未寫入 datafile 的 block 所對應的 redo 。
SQL> create table gaojf8 as select * from all_objects;
Table created
SQL> insert into gaojf3 select * from gaojf3;
29630 rows inserted
SQL> /
59260 rows inserted
SQL> commit;
Commit complete
SQL> select * from x$kccrt;
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
-------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ------------- ------------- ------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------------- -------------------- ---------- ---------------- --------------------
421A 54D0 0 1 1 15 8796119126928 08/08/2006 00:28:38 1 14 2 16 0200000000000000 0 0 3 1 3 1 14 8796117861680 08/02/2006 02:29:36 0 13 cicro 08/02/2006 02:33:50
SQL> alter system switch logfile;
System altered
SQL> select * from x$kccrt;
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
-------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ------------- ------------- ------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------------- -------------------- ---------- ---------------- --------------------
421A 54D0 0 1 1 15 8796119126928 08/08/2006 00:28:38 1 14 2 16 0200000000000000 0 0 3 1 3 2 15 8796117861680 08/02/2006 02:29:36 0 14 cicro 08/02/2006 02:33:50
SQL> select * from x$kccrt;
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
-------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ------------- ------------- ------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------------- -------------------- ---------- ---------------- --------------------
421A 54D0 0 1 1 15 8796119126928 08/08/2006 00:28:38 1 14 2 16 0200000000000000 0 0 3 1 3 2 15 8796117861680 08/02/2006 02:29:36 0 14 cicro 08/02/2006 02:33:50
SQL> select * from x$kccrt;
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
-------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ------------- ------------- ------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------------- -------------------- ---------- ---------------- --------------------
421A 54D0 0 1 1 15 8796119128114 08/08/2006 00:35:51 1 15 2 16 0200000000000000 0 0 3 1 3 3 16 8796117861680 08/02/2006 02:29:36 0 15 cicro 08/02/2006 02:33:50
從上面試驗中可以看到，完全檢查點正在執行，還沒有執行完畢。因此，切換日誌前後察看
x$kccrt
，看到的
RTCKP_SCN, RTCKP_TIM
沒有發生變化。等檢查點執行完畢後（也就是檢查點觸發的
dbwr
執行完寫操作後）
，
rtckp_scn, rtckp_tim
才發生變化。
