1. full chekcpoint的一些基础知识
我们汉子道检查点其实是一个数据库事件，它存在的目的其实有2个:
1)建立数据的一致性
2）保证数据库尽可能快的恢复
full chekcpoint检查点的分类以及检查点的触发机制：
主要有如下几种触发机制：
--手工触发
--日志切换
--object 检查点
--并行查询
--3s check机制
检查点触发后会post信息给dbwn进程去写dirty block.那么dbwn进程写脏块的条件有哪些？
1）oracle shadow 进程扫描cache buffer链表超过25%,会触发，同时如果扫描达到40%后，仍然没有空闲buffer可用，
那么会post信息给dbwn去将buffer cache中的脏块写入到disk中。这2个机制是通过如下参数来控制的：
SQL> show parameter dirty
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_db_large_dirty_queue integer 25
SQL> show parameter db_block_max
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_db_block_max_cr_dba integer 6
_db_block_max_scan_pct integer 40
这里dbwn进程写脏块的顺序是怎么样的？根据chekcpoint queue来进行的，根据checkpoint queue将脏块按照seq进行顺序的写入到disk中。
SQL> alter system checkpoint;
System altered.
SQL> select file#,checkpoint_change# from v$datafile order by 1;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 7867966
2 7867966
4 7867966
5 7867966
6 7867966
SQL> select file#,checkpoint_change# from v$datafile_header order by 1;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 7867966
2 7867966
4 7867966
5 7867966
6 7867966
SQL> select rtckp_rba_seq||'.'||rtckp_rba_bno||'.'|| rtckp_rba_bof "RBA",rtckp_scn from x$kccrt;
RBA RTCKP_SCN
---------------------------------------- ----------------
323.2661.16 7867966
查看alert此时的日志
Beginning global checkpoint up to RBA [0x143.a65.10], SCN: 7867966
Completed checkpoint up to RBA [0x143.a65.10], SCN: 7867966
0x143.a65.10转换成十进制是323.2661.16
BBED> set file 5 block 1
FILE# 5
BLOCK# 1
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x00780e3e
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x3b33782c
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000143
ub4 kcrbabno @504 0x00000a65
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
---------------
占用12个字节
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000143 ------redo的seq的值
ub4 kcrbabno @504 0x00000a65
ub2 kcrbabof @508 0x0010
1）什么是增量检查点
我们知道oracle引入检查点机制的目的，是尽可能的降低实例恢复的时间，然后由于以前的版本只有full checkpoint,而每次触发full checkpoint都必须让dbwn进程将
cache buffer的所有脏块写入到disk中。对于一个大型OLTP系统而言，将所有脏块写入到disk中，会产生巨大的IO消耗，而且一旦此时数据库crash，那么实例恢复的时间会
相当的漫长。
故oracle引入增量检查点，这样让dbwn写脏块的频率变的更高一些，不仅可以缓解io压力，同时也能降低实例恢复的时间。oracle8i开始引入增量检查点。
2） 增量检查点相关的参数
log_checkpoint_interval 设定两次checkpoint之间重做日志块数量，当重做日志块数量达到设定值的时候将触发checkpoint.
log_checkpoint_timeout 设定两次checkpoint之间的间隔时间，当超时增量checkpoint将被触发。 ORACLE建议不用这个参数来控制，因为事务大小不是按时间等量分布的。单位是秒。
fast_start_io_target 因为log_checkpoint_interval主要看的是重做日志块的数量，并不能反映buffer cache中脏数据块的修改，因此oracle又引入了这个参数来实现当脏块达到一定数量
的时候触发checkpoint,不过此参数实际上控制的是恢复时所需IO的数量。
从9i，oracle引入了新的参数来代替上面的几个参数:
fast_start_mttr_target
关于该参数，一旦你设置之后，上面的几个参数的值就是通过这个参数来计算的。
SQL> select tt.TARGET_MTTR,tt.ESTIMATED_MTTR,tt.CKPT_BLOCK_WRITES,tt.CKPT_BLOCK_WRITES from v$instance_recovery tt ;
TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES CKPT_BLOCK_WRITES
----------- -------------- ----------------- -----------------
0 7 1300 1300
从10g开始，oracle引入了增量检查点的自动调节机制：
SQL> show parameter checkpoint
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_disable_incremental_checkpoints boolean FALSE --决定是否启动增量检查点。
_disable_selftune_checkpointing boolean FALSE 决定是否启动增量检查点自动调节。
_gc_global_checkpoint_scn boolean TRUE
_kdli_checkpoint_flush boolean FALSE
_log_checkpoint_recovery_check integer 0
_selftune_checkpoint_write_pct integer 3 是一个百分比
_selftune_checkpointing_lag integer 300 默认值300s
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean TRUE
3）增量检查点的实质
增量检查点不会更新datafile header，仅仅是更新controlfile。记住redo switch也是会触发增量检查点的。但是redo switch所触发增量检查点，并不是真正的增量检查点，
因为它会更新controlfile和datafile header。
通过实验观察一下：
++++++++++session1
SQL> col "RBA" for a30;
SQL> select rtckp_rba_seq||'.'||rtckp_rba_bno||'.'|| rtckp_rba_bof "RBA",rtckp_scn from x$kccrt;
RBA RTCKP_SCN
------------------------------ ----------------
325.2.16 7931250
SQL> oradebug setmypid
Statement processed.
SQL> alter session set events 'immediate trace name controlf level 3';
Session altered.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_12817.trc
此时观察一个datafie header 的checkpoint信息：
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x00790572
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x3b3476a5
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000145
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
++++++++session2
进行大量的dml操作
SQL> delete from tt where rownum<200;
199 rows deleted.
SQL> commit;
Commit complete.
SQL> delete from tt where rownum<10000;
9999 rows deleted.
SQL> commit;
Commit complete.
SQL> insert into tt values(22);
1 row created.
SQL> commit;
Commit complete.
----------session3
SQL> oradebug setmypid
Statement processed.
SQL> alter session set events 'immediate trace name controlf level 3';
Session altered.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_12893.trc
此时再次观察datafile checkpint信息：
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x00790572
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x3b3476a5
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000145
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
之前的：
DATA FILE #5:
name #5: /u01/app/oracle/oradata/orcl/tbs_unvdata01.dbf
creation size=0 block size=8192 status=0xe head=5 tail=5 dup=1
tablespace 6, index=4 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:187 scn: 0x0000.00790572 11/27/2018 10:59:49
Stop scn: 0xffff.ffffffff 11/22/2018 10:03:22
Creation Checkpointed at scn: 0x0000.004f62b1 10/16/2018 17:49:00
thread:0 rba:(0x0.0.0)
之后的：
DATA FILE #5:
name #5: /u01/app/oracle/oradata/orcl/tbs_unvdata01.dbf
creation size=0 block size=8192 status=0xe head=5 tail=5 dup=1
tablespace 6, index=4 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:187 scn: 0x0000.00790572 11/27/2018 10:59:49
Stop scn: 0xffff.ffffffff 11/22/2018 10:03:22
Creation Checkpointed at scn: 0x0000.004f62b1 10/16/2018 17:49:00
thread:0 rba:(0x0.0.0)
orcl_ora_12817.trc
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:50
low cache rba:(0x145.1051.0) on disk rba:(0x145.10c4.0)
on disk scn: 0x0000.00790b6e 11/27/2018 11:22:53
resetlogs scn: 0x0000.000e2006 09/14/2018 11:30:48
heartbeat: 993285236 mount id: 1521006257
orcl_ora_12893.trc
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:213
low cache rba:(0x145.10c4.0) on disk rba:(0x145.25bd.0)
on disk scn: 0x0000.00790c4c 11/27/2018 11:27:53
resetlogs scn: 0x0000.000e2006 09/14/2018 11:30:48
heartbeat: 993285346 mount id: 1521006257
从上面可以得出一下结论：
1）增量检查点仅仅更新controlfile，不会更新datafile header中的checkpoint的信息。
2）增量检查点会仅仅是controlfile中的checkpoint progress records记录中的如下信息：
low cache rba ,on disk rba ,on disk scn不会去更新controlfile中datafile对应的checkpoint scn等信息。
alter system switch logfile;
更新了checkpoint rba信息，同时datafile header的checkpoint scn信息也更新了。
实际上，检查点队列就是一个列表，而这个列表上包含一系列的buffer cache中的脏块，当然这些脏块的顺序是最早被修改的脏块放在前面，稍后修改的脏块在后面，
总之是根据time来 排序 的。
checkpoint queue是一个列表，每个checkpointqueue的一个位置我们称职为postion，当然这个postion就是通过rba来表示的。所以你可以理解为：
checkpoint queue就是一些脏块对应的buffer header列表，每个buffer header里面还包含了rba信息，只是这些rba是有一定顺序的。
每个rba都对应buffer cache中的一个脏块，而脏块这里也是分时间前后的，所以对应的checkpoint queue 上的checkpoint rba也是分先后的。
1）这里补充一点，dbwn进程要写脏块，那么久需要扫描LRU链表，在扫描之前需要先获得 cache buffer lru chains这个latch。
还有，dbwn进行在修改buffer cache中的数据之前，需要获得一个free buffer。cache buffer是被划分成多个buffer pool，然后，每个buffer pool里面的free buffer 是通过hash bucket
来管理的。当然，bucket的个数，是通过oracle隐含参数来控制：
SQL> show parameter db_block_hash
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_db_block_hash_buckets integer 65536
_db_block_hash_latches integer 2048
2） buffer header dump
SQL> oradebug setmypid
Statement processed.
SQL> alter session set events ' immediate trace name buffers level 1';
Session altered.
SQL> oradebug close_trace
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14141.trc
Dump of buffer cache at level 1 for tsn=2147483647 rdba=0
BH (0x647ea7f0) file#: 2 rdba: 0x00813c80 (2/81024) class: 8 ba: 0x6461c000
set: 20 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
dbwrid: 0 obj: 6592 objn: 6592 tsn: 1 afn: 2 hint: f
hash: [0x710f89b0,0x710f89b0] lru: [0x67bf1420,0x6d3e33e0]
lru-flags: hot_buffer
ckptq: [NULL] fileq: [NULL] objq: [0x6b3e2b80,0x612d6988] objaq: [0x6afe6748,0x612d6978]
st: XCURRENT md: NULL fpin: 'ktspfwh10: ktspscan_bmb' tch: 0
flags: block_written_once redo_since_read
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [3]
BH (0x6cfd7e90) file#: 2 rdba: 0x00821a9c (2/137884) class: 1 ba: 0x6cc34000
set: 17 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
dbwrid: 0 obj: 87239 objn: 87239 tsn: 1 afn: 2 hint: f
hash: [0x710f8a00,0x710f8a00] lru: [0x6cfd7d10,0x6c3e7958]
lru-flags: hot_buffer
ckptq: [NULL] fileq: [NULL] objq: [0x61299158,0x61299158] objaq: [0x61299148,0x61299148]
st: XCURRENT md: NULL fpin: 'ktspbwh1: ktspfsrch' tch: 1
flags: block_written_once redo_since_read
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
以上所述就是小编给大家介绍的《full checkpoint》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Uberland
Alex Rosenblat / University of California Press / 2018-11-19 / GBP 21.00
Silicon Valley technology is transforming the way we work, and Uber is leading the charge. An American startup that promised to deliver entrepreneurship for the masses through its technology, Uber ins......一起来看看 《Uberland》 这本书的介绍吧!
