关于fast_start_io_target的一点看法

　　首先明确几个概念：
　　
　　1．Data block 是包含几个os block，也就是一对多的关系。
　　
　　2．Data files 中的是 data block
　　Redo log files 中的 redo block 是os block
　　
　　3．Data block 中记录的是完整的信息
　　
　　Redo block 中记录的是最简单的信息
　　
　　在8i 以前的版本，只有两个参数用来影响recovery，那就是log_checkpoint_interval和log_checkpoint_time。以log_checkpoint_interval=10000举例。意思很简单，就是经过10000个redo block后就引发checkpoint,这样恢复时，就绝对是在这10000个redo block中。
　　
　　但是这样做有个缺点，就是因为redo block（os block）不等于data block。假如datablock中的数据很小，比如1，修改成2，那么10000个redo block中包含的信息却可以是远远大于10000个data block，假如data block中的数据很大，比如123456789，修改成987654321，那么10000个redo block中包含的信息却可以是远远小于10000个data block。
　　
　　这样，在恢复时，尽管是读10000个redo blcok，但是这个10000个redo block中所包含的data block有可能是很少，也有可能是很多，很难把握恢复的时间。
　　
　　于是，在8i中就引进了fast_start_io_target这个参数来弥补这个不足。计算机自动计算redo block中所包含的data block的多少。例如fast_start_io_target=10000，t1（第一次checkpoint），在t1后有5000个redo block记录了，但是这个5000个redo block中只包含了7000个data block，那么redo block继续记录，到了redo block到8000个时，计算机发现这8000个redo block中包含了10000个data block，那么就引起t2（第二次checkpoint），凡是在t1和t2之间的任何crash，都可以保证recovery的时间肯定在这10000个data block的读写时间之内（因为1个data block的I/O 是可以估算的）
　　
　　所以说，设置fast_start_io_target比设置log_checkpoint_interval，log_checkpoint_time这个两个参数更为准确。假如3个参数一起设置，那么只要达到任一参数值时，就引发checkpoint。
　　
　　例如：fast_start_io_target=10000，log_checkpoint_interval=10000，log_checkpoint_time=1800。
　　
　　在redo block=10000时，所包含的data block却只有8000，就触发log_checkpoint_interval
　　
　　在redo block=8000时，所包含的data block 却有10000，就触发fast_start_io_target