ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Checkpoint Tuning -- Checkpoint not complete

Checkpoint Tuning -- Checkpoint not complete

原创 Linux操作系统 作者:tolywang 时间:2007-06-07 00:00:00 0 删除 编辑

数据库在alert日志中频繁的报“Checkpoint not complete”


Thu Jan 25 16:20:53 2007
Thread 2 cannot allocate new log, sequence 1657268
Checkpoint not complete
Current log# 3 seq# 1657267 mem# 0: /dev/rdrd/drd3
Thread 2 advanced to log sequence 1657268
Current log# 4 seq# 1657268 mem# 0: /dev/rdrd/drd4
Thread 2 cannot allocate new log, sequence 1657269
Checkpoint not complete
Current log# 4 seq# 1657268 mem# 0: /dev/rdrd/drd4
Thread 2 advanced to log sequence 1657269
Current log# 3 seq# 1657269 mem# 0: /dev/rdrd/drd3
Thread 2 cannot allocate new log, sequence 1657270
Checkpoint not complete


1.增大redo log的大小
2.增加redo log group的数目.
3.加快dbwr写数据文件速度.

-------------------------------------

Checkpoint Tuning and Troubleshooting Guide

这个主题使DBA能对checkpoint和checkpoint优化的参数有一个较好的理解:
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT

它也解释了怎样解释和处理出现在ALERT.LOG file中的
checkpoint的错误"'Checkpoint not Complete' and 'Cannot Allocate New Log"

什么是checkpoint?

checkpoint是为了内存中已经被修改的数据块与磁盘数据文件同步的一种数据库事件。它提供了一种
保持事务提交以后数据一致的手段。往Oracle磁盘写脏数据的机制与事务提交不是同步的。

checkpoint有两个目地:1.确保数据一致性。2.使数据库能快速地恢复。怎样快速恢复呢?
因为数据库会把所有的改变都在数据文件上设置checkpoint,并一直增加,它不需要请求checkpoint
之前的重做日志.Checkpoint能保证所有在缓存区的数据写到相应的数据文件,防止因为意外的实例
失败导致的数据丢失。

Oracle写这个脏数据只在一定的条件下:
后面的进程需要1/4个db_block_buffer参数的大小
每三秒
当一个checkpoint产生

一个checkpoint有5中事件类型:
每次重做日志的切换
LOG_CHECKPOINT_TIMEOUT 这个延迟参数的到达。
相应字节(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)被写到当前的重做日志

IO OS blocks: 在UNIX下可以 # fstyp -v /dev/vg00/lvol1
vxfs
version: 5
f_bsize: 8192

ALTER SYSTEM SWITCH LOGFILE 这个命令会直接导致checkpoint发生
ALTER SYSTEM CHECKPOINT

Checkpoint期间会有下面进程发生:
DBWR写所有脏数据到数据文件
LGWR更新控制文件和数据文件的SCN

Checkpoints和优化
Checkpoints是一个数据库优化的难点。频繁的Checkpoints可以实现快速的恢复,但也会使性能
下降。DBA怎样处理这个问题呢?

依赖于数据库数据文件的数量,一个Checkpoint可能是高速的运行。因为所有的数据文件在Checkpoint
期间都会被冻结。更频繁的Checkpoints可以快速恢复数据库。这也客户对不按规定系统宕机的容忍的原因。
然而,在一些特殊情况下,频繁的Checkpoints也不能保证可以快速恢复。我们假设数据库在95%的时间
内是正常运行,5%由于实例失败导致不可用,要求恢复。对大多数客户而言,他们更希望调整95%
的性能而不是5%的宕机时间。

这个假设表明,性能是摆在第一位的,所以我门的目标就是在优化期间减少Checkpoints的频繁度。

优化Checkpoints包括4个关键的初始化参数:
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT

详细介绍每个参数:
FAST_START_MTTR_TARGET

Oracle9i以来FAST_START_MTTR_TARGET 参数是调整checkpoint的首选的方法。
FAST_START_MTTR_TARGET 可以指定单实例恢复需要的秒数。基于内部的统计,增长的
checkpoint会自动调整的checkpint的目标以满足FAST_START_MTTR_TARGET 的需求。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR 显示当前估计需要恢复的秒数。这个值会被显示
即使FAST_START_MTTR_TARGET 没有被指定。
V$INSTANCE_RECOVERY.TARGET_MTTR 表明在短时间内MTTR的目标。
V$MTTR_TARGET_ADVICE 显示这个当前MTTR设置的工作量产生的I/O数量和其他I/O。
这个视图帮助用户评定这个在优化和恢复之前的平衡。

LOG_CHECKPOINT_INTERVAL

LOG_CHECKPOINT_INTERVAL 参数指定这个最大的重做块的间隔数目。
如果FAST_START_MTTR_TARGET被指定,LOG_CHECKPOINT_INTERVAL不能被设置为0.


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

请登录后发表评论 登录
全部评论
Oracle , MySQL, SAP IQ, SAP HANA, PostgreSQL, Tableau 技术讨论,希望在这里一起分享知识,讨论技术,畅谈人生 。

注册时间:2007-12-10

  • 博文量
    5595
  • 访问量
    13100600