Checkpoint not Complete' and 'Cannot Allocate New Log

Thread 2 cannot allocate new log, sequence 4510
Checkpoint not complete
Current log# 3 seq# 4509 mem# 0: +MYASM/baan/onlinelog/group_3.268.592727939
Thread 2 advanced to log sequence 4510
Current log# 4 seq# 4510 mem# 0: +MYASM/baan/onlinelog/group_4.264.592727939
Tue May 29 16:22:14 2007
Thread 2 cannot allocate new log, sequence 4511
Checkpoint not complete
Current log# 4 seq# 4510 mem# 0: +MYASM/baan/onlinelog/group_4.264.592727939
Thread 2 advanced to log sequence 4511
Current log# 3 seq# 4511 mem# 0: +MYASM/baan/onlinelog/group_3.268.592727939
Tue May 29 16:23:08 2007
Thread 2 cannot allocate new log, sequence 4512
Checkpoint not complete
在metalink找到一些答案

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.

在大多数Unix系统的OS块大小是512字节。设置LOG_CHECKPOINT_INTERVAL=10000意味着
这个增长的checkpoint不能追加到当前日志因为多于5M。如果你的重做日志是20M，你将
发出4个checkpoint对每个重做日志。

LOG_CHECKPOINT_INTERVAL 会发生影响当一个checkpoint发生时，小心设置这个参数，
保持它随着重做日志文件大小变化而变化。checkpoint频繁是这个影响数据库恢复的原因之一。
短的checkpoint间隔意味数据库将快速恢复，也增加了资源的利用。

这个参数也影响数据库向前回滚的时间。实际的恢复时间是基于这个时间，当然还有失败的类型和
需要归档日志的数量。

LOG_CHECKPOINT_TIMEOUT
这个参数指定checkpoint发出的时间间隔。换句话说，它指定一次脏数据多少时间写出一次。

checkpoint频率会影响这个数据库恢复的时间。长时间的间隔会要求数据库恢复要求更久。
Oracle建议用LOG_CHECKPOINT_interval去控制checkpoint而不用LOG_CHECKPOINT_TIMEOUT
,LOG_CHECKPOINT_TIMEOUT每n秒发一次checkpoint,不顾事务提交的频率。这可能会导致一些
没有必要的checkpoint在事务已经变化的情况下。不必要的checkpoint必须被避免。

还有一个容易误解的地方：LOG_CHECKPOINT_TIMEOUT 会间隔性地发出log switch。
而Log switch会触发一个checkpoint,但checkpoint不会导致一个log switch.唯一手工方式
alter system switch logfile或者重新设置redo logs大小 可以导致频繁switch.

在线重做日志的大小是关键的对于优化和恢复。

解决方法:

If redo logs switch every 3 minutes, you will see performance degradation.
This indicates the redo logs are not sized large enough to efficiently handle
the transaction load.

size of the redolog files.
Using Statspack to determine Checkpointing problems

Statspack snapshots can be taken every 15 minutes or so, these reports gather useful
information about number of checkpoints started and checkpoints completed and number
of database buffers written during checkpointing for that window of time . It also contains
statistics about redo activity. Gathering and comparing these snapshot reports gives you
a complete idea about checkpointing performance at different periods of time.

Another important thing to watch in statspack report is the following wait events,
they could be a good indication about problems with the redo log throughput and checkpointing:

log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch/archive
log file switch (clearing log file)
log file switch completion
log switch/archive
log file sync

In the case when one or more of the above wait events is repeated frequently
with considerable values then you need to take an action like adding More
online redo log files or increasing their sizes and/or modifying checkpointing parameters.

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