管理oracle日志之调整检查点

• 检查点事件代表在那个时刻数据库处于一致的状态，检查点之所以重要，是因为在实例失败后，只有发生在最后一个检查点之后事务需要恢复；有两种类型的检查点：增量检查点和完全检查点；
• 增量检查点是从ORACLE 8开始引入的，之前的版本只存在完全检查点，这个时候，所有的脏数据都要写回磁盘，巨大的I/O对系统性带来很大影响，而且在写出所有脏块的过程中会锁定数据缓存，写出完成之前再不能够产生新的脏块；和增量检查点相关的一个新的结构是检查点队列，这个队列中存放了所有按low RBA(第一次对此块修改对应的Redo Block Address)排序的脏块，每三秒，增量检查点去更新控制文件，记录当前检查点队列的最小的low RBA以及on-disk RBA(LGWR进程已经写入到日志文件的最后的日志位置)等信息，实例恢复的时候将从控制文件的low RBA开始，而不是从数据文件的Checkpoint SCN开始；
• 完全检查点发生时，会执行下面的动作：
Ø 通知DBWn进程将所有的脏块写回磁盘；
Ø DBWn在写出脏块时如果发现对应的日志还在日志缓冲区，就触发LGWR写出日志条；
Ø 检查点进程更新控制文件和数据文件头；
• 检查点的触发条件有下面一些：
Ø 实例关闭（ABORT方式除外）；
Ø 日志切换；
Ø 用户触发：Alter System Checkpoint; Alter Tablespace … Begin Backup;
Ø 初始参数FAST_START_MTTR_TARGET指定的值已超过（增量检查点）；
Ø 日志文件长度的90%（增量检查点）；
Ø 每三秒（增量检查点）；
• 完全检查点发生时，必须等到要求DBWn完成的任务完成后，检查点才能结束，增量检查点（FAST_START_MTTR_TARGET以及日志文件长度的90%）也会去建议DBWn应该尽快完成的任务，但不会强制触发DBWn，更不会等待其完成（看http://asktom.oracle.com/pls/ask/f?...372 后的理解）；
• 监控检查点的活动很重要，因为太多的检查点会增加不必要的I/O，太少的检查点会使数据库在实例恢复时经历过长的时间；
• 测量检查点性能有下面一些方法：
Ø Select n.Name, Se.Total_Waits, Se.Average_Wait
From V$system_Event Se, V$event_Name n
Where n.Name = Se.Event(+)
And n.Name In
('checkpoint completed', 'log file switch (checkpoint incomplete)');

checkpoint completed等待检查点的完成;
log file switch (checkpoint incomplete) 如果紧接着的一个日志切换检查点发生，前面日志切换检查点尚未完成，这时，前面的检查点会终止，后面的检查点得从头再来，导致更多的I/O操作却不能缩短实例恢复的时间；
Ø Select *
From V$sysstat
Where Name In
('background checkpoints started', 'background checkpoints completed')；

background checkpoints started 自实例启动以来开始过的检查点；
background checkpoints completed自实例启动以来已经成功完成的检查点；
这两个值的差异值或者差异值减一等于未完成的日志切换检查点；
Ø Statspack中与检查点性能相关的数据有：实例活动统计（Instance Activity Stats）的background checkpoints started 和background checkpoints completed；
Ø 当出现日志切换检查点未完成事件时，报警日志文件中会有记录，大致的描述如下：Thread x cannot allocate new log, sequence y Checkpoint not complete;
Ø 初始参数LOG_CHECKPOINTS_TO_ALERT置为TRUE时，每一个检查点的性息都可以在报警日志文件中找到；
• 调整检查点性能有下面两种方法（加大日志文件，调整初始参数）：
Ø 每个日志切换时会发生完全检查点，加大日志文件可以使检查点的间隔更大些，以减少检查点未完成这个事件发生频率；

Ø 增大日志文件方法是，先增加新的更大日志文件组，再删除小的日志文件组；
Ø 为了在实例恢复性能以及检查点活动负担间达到平衡，调整日志文件大小，使日志切换的发生间隔在20到30分钟之间为宜；
Ø 在9i中，ORACLE建议只需调整FAST_START_MTTR_TARGET这个参数，含义是实例失败时的平均恢复时间（秒），取值范围为0~3600，这个参数可以用Alter System语句动态改变，为零时取消这个功能，这个参数通常是用另两个参数来实现的：FAST_START_IO_TARGET（实例失败时的平均赃块数）, LOG_CHECKPOINT_INTERVAL（实例失败时的平均日志OS块数）；
Ø 设置上面的参数后，可以用V$INSTANCE_RECOVERY这个视图观察效果：TARGET_MTTR（平均恢复时间，通常等于上面参数指定的值，如果因为服务器资源的限制可能稍大于上面的参数值） ESTIMATED_MTTR（评估的当前时刻实例失败后的恢复用时）；

 

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

转载于:http://blog.itpub.net/13024285/viewspace-628850/