CheckPoint

目的
-----
本文帮助DBA更好地理解增量检查点，checkpoint调优的相关参数信息：
 -  FAST_START_MTTR_TARGET
 -  LOG_CHECKPOINT_INTERVAL
 -  LOG_CHECKPOINT_TIMEOUT
 -  LOG_CHECKPOINTS_TO_ALERT
以及如何理解如何理解和操作ALERT LOG中的checkpoint错误：'Checkpoint not Complete'和'Cannot Allocate New Log'。

内容
-----
1.什么是Checkpoint？
2.checkpoint和性能
3.增量检查点的相关参数
4.Redo log和Checkpoint
5.理解Checkpoint错误信息('Checkpoint not Complete'和'Cannot Allocate New Log')
6.Oracle版本信息
7.利用Statspack定位Checkpoint问题

Checkpint调优及错误解决
================================

1.什么是Checkpoint？
--------------------
Checkpoint是一个将内存中被修改的数据块同步到磁盘上的数据文件的数据库事件，它提供了确保事务数据修改一致性的机制。在Oracle中，将修改块写到磁盘上的机制与相关事务的commit并不是同步的。
Checkpoint有2个目的：(1)确立数据的一致性，(2)确保更快的数据库恢复。如何更快地恢复？因为数据库中所有的变更，在checkpoint时都被记录数据文件中，在checkpoint之前的redo log记录被标记为不需要apply的。checkpoint必须确保cache中所有被修改的buffer已经被写入相应的数据文件中，从而避免发生crash(实例或磁盘错误)时的数据丢失。

当下列条件之一发生时，Oracle将脏数据写入磁盘：
 - 一个shadow进程必须要扫描超过4分之一的buffer cache
 - 每隔3秒
 - 当checkpoint发生时

checkpoint被以下5类事件触发：
 - 每次redo log切换时
 - 达到LOG_CHECKPOINT_TIMEOUT的延迟时
 - 大小符合：(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)被写入当前的redo log
 - ALTER SYSTEM SWITCH LOGFILE命令
 - ALTER SYSTEM CHECKPOINT命令
 
在checkpoint期间将发生以下事件：
 - 数据库写进程(DBWR)将cache中所有被修改的buffer已经被写入相应的数据文件中。
 - 检查点进程(CKPT)更新所有数据文件的文件头为最后一次发生的checkpoint的SCN。
 

2.checkpoint和性能
--------------------------
Checkpoint的调整处于矛盾的选择，频繁的checkpoint可以确保更快地恢复，但是也会导致性能下降。

依据数据库中数据文件的数量来决定checkpoint的频率，在checkpoint期间，所有的数据文件头都会被冻结，需要在checkpoint的频率中找到一个性能平衡点。频繁的checkpoint可以确保数据库在crash之后快速恢复。所以一些不能容许长时间停机的客户选择此方式。但是所带来的性能下降证明了该方式在多数系统中是不适合的。假设数据库系统95%的时间都在运行，只有5%的时间遭遇意外(如硬件错误)导致crash，需要恢复。对于大多数客户来说，确保95%运行时间内的性能，比加快5% crash的恢复时间，有意义得多。

 

本文假设性能是首选要素，按此建议定制方式。因此，目标是最小化checkpoint的频率调优。
调整checkpoint有4个相关的初始化参数
 -  FAST_START_MTTR_TARGET
 -  LOG_CHECKPOINT_INTERVAL
 -  LOG_CHECKPOINT_TIMEOUT
 -  LOG_CHECKPOINTS_TO_ALERT
 
这些参数将在后面讨论。
在alert log发现"checkpoint not complete"信息时，也同样需要考虑调整redo log和checkpoint。

3.增量检查点的相关参数
------------------------
注意：日志切换总是优于由以下参数造成的checkpoint。

 

•FAST_START_MTTR_TARGET

从Oracle9i开始FAST_START_MTTR_TARGET参数是调整checkpoint的首选方法。FAST_START_MTTR_TARGET参数在实例中用来制定crash之后数据库需要多少秒的时间进行恢复。基于内部的统计，增量检查点会自动调整checkpoint的频率接近FAST_START_MTTR_TARGET的设置。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR显示了评估出的当前平均恢复时间，单位是秒。即使不设置FAST_START_MTTR_TARGET，也会显示。
V$INSTANCE_RECOVERY.TARGET_MTTR显示系统设置的MTTR时间。
V$MTTR_TARGET_ADVICE显示了当前负载在当前MTTR设置下需要的IO数，以及估算出当前负载在其他MTTR设置下的需要的IO数。该视图用于评估FAST_START_MTTR_TARGET的设置，可以选择一个平衡点来设置。

•LOG_CHECKPOINT_INTERVAL

LOG_CHECKPOINT_INTERVAL参数指定了增量检查点允许当前log尾部滞后的最大数量的redo块数，redo block的大小是操作系统块大小，不是数据库块大小。
如果指定了FAST_START_MTTR_TARGET，LOG_CHECKPOINT_INTERVAL不应设置或设置为0。
在大多数操作系统中，块大小为512bytes。此类操作系统中，如果设置LOG_CHECKPOINT_INTERVAL值为10000，那么增量检查点不允许当前日志尾部滞后多余5M的内容，如果redo log是20M，每个日志将有4个检查点。
LOG_CHECKPOINT_INTERVAL影响checkpoint的发生，需要谨慎设置该参数，当redo log大小改变时，该参数也应该随之改变。当数据库从一个意外失败中恢复时，checkpoint的频率对于所需的恢复时间是一个关键要素。checkpoint间隔时间太长的，数据库恢复所需的时间也长。checkpoint间隔时间短，数据库恢复也快，但同时checkpoint也增加了资源开销。
该参数也影响数据库完全恢复时，前滚恢复阶段的时间。实际恢复时间依赖该时间，以及其他要素，如失败类型(实例或系统crash，介质错误等)，需要apply的归档日志数量。

