checkpoint详解（部分转）
checkpoint是什么？
checkpoint是数据库的一个内部事件，
这个事件激活以后会触发数据库写进程(DBWR)将数据缓冲(DATA BUFFER CACHE)中的脏数据块写出到数据文件中。
checkpoint的作用是什么？
checkpoint主要2个作用：
1、保证数据库的一致性，
这是指将脏数据写出到硬盘，保证内存和硬盘上的数据是一样的；
2、缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。
如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。
checkpoint就像word的自动保存一样。
checkpoint的类型：
完全检查点：
定义：清除脏列表(DIRTY LIST OR CHECKPOINT ENQUEUE)中所有数据块。
什么时候发生：ALTER SYSTEM CHECKPOINT; SHUTDOWN;
增量检查点:
定义：根据检查点的条件清除脏列表中的部分数据块，直到满足所有检查点条件为止。
什么时候发生：CKPT进程每3秒被唤醒，CKPT检查当前的所有checkpoint条件，
如果任何一个条件不能被满足，那么CKPT发出增量检查点。
检查点条件有哪些？
90％ OF THE SMALLEST REDO LOGFILEITPUB
FAST_START_MTTR_TARGET
FAST_START_IO_TARGET
LOG_CHECKPOINT_TIMEOUT
LOG_CHECKPOINT_INTERVAL
90％ OF THE SMALLEST REDO LOGFILE :
意味着最后一次增量检查点与当前日志文件末尾所差的redo block数量如果超过最小redo log的90％，那么就会触发增量检查点。
FAST_START_MTTR_TARGET：实例恢复的时间限制，
将这个时间换算成redo blocks数量，当log buffer中未写入log file的redo block数量超过这个值，就会触发增量检查点。
FAST_START_IO_TARGET：实例恢复所需要读取的redo blocks数量，
当log buffer中未写入log file的redo block数量超过这个值，就会触发增量检查点。
LOG_CHECKPOINT_TIMEOUT：2次增量检查点的时间间隔。
LOG_CHECKPOINT_INTERVAL：最后一次增量检查点与当前日志文件末尾所差的redo block数量。
注意：增量检查点并不是将脏列表中的所有脏块都写出到数据文件中，而是写出一部分，保证满足所有条件即可。
相关概念：
RBA checkpoin rba on-disk rba RBA:redo block address 重作日志地址
logfile sequence number(4bytes)
logfile block number(4bytes)
redo entry offset(2bytes)
checkpoint rba：最后一次检查点对应的重作日志地址，意味着这个地址之前的redo log都是实例恢复不需要的。
实例恢复的起点
on-disk rba：当前日志中最新的重作日志地址。
实例恢复的终点
相关视图：x$kcccp v$instance_recovery v$instance_recovery实例恢复对应的视图:
actual_redo_blks:最后一次检查点到当前日志尾所差的redo blocks数量；
target_redo_blks:所有检查点条件中最小的条件相差的redo blocks数量；
log_file_size_redo_blks:最小日志组的90％大小所对应的redo blocks数量；--这是一个增量检查点条件
log_chkpt_timeout_redo_blks:有log_checkpoint_timeout参数所转换的redo blocks数量； --这也是一个增量检查点条件
target_mttr:有fast_start_mttr_target参数所限制的实例恢复的最大时间
estimated_mttr:根据当前最后一次检查点与日志尾所差的redo blocks数量估算出来的mttr。
x$kcccp 增量检查点对应的视图：
CPLRBA_SEQ：最后一次增量检查点对应rba的第一部分--日志序列号；
CPLRBA_BNO：最后一次增量检查点对应rba的第二部分--日志块数；
CPLRBA_BOF：最后一次增量检查点对应rba的第三部分--日志偏移量；
CPODR_SEQ：日志尾的rda的第一部分--日志序列号；
CPODR_BNO：日志尾的rda的第二部分--日志块数；
CPODR_BOF：日志尾的rda的第二部分--日志偏移量；
CPHBT：检查点心跳数。
实验测试：
1、完全检查点：
SQL> show parameter log_checkpoint_
NAME TYPE VALUE
------------------------------------ ----------- ---------------------
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean FALSE
SQL> alter system set log_checkpoints_to_alert=true scope=both;
系统已更改。
SQL> show parameter log_check
NAME TYPE VALUE
------------------------------------ ----------- ------------------
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean TRUE
SQL> alter system checkpoint;
系统已更改。
日志中的信息：完全检查点立即执行。
Beginning global checkpoint up to RBA [0x6b.861.10], SCN: 5529715
Completed checkpoint up to RBA [0x6b.861.10], SCN: 5529715
从v$instance_recovery 中看到actual_redo_blks瞬间为0，说明完全检查点清除脏列表上的所有的脏块。
同时也会完成之前没有完成的日志切换检查点，这时查询v$log，active的状态转变为inactive。
第1个窗口
SQL> alter system checkpoint;
系统已更改。
第2个窗口
SQL> select actual_redo_blks from v$instance_recovery;
ACTUAL_REDO_BLKS
----------------
43
SQL> select actual_redo_blks from v$instance_recovery;
ACTUAL_REDO_BLKS
----------------
43
当第一个窗口执行完全检查点后
SQL> select actual_redo_blks from v$instance_recovery;
ACTUAL_REDO_BLKS
----------------
0
此时查看警报日志：
Beginning global checkpoint up to RBA [0x6b.892.10], SCN: 5529786
Completed checkpoint up to RBA [0x6b.892.10], SCN: 5529786
RBA十六进制6b转成十进制就是107，是当前的在线日志序列号：
SQL> select group#,sequence#,status from v$Log;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 105 INACTIVE
2 106 INACTIVE
3 107 CURRENT
4 104 INACTIVE
SQL> select group#,member from v$logfile where group#=3;
GROUP#
----------
MEMBER
-----------------------------------------------------------
3
D:\ORACLE\PRODUCT\10.2.0\ORADATA\WEIBIN\REDO03.LOG
SQL> alter system dump logfile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\WEIBIN\REDO03.LOG';
系统已更改。
找出对应的转储日志，位置在user_dump_dest指定的目录下面
SQL> show parameter user_dump_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
user_dump_dest string D:\ORACLE\PRODUCT\10.2.0\ADMIN
\WEIBIN\UDUMP
SQL> select spid from v$process where addr = (
2 select paddr from v$session where sid = (select distinct sid from v$mystat));
SPID
------------
2220
在D:\ORACLE\PRODUCT\10.2.0\ADMIN\WEIBIN\UDUMP目录下对应转储日志名为：weibin_ora_2220.trc
找到对应的rba
REDO RECORD - Thread:1 RBA: 0x00006b.00000892.0010 LEN: 0x0090 VLD: 0x06
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 1 rdba: 0x0040067a BFT:(1024,4195962) non-BFT:(1,1658)
scn: 0x0000.005460af seq: 0x02 flg:0x06
Block Written - afn: 2 rdba: 0x00800019 BFT:(1024,8388633) non-BFT:(2,25)
scn: 0x0000.005460ab seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800029 BFT:(1024,8388649) non-BFT:(2,41)
scn: 0x0000.005460ad seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006b.00000892.00a0 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800039 BFT:(1024,8388665) non-BFT:(2,57)
scn: 0x0000.00546078 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800047 BFT:(1024,8388679) non-BFT:(2,71)
scn: 0x0000.005460a3 seq: 0x07 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006b.00000892.00f4 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800049 BFT:(1024,8388681) non-BFT:(2,73)
scn: 0x0000.005460af seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800059 BFT:(1024,8388697) non-BFT:(2,89)
scn: 0x0000.005460a2 seq: 0x01 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006b.00000892.0148 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800069 BFT:(1024,8388713) non-BFT:(2,105)
scn: 0x0000.0054608f seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800079 BFT:(1024,8388729) non-BFT:(2,121)
scn: 0x0000.00546093 seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006b.00000892.019c LEN: 0x0054 VLD: 0x02
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800089 BFT:(1024,8388745) non-BFT:(2,137)
scn: 0x0000.005460a4 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800139 BFT:(1024,8388921) non-BFT:(2,313)
scn: 0x0000.00546093 seq: 0x03 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006b.00000893.0010 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x008003dc BFT:(1024,8389596) non-BFT:(2,988)
scn: 0x0000.005460ab seq: 0x01 flg:0x04
Block Written - afn: 3 rdba: 0x00c00a65 BFT:(1024,12585573) non-BFT:(3,2661)
scn: 0x0000.005460a4 seq: 0x01 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006b.00000893.0064 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c00a6c BFT:(1024,12585580) non-BFT:(3,2668)
scn: 0x0000.005460a4 seq: 0x01 flg:0x06
Block Written - afn: 3 rdba: 0x00c0697f BFT:(1024,12609919) non-BFT:(3,27007)
scn: 0x0000.005460ad seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006b.00000893.00b8 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.005460ba SUBSCN: 1 06/29/2011 11:17:11
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c079f0 BFT:(1024,12614128) non-BFT:(3,31216)
scn: 0x0000.005460ad seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c07ed4 BFT:(1024,12615380) non-BFT:(3,32468)
scn: 0x0000.005460a4 seq: 0x01 flg:0x06
注意以上红色部分，这条redo record的SCN: 0x0000.005460ba，5460ba转换成十进制为5529786和检查点scn是一致的。
SQL> select file#, checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 5556107
2 5556107
3 5556107
4 5556107
5 5556107
6 5556107
7 5556107
8 5556107
9 5556107
10 5556107
11 5556107
已选择11行。
SQL> select to_char(5556107,'xxxxxxx') from dual;
TO_CHAR(
--------
54c78b
SQL> select count(*) from v$bh where dirty='Y';
COUNT(*)
----------
57
SQL> alter system checkpoint
2 ;
系统已更改。
SQL> select count(*) from v$bh where dirty='Y';
COUNT(*)
----------
0
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 5556412
2 5556412
3 5556412
4 5556412
5 5556412
6 5556412
7 5556412
8 5556412
9 5556412
10 5556412
11 5556412
已选择11行。
SQL> select to_char(5556412,'xxxxxxx') from dual;
TO_CHAR(
--------
54c8bc
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 INACTIVE
3 INACTIVE
4 CURRENT
SQL> select group#,member from v$logfile where group#=4;
GROUP#
----------
MEMBER
-----------------------------------------------------------------------
4
D:\ORACLE\PRODUCT\10.2.0\ORADATA\WEIBIN\REDO04.LOG
SQL> alter system dump logfile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\WEIBIN\REDO04.LOG';
系统已更改。
找到54c8bc的redo record：正好是57个脏块
REDO RECORD - Thread:1 RBA: 0x00006c.000021ef.0010 LEN: 0x00d0 VLD: 0x06
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 6 rdba: 0x01801b70 BFT:(1024,25172848) non-BFT:(6,7024)
scn: 0x0000.0054c8a7 seq: 0x04 flg:0x04
Block Written - afn: 7 rdba: 0x01c00261 BFT:(1024,29360737) non-BFT:(7,609)
scn: 0x0000.0054c897 seq: 0x03 flg:0x06
Block Written - afn: 7 rdba: 0x01c00262 BFT:(1024,29360738) non-BFT:(7,610)
scn: 0x0000.0054c874 seq: 0x02 flg:0x06
Block Written - afn: 7 rdba: 0x01c00264 BFT:(1024,29360740) non-BFT:(7,612)
scn: 0x0000.0054c89b seq: 0x02 flg:0x06
Block Written - afn: 7 rdba: 0x01c00265 BFT:(1024,29360741) non-BFT:(7,613)
scn: 0x0000.0054c893 seq: 0x02 flg:0x06
Block Written - afn: 7 rdba: 0x01c00266 BFT:(1024,29360742) non-BFT:(7,614)
scn: 0x0000.0054c874 seq: 0x02 flg:0x06
Block Written - afn: 7 rdba: 0x01c00267 BFT:(1024,29360743) non-BFT:(7,615)
scn: 0x0000.0054c874 seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021ef.00e0 LEN: 0x0064 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 7 rdba: 0x01c00525 BFT:(1024,29361445) non-BFT:(7,1317)
scn: 0x0000.0054c893 seq: 0x02 flg:0x06
Block Written - afn: 6 rdba: 0x018000b2 BFT:(1024,25166002) non-BFT:(6,178)
scn: 0x0000.0054c89d seq: 0x02 flg:0x04
Block Written - afn: 6 rdba: 0x01800115 BFT:(1024,25166101) non-BFT:(6,277)
scn: 0x0000.0054c899 seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021ef.0144 LEN: 0x0064 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 6 rdba: 0x018006a6 BFT:(1024,25167526) non-BFT:(6,1702)
scn: 0x0000.0054c893 seq: 0x09 flg:0x04
Block Written - afn: 6 rdba: 0x018006b4 BFT:(1024,25167540) non-BFT:(6,1716)
scn: 0x0000.0054c857 seq: 0x01 flg:0x04
Block Written - afn: 6 rdba: 0x018006b6 BFT:(1024,25167542) non-BFT:(6,1718)
scn: 0x0000.0054c8a9 seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021ef.01a8 LEN: 0x0064 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800009 BFT:(1024,8388617) non-BFT:(2,9)
scn: 0x0000.0054c8ab seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800019 BFT:(1024,8388633) non-BFT:(2,25)
scn: 0x0000.0054c8af seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800029 BFT:(1024,8388649) non-BFT:(2,41)
scn: 0x0000.0054c870 seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f0.001c LEN: 0x0064 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800039 BFT:(1024,8388665) non-BFT:(2,57)
scn: 0x0000.0054c8a7 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800049 BFT:(1024,8388681) non-BFT:(2,73)
scn: 0x0000.0054c8ad seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800059 BFT:(1024,8388697) non-BFT:(2,89)
scn: 0x0000.0054c89d seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f0.0080 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800069 BFT:(1024,8388713) non-BFT:(2,105)
scn: 0x0000.0054c8a9 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800079 BFT:(1024,8388729) non-BFT:(2,121)
scn: 0x0000.0054c8a5 seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f0.00d4 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800089 BFT:(1024,8388745) non-BFT:(2,137)
scn: 0x0000.0054c899 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800099 BFT:(1024,8388761) non-BFT:(2,153)
scn: 0x0000.0054c8b1 seq: 0x02 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f0.0128 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800148 BFT:(1024,8388936) non-BFT:(2,328)
scn: 0x0000.0054c8a5 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800247 BFT:(1024,8389191) non-BFT:(2,583)
scn: 0x0000.0054c8b1 seq: 0x03 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f0.017c LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x008002d9 BFT:(1024,8389337) non-BFT:(2,729)
scn: 0x0000.0054c8ab seq: 0x04 flg:0x04
Block Written - afn: 2 rdba: 0x0080031f BFT:(1024,8389407) non-BFT:(2,799)
scn: 0x0000.0054c874 seq: 0x08 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f0.01d0 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x00800321 BFT:(1024,8389409) non-BFT:(2,801)
scn: 0x0000.0054c8ad seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x008003ee BFT:(1024,8389614) non-BFT:(2,1006)
scn: 0x0000.0054c8a3 seq: 0x03 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f1.0034 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 2 rdba: 0x008003f0 BFT:(1024,8389616) non-BFT:(2,1008)
scn: 0x0000.0054c8af seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800592 BFT:(1024,8390034) non-BFT:(2,1426)
scn: 0x0000.0054c870 seq: 0x01 flg:0x04
REDO RECORD - Thread:1 RBA: 0x00006c.000021f1.0088 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c01315 BFT:(1024,12587797) non-BFT:(3,4885)
scn: 0x0000.0054c893 seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c05ca0 BFT:(1024,12606624) non-BFT:(3,23712)
scn: 0x0000.0054c893 seq: 0x03 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f1.00dc LEN: 0x0074 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c05ccd BFT:(1024,12606669) non-BFT:(3,23757)
scn: 0x0000.0054c8a7 seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c05cce BFT:(1024,12606670) non-BFT:(3,23758)
scn: 0x0000.0054c8a3 seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c05ccf BFT:(1024,12606671) non-BFT:(3,23759)
scn: 0x0000.0054c89b seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c05cd5 BFT:(1024,12606677) non-BFT:(3,23765)
scn: 0x0000.0054c874 seq: 0x06 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f1.0150 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c05cd7 BFT:(1024,12606679) non-BFT:(3,23767)
scn: 0x0000.0054c89f seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f1.0194 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c05cdf BFT:(1024,12606687) non-BFT:(3,23775)
scn: 0x0000.0054c8ab seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f1.01d8 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c05f00 BFT:(1024,12607232) non-BFT:(3,24320)
scn: 0x0000.0054c8ab seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f2.002c LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c05f18 BFT:(1024,12607256) non-BFT:(3,24344)
scn: 0x0000.0054c8ab seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f2.0070 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c06fb0 BFT:(1024,12611504) non-BFT:(3,28592)
scn: 0x0000.0054c8a9 seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f2.00b4 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c07442 BFT:(1024,12612674) non-BFT:(3,29762)
scn: 0x0000.0054c8af seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f2.00f8 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c079c4 BFT:(1024,12614084) non-BFT:(3,31172)
scn: 0x0000.0054c893 seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f2.013c LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c079c7 BFT:(1024,12614087) non-BFT:(3,31175)
scn: 0x0000.0054c89f seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f2.0180 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c079ea BFT:(1024,12614122) non-BFT:(3,31210)
scn: 0x0000.0054c8af seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f2.01c4 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c079ec BFT:(1024,12614124) non-BFT:(3,31212)
scn: 0x0000.0054c8ad seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f3.0018 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c07a54 BFT:(1024,12614228) non-BFT:(3,31316)
scn: 0x0000.0054c8ab seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f3.005c LEN: 0x0074 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c07eca BFT:(1024,12615370) non-BFT:(3,32458)
scn: 0x0000.0054c874 seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c07ecb BFT:(1024,12615371) non-BFT:(3,32459)
scn: 0x0000.0054c893 seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c07ecc BFT:(1024,12615372) non-BFT:(3,32460)
scn: 0x0000.0054c893 seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c07ecd BFT:(1024,12615373) non-BFT:(3,32461)
scn: 0x0000.0054c89f seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f3.00d0 LEN: 0x0054 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c07ecf BFT:(1024,12615375) non-BFT:(3,32463)
scn: 0x0000.0054c897 seq: 0x02 flg:0x06
Block Written - afn: 3 rdba: 0x00c07ed0 BFT:(1024,12615376) non-BFT:(3,32464)
scn: 0x0000.0054c897 seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f3.0124 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 3 rdba: 0x00c07f71 BFT:(1024,12615537) non-BFT:(3,32625)
scn: 0x0000.0054c89f seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f3.0168 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 1 rdba: 0x0040067a BFT:(1024,4195962) non-BFT:(1,1658)
scn: 0x0000.0054c8b1 seq: 0x02 flg:0x06
REDO RECORD - Thread:1 RBA: 0x00006c.000021f3.01ac LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0054c8bc SUBSCN: 1 06/29/2011 14:18:20
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 1 rdba: 0x0040068a BFT:(1024,4195978) non-BFT:(1,1674)
scn: 0x0000.0054c8b1 seq: 0x03 flg:0x06
总结一下：完全检查点会清空buffer cache中所有脏块(有些特殊块不包含在内)，
当alter system checkpoint 命令发出，完全检查点会立刻执行。
如果是在生产库，由于脏块数量比较多，完全检查点的时间会很长，并占用一定的系统资源，这时操作系统的IO会变忙。
2、增量检查点：设置增量检查点的意义是通过提高检查点发生的次数，将脏块不断的，一点一点的写出到数据文件，
这样可以避免由于完全检查点引起的高IO负载。
a、第一个发生增量检查点的条件：90％ OF THE SMALLEST REDO LOGFILE
一般很少有人更改log_checkpoint和fast_start参数，那些参数的默认值都设置的很大，
所以还没到那些参数的阀值的时候，90％最小日志的条件就生效了（增量检查点是任何一个条件成立以后就会发生）。
实验一把：
SQL> show parameter log_checkpoint
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean TRUE
SQL> show parameter fast_start
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_io_target integer 0
fast_start_mttr_target integer 0
fast_start_parallel_rollback string HIGH
SQL> create table test as select * from dba_objects;
Table created.
ps：增量检查点的触发条件的当前值都可以在v$instance_recovery中看到，而x$kcccp可以看到最后一次检查点的位置(用rba表示)和当前日志尾的位置(用rba表示)。
看看当前各个增量检查点触发条件的值：
SQL> select actual_redo_blks act,target_redo_blks target,LOG_FILE_SIZE_REDO_BLKS logfile,LOG_CHKPT_TIMEOUT_REDO_BLKS log_check,target_mttr tmttr,estimated_mttr es_mttr from v$instance_recovery;
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
62967 170577 184320 170577 0 14
--LOG_FILE_SIZE_REDO_BLKS的值是184320，这正好是日志文件的90％
--日志块是0.5K一个，换算成M，184320*0.5/1024＝90 日志文件是100M
--再看一下最后一次检查点的位置：
SQL> select CPLRBA_SEQ,CPLRBA_BNO,CPODR_SEQ,CPODR_BNO from x$kcccp;
CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------
47 107610 47 170607
--最后一次检查点发生在47号日志的17610块,当前日志也是47号，日志尾在170607块。
--这时从另一个窗口不断的执行 insert into test as select * from test where rownum < 100000;
--同时不断查询v$instance_recovery，可以看到新产生大量的日志块:
SQL> select actual_redo_blks act,target_redo_blks target,LOG_FILE_SIZE_REDO_BLKS logfile,LOG_CHKPT_TIMEOUT_REDO_BLKS log_check,target_mttr tmttr,estimated_mttr es_mttr from v$instance_recovery;
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
63008 170612 184320 170612 0 14
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
82829 184320 184320 190439 0 14
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
103118 184320 184320 210728 0 14
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
103197 184320 184320 210807 0 20
--此时redo log也发生了切换：
SQL> select * from v$Log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 47 104857600 3 NO ACTIVE 1210034 11-DEC-06
2 1 48 104857600 3 NO CURRENT 1213051 11-DEC-06
3 1 46 104857600 3 YES INACTIVE 1209429 11-DEC-06
--这里注意：当当前日志被写满以后，进行日志切换，这时触发了一个log switch checkpoint，但是仅仅是触发，而并没有完成。
--后台警报日志:
Mon Dec 11 15:06:26 2006
Beginning log switch checkpoint up to RBA [0x30.2.10], SCN: 0x0000.0012827b
Thread 1 advanced to log sequence 48
Current log# 2 seq# 48 mem# 0: /u01/app/oracle/oradata/novo/redo02.log
--另外注意，47号日志的状态是ACTIVE，active的意思是这个日志组还包含实例恢复所需要的日志。这也说明log switch checkpoint并没有立即工作
--这时看看最后一次检查点的位置：
SQL> select CPLRBA_SEQ,CPLRBA_BNO,CPODR_SEQ,CPODR_BNO from x$kcccp;
CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------
47 107610 48 6161
--最后一次检查点的位置没变，还在47号日志上面，而当前日志尾已经到了48号的6161块上。这也印证了为什么44号日志的状态是ACTIVE的。
--再看看当前是否满足增量检查点的触发条件：
SQL> select actual_redo_blks act,target_redo_blks target,LOG_FILE_SIZE_REDO_BLKS logfile,LOG_CHKPT_TIMEOUT_REDO_BLKS log_check,target_mttr tmttr,estimated_mttr es_mttr from v$instance_recovery;
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
103361 184320 184320 210971 0 20
--没有满足，那么继续insert
--不断观察v$instance_recovery：
SQL> select actual_redo_blks act,target_redo_blks target,LOG_FILE_SIZE_REDO_BLKS logfile,LOG_CHKPT_TIMEOUT_REDO_BLKS log_check,target_mttr tmttr,estimated_mttr es_mttr from v$instance_recovery;
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
63008 170612 184320 170612 0 14
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
82829 184320 184320 190439 0 14
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
103118 184320 184320 210728 0 14
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
103197 184320 184320 210807 0 20
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
103361 184320 184320 210971 0 20
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
123466 184320 184320 231076 0 22
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
143954 184320 184320 251564 0 22
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
159205 184320 184320 258499 0 22
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
184159 184320 184320 291769 0 26
--这时actual redo blocks已经到了184149了，马上接近90％ of redologfile，意味着再有一些日志进来以后，就会触发增量检查点。
--这时47号日志的状态还是没有变化的，还是active：
SQL> select * from v$Log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 47 104857600 3 NO ACTIVE 1210034 11-DEC-06
2 1 48 104857600 3 NO CURRENT 1213051 11-DEC-06
3 1 46 104857600 3 YES INACTIVE 1209429 11-DEC-06
--再次插入数据：
--actual redo blocks超过90％ of logfile，这时应该触发增量检查点，最后一次查询是增量检查点发生之后的actual redo blocks值，已经小于90％ of logfile。
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
204281 184320 184320 372918 0 28
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
204281 184320 184320 372918 0 28
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
183929 184320 184320 373265 0 28
--注意增量检查点只是写出一部分脏数据，只要保证actual redo blocks小于90％ of logfile就可以了。
--这时查询x$kcccp，发现最后一次检查点的位置已经升高，但依旧在47号日志上面：
SQL> select CPLRBA_SEQ,CPLRBA_BNO,CPODR_SEQ,CPODR_BNO from x$kcccp;
CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------
47 185730 48 118320
--再次插入数据，并查询v$instance_recovery
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
184588 184320 184320 393585 0 30
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
184588 184320 184320 393604 0 30
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
183868 184320 184320 393604 0 30
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
183869 184320 184320 393604 0 30
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
183881 184320 184320 393617 0 28
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
183881 184320 184320 393617 0 28
--由于再次超过阀值，增量检查点再次发生，并写出了一些脏块，此时查询x$kcccp，发现最后一次检查点的位置已经提到48号日志：
SQL> select CPLRBA_SEQ,CPLRBA_BNO,CPODR_SEQ,CPODR_BNO from x$kcccp;
CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------
48 6072 48 188945
--观察alert log：log switch checkpoint 完成。
Mon Dec 11 15:29:08 2006
Completed checkpoint up to RBA [0x30.2.10], SCN: 0x0000.0012827b
--这里注意RBA已经指向日志 0x30，转换成10进制就是，16×3＝48，这与上面x$kcccp查到的情况是相符的。
--由于最后一次检查点的位置已经超过47号日志，那么47号日志对于实例恢复来说就没有用了，来看看47号日志的状态：
--观察v$log，47号日志的状态已经变为INACTIVE
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 47 104857600 3 NO INACTIVE 1210034 11-DEC-06
2 1 48 104857600 3 NO CURRENT 1213051 11-DEC-06
3 1 46 104857600 3 YES INACTIVE 1209429 11-DEC-06
总结一下：通常所说的logfile switch 触发检查点，实际上就是给出一个标记，而并不真正去写脏块。等待增量检查点做到了那个标记，再标识完成。
b、第二个发生增量检查点的条件：LOG_CHECKPOINT_TIMEOUT
这个参数说白了就是控制2次增量检查点之间所发生的时间间隔，超过这个间隔，就会触发增量检查点。
从另外一个角度理解，就是脏块在buffer cache中所能存在的最大时间。
为了让实验更明显，把这个参数设小点，1分钟：
SQL> show parameter log_checkpoint
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean TRUE
SQL> alter system set log_checkpoint_timeout = 60;
System altered.
SQL> show parameter log_checkpoint;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 60
log_checkpoints_to_alert boolean TRUE
--查看v$instance_recovery视图：
SQL> select actual_redo_blks act,target_redo_blks target,LOG_FILE_SIZE_REDO_BLKS logfile,LOG_CHKPT_TIMEOUT_REDO_BLKS log_check,target_mttr tmttr,estimated_mttr es_mttr from v$instance_recovery;
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
7 15 184320 15 0 7
--看到target 和 log_CHECKPOINT_TIMEOUT的值是一样的，而且变的特别小，只要actual redo blocks超过这个数量就会触发增量检查点。
--下面重复上面的那个实验，不断的插入数据，以产生redo log，然后观察检查点发生的情况：
--先看看redo log的状态：
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 47 104857600 3 NO INACTIVE 1210034 11-DEC-06
2 1 48 104857600 3 NO CURRENT 1213051 11-DEC-06
3 1 46 104857600 3 YES INACTIVE 1209429 11-DEC-06
--增量检查点的位置：
SQL> select CPLRBA_SEQ,CPLRBA_BNO,CPODR_SEQ,CPODR_BNO from x$kcccp;
CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------
48 189440 48 189462
--插入数据，并观察v$instance_recovery
SQL> insert into test select * from test where rownum < 100000;
99999 rows created.
--观察v$instance_recovery
SQL> select actual_redo_blks act,target_redo_blks target,LOG_FILE_SIZE_REDO_BLKS logfile,LOG_CHKPT_TIMEOUT_REDO_BLKS log_check,target_mttr tmttr,estimated_mttr es_mttr from v$instance_recovery;
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
20433 20433 184320 20433 0 10
SQL> /
ACT TARGET LOGFILE LOG_CHECK TMTTR ES_MTTR
---------- ---------- ---------- ---------- ---------- ----------
56 85 184320 85 0 10
--1分钟后发生了增量检查点，actual redo blocks减少了不少：
--看看增量检查点的位置：
SQL> select CPLRBA_SEQ,CPLRBA_BNO,CPODR_SEQ,CPODR_BNO from x$kcccp;
CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------
48 189486 49 5126
SQL> /
CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------
49 5126 49 5183
--检查点的位置提升了2次，并提升到了49号日志，这时看到alert log中的log switch checkpoint也完成了：
Mon Dec 11 16:12:50 2006
Beginning log switch checkpoint up to RBA [0x31.2.10], SCN: 0x0000.00128ded
Thread 1 advanced to log sequence 49
Current log# 3 seq# 49 mem# 0: /u01/app/oracle/oradata/novo/redo03.log
Mon Dec 11 16:13:56 2006
Completed checkpoint up to RBA [0x31.2.10], SCN: 0x0000.00128ded
--这里注意从checkpoint begin到end的时间间隔是1分钟，这与log_checkpoint_timeout的条件是吻合的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/25964700/viewspace-700999/ ，如需转载，请注明出处，否则将追究法律责任。
