checkpoint详解(转)

最新推荐文章于 2024-05-18 15:36:39 发布
最新推荐文章于 2024-05-18 15:36:39 发布
阅读量564 收藏
点赞数
文章标签： 数据库 php 操作系统
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 LOGFILE
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：实例恢复的时间限制，
oracle将这个时间换算成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 0
log_checkpoints_to_alert boolean TRUE
SQL> alter system checkpoint;
系统已更改。
日志中的信息：完全检查点立即执行。
Beginning global checkpoint up to RBA [0x52f.5c2.10], SCN: 0x0000.0045bf00
Completed checkpoint up to RBA [0x52f.5c2.10], SCN: 0x0000.0045bf00
从v$instance_recovery 中看到actual_redo_blks瞬间为0，说明完全检查点清除脏列表上的所有的脏块。
同时也会完成之前没有完成的日志切换检查点，这时查询v$log，active的状态转变为inactive。
第1个窗口
SQL> alter system checkpoint;
系统已更改。
第2个窗口
10:24:54 SQL> select actual_redo_blks from v$instance_recovery;
ACTUAL_REDO_BLKS
----------------
128
10:25:09 SQL> /
ACTUAL_REDO_BLKS
----------------
128
10:25:11 SQL> /
ACTUAL_REDO_BLKS
----------------
0
10:25:45 SQL>
此时查看警报日志：
Beginning global checkpoint up to RBA [0x531.8f.10], SCN: 0x0000.00461fd1
Completed checkpoint up to RBA [0x531.8f.10], SCN: 0x0000.00461fd1
531转成十进制就是1329，是当前的在线日志序列号：
SQL> select group#,sequence#,status from v$Log;
GROUP# SEQUENCE# STATUS
---------- ---------- ---------------------------
4 1328 INACTIVE
5 1329 CURRENT
6 1327 INACTIVE
SQL> alter system dump logfile 'D:ORACLEORADATATEST9REDO05.LOG';
系统已更改。
转储日志，找到对应的rba
REDO RECORD - Thread:1 RBA: 0x000531.0000008f.0010 LEN: 0x0428 VLD: 0x02
SCN: 0x0000.00461fd1 SUBSCN: 1 12/05/2006 10:25:43
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 1 rdba: 0x00403162(1,12642)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00403159(1,12633)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00403158(1,12632)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x0040314b(1,12619)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x0040314a(1,12618)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00403149(1,12617)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401efa(1,7930)
scn: 0x0000.00461fca seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401eba(1,7866)
scn: 0x0000.00461fcc seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401387(1,4999)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401386(1,4998)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401373(1,4979)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401372(1,4978)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401370(1,4976)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x0040136a(1,4970)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401365(1,4965)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401363(1,4963)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00401347(1,4935)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400e8c(1,3724)
scn: 0x0000.00461f62 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400cae(1,3246)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400cac(1,3244)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400cab(1,3243)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400ca9(1,3241)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x004005da(1,1498)
scn: 0x0000.00461f90 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x004005ca(1,1482)
scn: 0x0000.00461f90 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400181(1,385)
scn: 0x0000.00461f5d seq: 0x01 flg:0x04
Block Written - afn: 1 rdba: 0x0040006a(1,106)
scn: 0x0000.00461f5e seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x0040002b(1,43)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400028(1,40)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400027(1,39)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400026(1,38)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400023(1,35)
scn: 0x0000.00461f88 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400018(1,24)
scn: 0x0000.00461f4b seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x0081645c(2,91228)
scn: 0x0000.00461f6d seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x0081645b(2,91227)
scn: 0x0000.00461fc8 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x008072d3(2,29395)
scn: 0x0000.00461f65 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x008072d2(2,29394)
scn: 0x0000.00461fcb seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00802ffa(2,12282)
scn: 0x0000.00461f6a seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00802ff9(2,12281)
scn: 0x0000.00461fc3 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00802df1(2,11761)
scn: 0x0000.00461f6c seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00802df0(2,11760)
scn: 0x0000.00461fc6 seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00802d66(2,11622)
scn: 0x0000.00461fc9 seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00802d65(2,11621)
scn: 0x0000.00461f63 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00802d64(2,11620)
scn: 0x0000.00461f74 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00802c18(2,11288)
scn: 0x0000.00461f67 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00802c17(2,11287)
scn: 0x0000.00461fb4 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00802b92(2,11154)
scn: 0x0000.00461f68 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00802b89(2,11145)
scn: 0x0000.00461fbf seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x008028e0(2,10464)
scn: 0x0000.00461f69 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x008028df(2,10463)
scn: 0x0000.00461fc1 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00801472(2,5234)
scn: 0x0000.00461f6b seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00801471(2,5233)
scn: 0x0000.00461fc5 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800a64(2,2660)
scn: 0x0000.00461f66 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800a63(2,2659)
scn: 0x0000.00461fcc seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800099(2,153)
scn: 0x0000.00461fc9 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800089(2,137)
scn: 0x0000.00461fc7 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800079(2,121)
scn: 0x0000.00461fc6 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800069(2,105)
scn: 0x0000.00461fc4 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800059(2,89)
scn: 0x0000.00461fc2 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800049(2,73)
scn: 0x0000.00461fc0 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800039(2,57)
scn: 0x0000.00461fb5 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800029(2,41)
scn: 0x0000.00461fcd seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800019(2,25)
scn: 0x0000.00461fcc seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800009(2,9)
scn: 0x0000.00461fca seq: 0x01 flg:0x04
Block Written - afn: 1 rdba: 0x00400009(1,9)
scn: 0x0000.00461f5e seq: 0x01 flg:0x04
注意 这条redo record的scn：SCN: 0x0000.00461fd1，和检查点scn是一致的。
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 4595665
2 4595665
3 4595665
4 4595665
5 4595665
6 4595665
7 4595665
已选择7行。
SQL> select to_char(4595665,'xxxxxxx') from dual;
TO_CHAR(4595665,
----------------
461fd1
研究写出脏块的数量：
SQL> select count(1) from v$bh where dirty='Y';
COUNT(1)
----------
42
SQL> alter system checkpoint;
系统已更改。
SQL> select count(1) from v$bh where dirty='Y';
COUNT(1)
----------
11
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 4596768
2 4596768
3 4596768
4 4596768
5 4596768
6 4596768
7 4596768
已选择7行。
SQL> select to_char(4596768,'xxxxxxx') from dual;
TO_CHAR(4596768,
----------------
462420
找到462420的redo record：正好是31个脏块
REDO RECORD - Thread:1 RBA: 0x000531.0000028d.0010 LEN: 0x0218 VLD: 0x02
SCN: 0x0000.00462420 SUBSCN: 1 12/05/2006 10:48:14
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 1 rdba: 0x00401efa(1,7930)
scn: 0x0000.00462413 seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400e8c(1,3724)
scn: 0x0000.0046237f seq: 0x01 flg:0x06
Block Written - afn: 1 rdba: 0x00400d5a(1,3418)
scn: 0x0000.0046227e seq: 0x01 flg:0x06
Block Written - afn: 2 rdba: 0x0081645c(2,91228)
scn: 0x0000.004623fd seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x0081645b(2,91227)
scn: 0x0000.0046215e seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x008072d2(2,29394)
scn: 0x0000.0046240a seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00802ffa(2,12282)
scn: 0x0000.00462412 seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00802ff9(2,12281)
scn: 0x0000.004622f8 seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00802df1(2,11761)
scn: 0x0000.00462415 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00802df0(2,11760)
scn: 0x0000.004622a9 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00802d66(2,11622)
scn: 0x0000.004620ea seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00802d65(2,11621)
scn: 0x0000.00462408 seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00802c18(2,11288)
scn: 0x0000.0046240e seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00802c17(2,11287)
scn: 0x0000.0046207e seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00802b92(2,11154)
scn: 0x0000.0046240f seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00802b89(2,11145)
scn: 0x0000.004622f4 seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x008028df(2,10463)
scn: 0x0000.00462411 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00801472(2,5234)
scn: 0x0000.00462414 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00801471(2,5233)
scn: 0x0000.004623c1 seq: 0x03 flg:0x04
Block Written - afn: 2 rdba: 0x00800a63(2,2659)
scn: 0x0000.0046240c seq: 0x02 flg:0x04
Block Written - afn: 2 rdba: 0x00800099(2,153)
scn: 0x0000.004623fe seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800089(2,137)
scn: 0x0000.00462416 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800079(2,121)
scn: 0x0000.00462415 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800069(2,105)
scn: 0x0000.00462413 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800059(2,89)
scn: 0x0000.00462412 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800049(2,73)
scn: 0x0000.00462410 seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800039(2,57)
scn: 0x0000.0046240f seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800029(2,41)
scn: 0x0000.0046240d seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800019(2,25)
scn: 0x0000.0046240b seq: 0x01 flg:0x04
Block Written - afn: 2 rdba: 0x00800009(2,9)
scn: 0x0000.00462409 seq: 0x01 flg:0x04
Block Written - afn: 1 rdba: 0x00401eba(1,7866)
scn: 0x0000.00462415 seq: 0x01 flg:0x06
REDO RECORD - Thread:1 RBA: 0x000531.0000028f.0010 LEN: 0x01bc VLD: 0x01
SCN: 0x0000.00462422 SUBSCN: 1 12/05/2006 10:48:17
总结一下：完全检查点会清空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> l
1* 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> l
1* 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> l
1* 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的条件是吻合的。


----赋另外一篇介绍checkpoint的文章----

checkpoint扫盲
什么是checkpoint在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是保证在提交（commit）完成之前要先保证日志都被写入到日志文件中，而脏数据块着保存在数据缓存（buffer cache）中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的，而数据写入和提交操作是不同步的。这样就存在一个问题，当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中，这样在实例启动的时候就要使用日志文件进行恢复操作，将数据库恢复到崩溃之前的状态，保证数据的一致性。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。
一般所说的checkpoint是一个数据库事件（event），checkpoint事件由checkpoint进程（LGWR/CKPT进程）发出，当checkpoint事件发生时DBWn会将脏块写入到磁盘中，同时数据文件和控制文件的文件头也会被更新以记录checkpoint信息。

checkpoint的作用checkpoint主要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由三个部分组成：
  • 日志文件序列号（4字节）
  • 日志文件块编号（4字节）
  • 重做日志记录在日志块中的起始偏移字节数（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命令发出时。

特别注意：

  • 日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。
  • 日志切换触发的是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行为：

类似于alter system checkpoint这样的语句所产生的，先记录下当前的scn，然后推动DBWn进程去写脏数据，当写到所记录的scn时候检查点结束，然后ckpt进程将记录的scn写入到控制文件和数据文件头。

  • 设置参数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]
  • ckpt进程每3s起来一次记录checkpoint的进度到控制文件中，这种情况跟上面的类似，只不过在alert里面是看不到的，而且也不是每次唤醒都会写控制文件的，而是有就记，没有就拉倒。
  • 类似于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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20928639/viewspace-749736/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20928639/viewspace-749736/

cuijiao6918
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Oracle checkpoint详解
cm333666的博客
05-08 317
checkpoint扫盲 top什么是checkpoint 在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是...
Oracle检查点（Checkpoint）详解 (文档 ID 1526118.1)
weixin_34144848的博客
11-19 1198
Oracle检查点（Checkpoint）详解 1.检查点概念--chkpoint 检查点是一个数据库事件，存在的意义在于减少崩溃恢复crash recovery时间.检查点事件由后台进程CKPT触发，当检查点发生时，CKPT通知DBWR进程将脏数据库dirtybuffer写出到数据文件上，更新数据文件头及...
什么是Checkpoint？
最新发布
Flemington7的博客
05-18 2698
在机器学习和深度学习中，checkpoint（检查点）是指在模型训练过程中保存的模型状态。这些检查点通常包括模型的参数（权重和偏置）、优化器状态和其他相关的训练信息。通过保存检查点，您可以在训练过程中定期保存模型的当前状态，以便在需要时恢复训练或用于模型评估和推理。Checkpoint 是机器学习和深度学习训练过程中的重要工具。它可以防止数据丢失，帮助调试和优化模型，并在模型评估和推理中发挥重要作用。通过定期保存检查点，您可以在训练过程中随时恢复模型状态，继续训练或进行推理。
oracle数据库日志中报错：checkpoint not completed 导致高发时段数据库宕机解决方式
qq_42755868的博客
01-12 523
近期在自己搭设的环境中测试了一下，发现每一周都会有数据库宕机的情况出现，查看日志频繁出现：checkpoint not completed 提示。 度了一下网上的分享，发现是数据库出现脏数据块写入落库时，日志分组无法做及时切换导致的。 可以分别通过以下语句做查看： ①查看制定日期后每一天的日志分组切换次数，查看高峰时段的切换次数，根据切换次数对日志分组做调整。 SELECT TO_CHAR(first_time,'yyyy-mm-dd') day1, COUNT(*) FROM v$log_histor
Oracle中全量CHECKPOINT和增量CHECKPOINT的区别与作用
weixin_46593978的博客
05-16 332
全量CHECKPOINT和增量CHECKPOINT对用户都是透明的，而增量CHECKPOINT只不过是将全量CHECKPOINT要写的脏块分时间分批次写到数据文件中而已，此操作可以极大地减少对数据库性能的影响。
oracle switch logfile日志切换及alter system checkpoint作了什么
03-25 322
日志切换或checkpoint到底发生了什么？　　　1,刚变成active的日志文件（即由last_change#到next_change#的redo）被　dbwr写入到数据文件 　　　2,ckpt更新所有数据文件头的star...
TensorFlow实现checkpoint文件转换为pb文件
09-17
#### 转换步骤详解 以下是对给定代码片段的详细解释： 1. **导入必要的库**： ```python import os from tensorflow.python import pywrap_tensorflow from net2use import inception_resnet_v2_small # 这里...
Oracle checkpoint 检查点详解
05-20
Oracle Checkpoint 详解 Oracle Checkpoint 是 Oracle 数据库中的一种机制，用于保证数据库的一致性和缩短实例恢复的时间。_checkpoint 事件由 checkpoint 进程（LGWR/CKPT 进程）发出， DBWn 会将脏块写入到磁盘中...
PostgreSQL实战之启动恢复读取checkpoint记录失败的条件详解
12-16
在PostgreSQL数据库系统中，启动恢复过程涉及到对检查点（checkpoint）记录的读取，这是保证数据一致性的重要步骤。本文将深入探讨启动恢复时读取checkpoint记录失败的条件及其背后的原因。 首先，PostgreSQL在启动...
checkpoint的snmp及syslog配置.doc
06-26
### Checkpoint R70 SNMP与Syslog配置详解 #### 一、SNMP配置 ##### 1.1 开启SNMP服务 在Checkpoint R70环境下配置SNMP服务的第一步是确保服务已启用并正常运行。这通常需要在Expert模式下进行。 **步骤一：** - *...
Checkpoint Endpoint R73 FDE安装手册
11-07
### Checkpoint Endpoint R73 FDE安装手册知识点详解 #### 一、环境要求 为了确保Checkpoint Endpoint R73 Full Disk Encryption (简称FDE)能够顺利安装并运行，我们需要满足一定的环境要求。 1. **安装环境**：...
ORACLE中的checkpoint
01-08
ORACLE中的checkpoint
1.Containerd容器运行时初识与尝试
WeiyiGeek 唯一极客IT知识分享
07-13 1213
0x00 前言简述1.基础介绍2.专业术语3.架构简述0x01 安装配置1.Ubuntu安装Containerd.io流程0x02 简单使用1.镜像拉取与运行2.创建和使用网络3.与宿主机和其它容器共享文件4.Docker 与 Containerd 并用配置0x03 Containerd 与 Docker CLI 工具命令表ctr 命令 - Containerd 管理命令...
alter system checkpoint
DBA小林的博客
02-10 1058
当关闭实例后，再启动报错，控制文件old control file，错误是因cache中的信息没有及时写入controlfile导致，避免的方法是在每次停库前,对DB作一次checkpoint, 即ALTER SYSTEM CHECKPOINT;shutdown immediate本身就会执行一次full checkpoint，但提前执行ALTER SYSTEM CHECKPOINT;也会触发checkpoint，但只会对执行sql的那个节点,不会对RAC中的所有节点。
SCN、Redo和Checkpoint
竹林晚风
09-09 595
一、Redo log作用 数据库异常关机（比如突然断电，shutdown abort）之后，这时已经
checkpoint扫盲（转）
cuizuchang3379的博客
08-13 138
checkpoint扫盲 什么是checkpoint 在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，...
oracle中的checkpoint,详解oracle checkpoint
weixin_36033929的博客
04-03 1052
这篇文章，源于群中几位网友的疑问，故打算写这篇文章给其释疑。1. 何为检查点？其存在的意义？2. 检查点的有哪些分类？检查点的结构如何？什么是checkpoint queue？通俗的将，检查点仅仅是一个机制而已，其作用是通知DBWR进程将cache buffer中的脏块写入到disk中，当然这个通知的动作是通过检查点进程CKPT来完成的。那么检查点存在的意义是什么呢？其实很简单，目的就是减少db ...
alter system checkpoint & alter system switch logfile & alter system archive log current
喝醉酒的小白
11-22 3232
https://blog.csdn.net/weixin_33573857/article/details/116482693
ORACLE触发CHECKPOINT的条件~
朝着梦想 渐行前进
12-23 2229
ORACLE触发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 CHE
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值