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
SQL> select * from X$KCCCP where indx=0;ADDR INDX INST_ID CPTNO CPSTA CPFLG CPDRT CPRDBCPLRBA_SEQ CPLRBA_BNO CPLRBA_BOF CPODR_SEQ CPODR_BNO CPODR_BOF CPODSCPODT CPODT_I CPHBT CPRLS CPRLC CPMIDCPSDR_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等信息。
每隔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 了。