•LOG_CHECKPOINT_TIMEOUT

LOG_CHECKPOINT_TIMEOUT参数指定了增量检查点允许的当前log尾部滞后的最大秒数。换句话说，它指定了buffer cache中脏数据的保留时间。
Oracle推荐使用LOG_CHECKPOINT_INTERVAL来控制checkpoint的间隔时间，更优于使用LOG_CHECKPOINT_TIMEOUT，因为LOG_CHECKPOINT_TIMEOUT设置了每隔"n"秒进行一次checkpoint，而不考虑事务的频率。在事务处理量变化时，可能导致不必要的checkpoint。应该避免出现不必要的checkpoint，以保证性能。
不要误解LOG_CHECKPOINT_TIMEOUT参数是用来设置日志切换的间隔时间，用于standby-by数据库中恢复窗口的设置。日志切换会触发checkpoint，但checkpoint不会触发日志切换。日志切换只有发生在手动执行ALTER SYSTEM SWITCH LOGFILE或者调整redo log大小引起更频繁的切换时发生，由操作系统块数量限制，而不是间隔时间。redo log的大小与性能和恢复都有密切，具体参见后面的Redo log和Checkpoint。

•LOG_CHECKPOINTS_TO_ALERT

LOG_CHECKPOINTS_TO_ALERT参数可以设置是否将checkpoint信息记录到alert log中，用来检查和checkpoint的频率。
在Oracle9i之前，该参数值为STATIC，Oracle建议将该参数设置为TRUE，其开销几乎可以忽略，但记录在alert log中的信息却是很有用的。

Note:76713.1有更多关于这些参数的信息。

4.Redo log和Checkpoint
------------------------
在每次日志切换时会触发checkpoint，如果前一个checkpoint已经在进行中，由日志切换触发的checkpoint会覆盖当前的checkpoint。
redo log的大小调整是很有必要的，可以去除那些由于日志切换触发的不必要的checkpoint。在增量检查点和日志尾部之间的滞后部分由最小在线日志文件大小的90%决定，这样确保了大多数情况中，日志切换不需要等待checkpoint。因为这样，日志文件大小需要设置得足够大。从经验来看，日志切换最好是每隔20分钟切换一次。如果日志文件太小，会增加checkpoint的活动，从而影响性能。Oracle建议设置所有的日志文件都一样大，每个线程至少2组日志。alert log中记录的日志切换的发生也是监控的一项有效手段。

 

下面这个例子中，日志切换得很频繁：
Fri May 16 17:15:43 1997
Thread 1 advanced to log sequence 1272
  Current log# 3 seq# 1272 mem# 0: /prod1/oradata/logs/redologs03.log
Thread 1 advanced to log sequence 1273
  Current log# 1 seq# 1273 mem# 0: /prod1/oradata/logs/redologs01.log
Fri May 16 17:17:25 1997
Thread 1 advanced to log sequence 1274
  Current log# 2 seq# 1274 mem# 0: /prod1/oradata/logs/redologs02.log
Thread 1 advanced to log sequence 1275
  Current log# 3 seq# 1275 mem# 0: /prod1/oradata/logs/redologs03.log
Fri May 16 17:20:51 1997
Thread 1 advanced to log sequence 1276
  Current log# 1 seq# 1276 mem# 0: /prod1/oradata/logs/redologs01.log

 

如果redo log每3分钟切换一次，可以感觉到性能明显下降。上面说明redo log不够大，不能有效地处理当前事务负载，需要增大redo log大小。

5.理解Checkpoint错误信息('Checkpoint not Complete'和'Cannot Allocate New Log')
-------------------------------------------------------------------------------
有时可以在alert log中看到如下一些信息：
  Thread 1 advanced to log sequence 248
    Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log
  Thread 1 cannot allocate new log, sequence 249
  Checkpoint not complete

 

该信息指出Oracle想要重用redo log，但是当前的checkpoint位置仍然在那个日志中。这种情况发生时，Oracle必须等待checkpoint通过那个日志。因为增量检查点不允许当前日志尾部滞后超过最小在线日志文件大小的90%，这种情况通常由于DBWR写得太慢，或者日志在还没有完全满之前切换，或者日志大小太小。
当数据库在等待checkpoint时，redo将停止产生，直到日志切换完成。

6.Oracle版本信息
-----------------
在Oracle8i中，参数FAST_START_IO_TARGET的设置，引起增量检查点的自动调整，需要恢复的数据块不多于FAST_START_IO_TARGET设置的值。该参数从9i开始不建议使用，取而代之的是FAST_START_MTTR_TARGET。

7.利用Statspack定位Checkpoint问题
----------------------------------
可以大约每隔15分钟收集一次Statspack快照，报告收集该时段内，checkpoint的次数、checkpoint期间写了多少数据库buffer。也包含了redo活跃的统计。收集和比较多份报告，掌握各个时段checkpoint的性能。
statspack报告中另一个值得关注的是等待事件，下面的等待事件较明显地指出redo log吞吐量已经checkpoint行为的问题。
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

 

如果上面的等待事件频繁地出现，相关的数值较高，那么可能需要考虑增加更多的redo log文件，或者增大它们的大小，修改checkpoint相关参数。