checkpoint小议(转)

checkpoint小议(转)

checkpoint小议

什么是checkpoint?
checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。

什么时候发生checkpoint?
我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpoint呢？以下几种情况会触发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 CHECKPOINT的时候
5.当运行alter tablespace XXX begin backup，end backup的时候
6.当运行alter tablespace ,datafile offline的时候;

增量检查点（incremental checkpoint）
oracle8以后推出了incremental checkpoint的机制，在以前的版本里每次checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。

数据字典
完全检查点
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

这里显示了上一次的完全检查点是在06/25/2004 18:49:37发生，所以我们推断06/25/2004 18:49:37发生了一次日志切换，再去操作系统上去看生产的归档，果然18：49有一个归档生产。
-rw-r----- 1 oracle oinstall 83532800 Jun 25 18:49 1_948.dbf

增量检查点
SQL> select * from X$KCCCP where indx=0;

ADDR INDX INST_ID CPTNO CPSTA CPFLG CPDRT CPRDB CPLRBA_SEQ CPLRBA_BNO CPLRBA_BOF CPODR_SEQ CPODR_BNO CPODR_BOF CPODS CPODT CPODT_I CPHBT CPRLS CPRLC CPMID CPSDR_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等信息。


xzh2000

大 中 小
使用道具
发表于 2004-6-26 17:19 资料 个人空间 主页 短消息 加为好友
哦，你说的完全检查点与增时检查点是指global与local吗？
还有就是为什么用varchar2(20)来保存cp发生的时间？
alter system checkpoint global;
alter system checkpoint local;

[ Last edited by xzh2000 on 2004-6-26 at 05:20 PM ]



wanghai

使用道具
发表于 2004-6-26 17:34 资料 个人空间 短消息 加为好友
不是说global和local，global和local只是针对单instance和rac,ops来说的。
所谓full checkpoint是指刷新所有脏数据到磁盘，是针对incremental checkpoint来说的。



biti_rainy

荣誉管理员

使用道具
发表于 2004-6-26 23:27 资料 个人空间 短消息 加为好友
每隔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 了。



ora-600

VIP会员

使用道具
发表于 2004-6-27 12:05 资料 个人空间 短消息 加为好友
增量checkpoint是3秒吧，那个是只写控制文件和数据文件头scn的，也就是biti说的保证数据库恢复最快，完全checkpoint会提示dbwn写脏数据，然后执行文件头和控制文件的写操作。



wanghai

使用道具
发表于 2004-6-27 13:34 资料 个人空间 短消息 加为好友
增量检查点并不去更新数据文件头，只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。

上面我写的有点简单，只写了记录checkpoint执行的情况，biti已经补充了，：）

上次关于checkpoint还写了封信给ixora，不过还没得到回复，呵呵



玉面飞龙

荣誉版主

发表于 2004-6-27 16:03 资料 个人空间 短消息 加为好友
来一点简单的

http://asktom.oracle.com/pls/ask/f?p=4950:8:7002783609336625378::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:19311485023372,

the goal of incremental checkpoints is to advance the checkpoint marker so that
less redo would have to be read and applied.

[ Last edited by 玉面飞龙 on 2004-6-27 at 04:05 PM ]



catchwo

甲骨文二段

发表于 2004-6-28 10:03 资料 个人空间 短消息 加为好友

QUOTE:
Originally posted by wanghai at 2004-6-26 04:46 PM:
什么是checkpoint?
checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。

什么时候发生checkpoint?
我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpo ...



catchwo

使用道具
发表于 2004-6-28 10:12 资料 个人空间 短消息 加为好友
小问题

有没有这个可能CHECKPOINT 时候系统记录一个SCN,对于CHECKPOINT以后的数据块更新要看数据块的SCN若SCN<=系统记录的CHECKPOINT时的SCN则要等待数据块写入数据文件后才能进行.否则当写数据文件真正发生时对应于那个CHECKPOINT SCN时的数据块的信息就不正确了(从而要使用REDO数据:性能可能不太好)



wanghai

总版主

发表于 2004-6-28 12:13 资料 个人空间 短消息 加为好友

