热衷技术，热爱交流
分类： Oracle
2013-05-07 21:58:01
前面简单讨论了完全检查点和增量检查点。究竟是多长时间发生一次检查点呢，每次需要写入多少buffer cache块呢？
对完全检查点，一般是一次把所有的buffer cache全部写完。间隔如下（仅看自动执行的）；
1. Buffer cache中脏数据达到40%；
2. 检查点跨度达到最小重做日志大小的90%；
对于增量检查点，是如何进行的呢：
增量检查点可以通过Fast-Start Checkping特性来实现：
Oracle 8i以前是通过参数log_checkpoint_interval和log_checkpoint_timeout
由于log_checkpoint_interval(根据重做日志量)和log_checkpoint_timeout（时间间隔）参数都有其局限性，于是oracle8i通过Fast-Start Checkping引入fast_start_io_target，这个参数用于控制发生crash时候恢复需要的I/O数量。例如，假设操作系统的I/O为每秒100（表示100个扇区，每个扇区一般512bytes）。如果要求数据库在5分钟内恢复，那么共需要产生的IO数量是5*60*1000=3000。可见，当操作系统每秒的IO增大，如果需要恢复的时间不变，我们就可以把这个变小。当然，系统性能改善了，fast_start_io_target不变的话，恢复的时间会变短。
Oracle 9i引入了fast_start_mttr_target参数（废弃了fast_start_io_target），替换8i中的fast_start_io_target。这个参数很简单，表示实例crash时候，需要recovery instance的时间。默认这个参数0，表示禁用Fast-Start Checkping特性。 以11g为例，以下是默认状态：
SYS AS SYSDBA >show parameter fast_;
NAME
|TYPE |VALUE
------------------------------------|-----------|------------------------------
fast_start_io_target
|integer |0
fast_start_mttr_target
|integer |0
fast_start_parallel_rollback
|string |LOW
SYS AS SYSDBA >show parameter log_checkpoint;
NAME
|TYPE
|VALUE
------------------------------------|-----------|------------------------------
log_checkpoint_interval
|integer |0
log_checkpoint_timeout
|integer |1800
log_checkpoints_to_alert
|boolean |FALSE
如果fast_start_io_target or log_checkpoint_interval 或者被指定，他们会自动覆盖由fast_start_mttr_target参数计算出来的值。
我们可以通过禁用log_checkpoint_interval， log_checkpoint_timeout，开启fast_start_mttr_target参数应用这一特性。
首先，确认参数statistics_level（参数值为all或者typical，才能可以进行建议视图的统计）
SYS AS SYSDBA >show parameter statistics_level;
NAME |TYPE |VALUE
------------------------------------|-----------|------------------------------
statistics_level |string |TYPICAL
禁用11g默认的参数:log_checkpoint_timeout(默认1800s)
SYS AS SYSDBA >alter system set log_checkpoint_timeout=0 scope=memory;
设置fast_start_mttr_target。fast_start_mttr_target一般为0~3600。太大恢复时间较长，太小IO太过频繁，可以通过系统负载以及系统性能设置这个参数值。综合系统性能，负载，重做日志块，buffer cache数量，以及这个参数的设置，oracle可以自动决定在什么时候执行增量检查点，一次需要写出多少buffer cache。
1, 设置fast_start_mttr_target=1为下限1
alter system set fast_start_mttr_target=1 scope=memory;
3. 查看实例恢复视图：
select RECOVERY_ESTIMATED_IOS,
FAST_START_IO_TARGET_REDO_BLKS,
TARGET_MTTR tmttr,
ESTIMATED_MTTR emttr,
CKPT_BLOCK_WRITES cbw,
ESTD_CLUSTER_AVAILABLE_TIME
from v$instance_recovery;
RECOVERY_ESTIMATED_IOS|FAST_START_IO_TARGET_REDO_BLKS| TMTTR| EMTTR| CBW|ESTD_CLUSTER_AVAILABLE_TIME
----------------------|------------------------------|----------|----------|----------|---------------------------
48| | 35| 29| 2595|
虽然fast_start_mttr_target设置成了1，但是这个视图的TARGET_MTTR值仍然显示，系统启动需要35s，因为系统打开数据库还需要读取各种文件，自然要费更多的时间。
4. 执行事务，继续观察ESTIMATED_MTTR和TARGET_MTTR
begin
for i in 0 .. 100
loop
insert into huangxing.test select * from dba_objects;
end loop;
end;
再次查看视图，由于在不断写出脏数据，可以看到ESTIMATED_MTTR实际已经高于TARGET_MTTR。这个是因为产生了太多的脏块，自然估计恢复时间的就要高于TARGET_MTTR。
select RECOVERY_ESTIMATED_IOS,
FAST_START_IO_TARGET_REDO_BLKS,
TARGET_MTTR tmttr,
ESTIMATED_MTTR emttr,
CKPT_BLOCK_WRITES cbw,
ESTD_CLUSTER_AVAILABLE_TIME
from v$instance_recovery;
RECOVERY_ESTIMATED_IOS|FAST_START_IO_TARGET_REDO_BLKS| TMTTR| EMTTR| CBW|ESTD_CLUSTER_AVAILABLE_TIME
----------------------|------------------------------|----------|----------|----------|---------------------------
2585| | 35| 38| 2699|
使用常规检查点把脏数据全部写出，我们看到，又回到了最开始之前的状态了（不一定完全一致）：
SYS AS SYSDBA >alter system checkpoint;
select RECOVERY_ESTIMATED_IOS,
FAST_START_IO_TARGET_REDO_BLKS,
TARGET_MTTR tmttr,
ESTIMATED_MTTR emttr,
CKPT_BLOCK_WRITES cbw,
ESTD_CLUSTER_AVAILABLE_TIME
from v$instance_recovery;
RECOVERY_ESTIMATED_IOS|FAST_START_IO_TARGET_REDO_BLKS| TMTTR| EMTTR| CBW|ESTD_CLUSTER_AVAILABLE_TIME
----------------------|------------------------------|----------|----------|----------|---------------------------
0| | 35| 29| 2873|
5. 设置fast_start_mttr_target为上限3600，
alter system set fast_start_mttr_target=3600 scope=memory;
提交与之前相同事务，可以看到，视图记录的实例恢复时间和估计恢复时间并不是那么高
提交事务的时候，如果频繁切换重做日志，发生了常规检查点，这会使得emttr上升并没有那么快
RECOVERY_ESTIMATED_IOS|FAST_START_IO_TARGET_REDO_BLKS| TMTTR| EMTTR| CBW|ESTD_CLUSTER_AVAILABLE_TIME
----------------------|------------------------------|----------|----------|----------|---------------------------
2869| | 51| 47| 2916|
如果当前重做日志文件很大，没有发生日志切换，不会发生完全检查点，那么emttr最终也是会超过tmttr的。超过与否实际取决于还有多少脏数据需要写出。
于是，讨论了两个极端后，我们就可以得到一个较为均衡的数值
需要注意的事，TMTTR数值的确定，应该是在连续考察系统运行状态后决定的。长时间运行生成的MTTR建议视图更具参考意义：
看看这段时间生成的建议视图
select MTTR_TARGET_FOR_ESTIMATE,ADVICe_status,DIRTY_LIMIT,ESTD_CACHE_WRITES,ESTD_TOTAL_WRITES,ESTD_TOTAL_IOS from v$mttr_target_advice;
MTTR_TARGET_FOR_ESTIMATE|ADVIC|DIRTY_LIMIT|ESTD_CACHE_WRITES|ESTD_TOTAL_WRITES|ESTD_TOTAL_IOS
------------------------|-----|-----------|-----------------|-----------------|--------------
57|ON | 6792| 259998| 259998| 488743
46|ON | 4050| 259998| 259998| 488743
68|ON | 9534| 259998| 259998| 488743
80|ON | 11422| 259998| 259998| 488743
36|ON | 1309| 260381| 260381| 489126
