关于fast_start_io_target，log_checkpoint_interval，log_checkpoint_time的一点看法

rrstpit

首先明确几个概念：
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

fanfdp

一篇好文章，讲的不错。

aaahhh

有一点不太准确
fast_start_io_target 的单位是io的次数， 不是block数。

redear

“假如datablock中的数据很小，比如1，修改成2，那么10000个redo block中包含的信息却可以是远远大于10000个data block，假如data block中的数据很大，比如123456789，修改成987654321，那么10000个redo block中包含的信息却可以是远远小于10000个data block。”

能否解释一下这句话？既然一个DATA BLOCK 包含几个OS BLOCK（在REDO FILE里，OS BLOCK=REDO BLOCK）， 怎么还会出现REDO BLOCK数 > DATA BLOCK数？

jaunt

从tahiti.oracle.com上看到的一些说法，看来这个地方可能会有一些疑惑。
------------------------------------------------------------------
http://download-west.oracle.com/ ... 5/c28recov.htm#9480

Fast-Start Checkpointing:
Fast-start checkpointing records the position in the redo thread (log) from which crash or instance recovery would need to begin. This position is determined by the oldest dirty buffer in the buffer cache. Each DBWn process continually writes buffers to disk to advance the checkpoint position, with minimal or no overhead during normal processing. Fast-start checkpointing improves the performance of crash and instance recovery, but not media recovery.

You can influence recovery performance for situations where there are stringent limitations on the duration of crash or instance recovery. The time required for crash or instance recovery is roughly proportional to the number of data blocks that need to be read or written during the roll forward phase. You can specify a limit, or bound, on the number of data blocks that will need to be processed during roll forward. The Oracle server automatically adjusts the checkpoint write rate to meet the specified roll-forward bound while issuing the minimum number of writes.

You can set the dynamic initialization parameter FAST_START_IO_TARGET to limit the number of blocks that need to be read for crash or instance recovery.[/COLOR] Smaller values of this parameter impose higher overhead during normal processing because more buffers have to be written. On the other hand, the smaller the value of this parameter, the better the recovery performance, since fewer blocks need to be recovered. The dynamic initialization parameters LOG_CHECKPOINT_INTERVAL and LOG_CHECKPOINT_TIMEOUT also influence Fast-Start Checkpointing.

------------------------------------------------------------------
http://download-west.oracle.com/ ... tatem19.htm#2054127

The FAST_START_IO_TARGET determines the target number of I/Os (reads and writes) to and from buffer cache that Oracle should perform upon crash or instance recovery.[/COLOR] Oracle continuously calculates the actual number of I/Os that would be needed for recovery and compares that number against the target. If the actual number is greater than the target, Oracle attempts to write additional dirty buffers to advance the checkpoint, while minimizing the affect on performance.

------------------------------------------------------------------
http://download-west.oracle.com/ ... chx_inst.htm#438086

Using FAST_START_IO_TARGET

Set this parameter to n, where n is an integer limiting to n the number of buffers that Oracle processes during crash or instance recovery.[/COLOR] Because the number of I/Os to be processed during recovery correlates closely to the duration of recovery, the FAST_START_IO_TARGET parameter gives you the most precise control over the duration of recovery.

FAST_START_IO_TARGET advances the checkpoint, because DBWn uses the value of FAST_START_IO_TARGET to determine how much writing to do. Assuming that users are making many updates to the database, a low value for this parameter forces DBWn to write changed buffers to disk. As the changed buffers are written to disk, the checkpoint advances.

The smaller the value of FAST_START_IO_TARGET, the better the recovery performance, because fewer blocks require recovery. If you use smaller values for this parameter, however, then you impose higher overhead during normal processing, because DBWn must write more buffers to disk more frequently.

------------------------------------------------------------------
http://download-west.oracle.com/ ... 2/ch20_io.htm#16021

Fast-Start Checkpointing:
The fast-start checkpointing feature limits the number of dirty buffers and thereby limits the amount of time required for instance recovery. If Oracle must process an excessive number of I/O operations to perform instance recovery, then performance can be adversely affected. You can control this overhead by setting an appropriate value for the parameter FAST_START_IO_TARGET.

FAST_START_IO_TARGET limits the number of I/O operations that Oracle should allow for instance recovery.[/COLOR] If the number of operations required for recovery at any point in time exceeds this limit, then Oracle writes dirty buffers to disk until the number of I/O operations needed for instance recovery is reduced to the limit set by FAST_START_IO_TARGET.

You can control the duration of instance recovery, because the number of operations required to recover indicates how much time this process takes. Disable this aspect of checkpointing by setting FAST_START_IO_TARGET to zero (0).

redear

斑竹调用的文档仅说明FAST_START_IO_TARGET 的功能。但这个参数在数据库执行RECOVER时，究竟如何调用OS块的呢？

望高手指点迷津。

biti_rainy

主张使用 fast_start_mttr_target           代替其他参数
该参数定义了 崩溃恢复的最长时间（单位为  秒 ），oracle将根据系统性能等因素综合起来自动决定什么时候发生检查点


至于 FAST_START_IO_TARGET  ,不要考虑恢复的时候怎么样调用block，该参数实际上是一个 检查点 的触发点，正因为检查点的触发 导致 dbwr写数据文件  和ckpt的更新数据文件头和控制文件，才决定了崩溃恢复的时候的最多不超过这个数目的block数

在恢复的时候，本身不会使用这个参数

biti_rainy

比如1，修改成2，那么10000个redo block中包含的信息却可以是远远大于10000个data block，假如data block中的数据很大，比如123456789，修改成987654321，那么10000个redo block中包含的信息却可以是远远小于10000个data block

楼主的这个例子是很不恰当的，不应该用数字的大小来做例子，应该说
比如在同一个表的10000  blocks 里面更新 10000条记录（每个block一条）  和在 1000blocks里面更新10000条记录（每个block十条），他们所产生的日志大致相当，但是同样的大致相当的日志量，在恢复的时候所更改的 blocks 却有10倍的差异，而oracle最小的 IO 单位是 block ，所以可能导致 IO 相差10倍，所以不准确。所以产生了 fast_start_io_target    来从另外一个角度控制

redear

多谢！！！

zhangzhenkai

不错的。