QUOTE:
Originally posted by morinson at 2004-6-28 11:05 AM:
后生小辈向各位老在请教

问一下，上面说了ckpt每隔3秒只是更新了控制文件的checkpoint progress record这个区域，那么它是什么时候进行数据文件更新的？当更新了控制文件后，正在更新数据文件时，掉电，会出现 ...

数据文件是有dbwr来写的，跟ckpt并没有实质关系。更新控制文件是在更新数据文件之后的动作，所以不用担心，这个时候断电会从上次的ckpt点开始恢复。



wxy8u8

甲骨文初段

VIP会员

上帝的宝贝

UID 4336
精华 1
积分 234
帖子 224
金钱 0 O元
阅读权限 200
注册 2004-2-25
状态 离线 #13
大 中 小
使用道具
发表于 2004-6-29 14:32 资料 个人空间 短消息 加为好友
检查点的作用一是建立数据的一致性。二是为数据库作一个标记。表示数据库可以恢复的最大限度。
由他触发dbwn，把数据写入DATAFILE。再由dbwn触发LGWn把scn写入datafile和control file。

incremental checkpoint的是否应用和间隔时间或间隔的块数应该由FAST_START_IO_TARGET 或FAST_START_MTTR_TARGET参数决定吧。
只是默认的情况是3秒。
但如果指定了FAST_START_IO_TARGET 或LOG_CHECKPOINT_INTERVAL 这两个参数。则FAST_START_MTTR_TARGET就失效了。。

[ Last edited by selina33 on 2004-6-29 at 04:27 PM ]



ljd

甲骨文初段

发表于 2004-6-29 15:15 资料 个人空间 短消息 加为好友
各位前辈，看到此章，非常有感，，，
但有一事请各位帮忙，我们单位现在数据库老是有时快，有时慢，是不是跟这个有关系。我该从哪方面开始查！

谢谢！



fly115

超级版主

发表于 2004-6-29 19:31 资料 个人空间 短消息 加为好友

QUOTE:
Originally posted by ljd at 2004-6-29 03:15 PM:
各位前辈，看到此章，非常有感，，，
但有一事请各位帮忙，我们单位现在数据库老是有时快，有时慢，是不是跟这个有关系。我该从哪方面开始查！

谢谢！

不能肯定是他拉，你慢是指什么意思？是不是同一个语句有时慢有时快吗，如果是这样，那要结合你的statspack来分析，一般来说每个应用都有高峰期和低峰期，看你慢的时候，你的事务量是不是很高（可以在这段时间增加statspack的频率），load的情况如何，是不是有什么耗资源的应用定期在跑（找出这些语句，需要优化他），每秒的重做量是不是很高。io的使用情况，是不是有很多序列读等待还是序列写等待，来合理优化索引
你说的检查点是不是是一个可能的原因，当然有可能，如果没有合理的设置log_buffer大小，logfile放在读写比较差的磁盘上，检查点的频繁程度，合理设置fsfr_start_mttr_target,看看在statspack中存在下面的等待事件

1.log file switch(archiving needed)

日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题，
可增大日志文件和增加日志组，调整log_archive_max_processes
(checkpoint incomplete)

当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成，
通常是io有严重问题，可增大日志文件和增加日志组
2.log file sync(这个到可能是log_buffer太大的反作用)

当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时间太长
（可能是因为一次log io size 太大），可调整 _log_io_size，
结合log_buffer,使得 (_log_io_size*db_block_size)*n =
log_buffer,这样可避免和增大log_buffer引起冲突;
放置日志文件于高速磁盘上

3.log file single write
指出写入到日志文件的标题块.可能表示检查点中等待

4.另外dbwr写是不是存在瓶径
cache buffers lru chain 是否需要增加
需要异步IO吗还是增加从dbwr

[ Last edited by fly115 on 2004-6-29 at 07:33 PM ]



oracle_gao_dba

授权用户

发表于 2004-6-30 00:53 资料 个人空间 短消息 加为好友
精辟，学习....！！！



cby

甲骨文四段

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

转载于:http://blog.itpub.net/644902/viewspace-159213/