在alert_.log中出现Checkpoint not Complete

在alert_.log中出现Checkpoint not Complete

alter_ORCL.log如下：
Wed May 18 10:12:06 2011
Thread 1 advanced to log sequence 563
  Current log# 1 seq# 563 mem# 0: /home/oracle/oracle/oradata/steel/redo01.log
Wed May 18 10:16:04 2011
Thread 1 advanced to log sequence 564
  Current log# 2 seq# 564 mem# 0: /home/oracle/oracle/oradata/steel/redo02.log
Thread 1 cannot allocate new log, sequence 565
Checkpoint not complete
  Current log# 2 seq# 564 mem# 0: /home/oracle/oracle/oradata/steel/redo02.log
Thread 1 advanced to log sequence 565
  Current log# 3 seq# 565 mem# 0: /home/oracle/oracle/oradata/steel/redo03.log
Wed May 18 10:51:44 2011

原因和后果：当日志将被重用的时候，该日志上涉及的数据的checkpoint必须完成，否则这个时候server crash就丢失数据了。简单来说就是没有写入数据文件，日志又被覆盖了！这是日志组已经使用轮循了一圈的时候发生的事情，可以增加日志组和增大日志文件，当然也可以修改 checkpoint参数使得检查点变频繁一些。

这个主题使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、后面的进程需要1/4个db_block_buffer参数的大小；
2、每三秒；
3、当一个checkpoint产生。

一个checkpoint有5中事件类型：
1、每次重做日志的切换；
2、LOG_CHECKPOINT_TIMEOUT 这个延迟参数的到达；
3、相应字节(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)被写到当前的重做日志；
IO OS blocks: 在UNIX下可以 # fstyp -v /dev/vg00/lvol1
vxfs
version: 5
f_bsize: 8192
4、ALTER SYSTEM SWITCH LOGFILE 这个命令会直接导致checkpoint发生
5、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。

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

refer：http://zhaoyu728.itpub.net/post/5364/293141