如果不考虑事务的完整性，是不是在SQL中的COMMIT越多性能越好？

伊斯力 · 发表于 2010-8-27 08:40

增量检查点

Oracle从8i开始引入了检查点队列这么一种概念，用于记录数据库里面当前所有的脏数据块的信息，DBWR根据这个队列而将脏数据块写入到数据文件中。检查点队列按时间先后记录着数据库里面脏数据块的信息，里面的条目包含RBA（Redo Block Address，重做日志里面用于标识检查点期间数据块在重做日志里面第一次发生更改的编号）和数据块的数据文件号和块号。在检查点期间不论数据块更改几次，它在检查点队列里面的位置始终保持不变，检查点队列也只会记录它最早的RBA，从而保证最早更改的数据块能够尽快写入。当DBWR将检查点队列里面的脏数据块写入到数据文件后，检查点的位置也要相应地往后移，CKPT每三秒会在控制文件中记录检查点的位置，以表示Instance Recovery时开始恢复的日志条目，这个概念称为检查点的“心跳”（heartbeat）。检查点位置发生变更后，Oracle里面通过4个参数用于控制检查点位置和最后的重做日志条目之间的距离。在这里面需要指出的是，多数人会将这4个参数看作控制增量检查点发生的时间。事实上这是错误的，这4个参数是用于控制检查点队列里面的条目数量，而不是控制检查点的发生。

（1、）fast_start_io_target

该参数用于表示数据库发生Instance Recovery的时候需要产生的IO总数，它通过v$filestat的AVGIOTIM来估算的。比如我们一个数据库在发生Instance Crash后需要在10分钟内恢复完毕，假定OS的IO每秒为500个，那么这个数据库发生Instance Recovery的时候大概将产生500*10*60=30,000次IO，也就是我们将可以把fast_start_io_target设置为 30000。

（2、）fast_start_mttr_target

我们从上面可以看到fast_start_io_target来估算检查点位置比较麻烦。Oracle为了简化这个概念，从9i开始引入了 fast_start_mttr_target这么一个参数，用于表示数据库发生Instance Recovery的时间，以秒为单位。这个参数我们从字面上也比较好理解，其中的mttr是mean time to recovery的简写，如上例中的情况我们可以将fast_start_mttr_target设置为600。当设置了 fast_start_mttr_target后，fast_start_io_target这个参数将不再生效，从9i后 fast_start_io_target这个参数被Oracle废除了。

（3、）log_checkpoint_timeout

该参数用于表示检查点位置和重做日志文件末尾之间的时间间隔，以秒为单位，默认情况下是1800秒。

（4、）log_checkpoint_interval

该参数是表示检查点位置和重做日志末尾的重做日志块的数量，以OS块表示。

（5、）90% OF SMALLEST REDO LOG

除了以上4个初始化参数外，Oracle内部事实上还将重做日志文件末尾前面90%的位置设为检查点位置。在每个重做日志中，这么几个参数指定的位置可能不尽相同，Oracle将离日志文件末尾最近的那个位置确认为检查点位置。

viadeazhu · 发表于 2010-8-27 09:18

commit不会强制checkpoint queue在此之前的都写回，其实checkpoint的速度是由oracle自行决定的。
能强制对全局或局部完全checkpoint的只有'alter system checkpoint;'或'alter tablespace read only'等。。

而commit必须保证的是在此之前，redo buffer必须写回redo log，这是oracle最基本的流程。
当然，你可以设置commit_write参数调整redo写回的性能。

我上面有人 · 发表于 2010-8-27 09:21

你没有理解我的意思！
我是说：大事务的commit跟redo几乎没有关系，是否hung只跟dbwr有关。

viadeazhu · 发表于 2010-8-27 09:34

设想一个场景，你的redo log是100MB一个，一共有三个，那就是300MB。

如果此时你做了一个大事务的update语句，其间会产生400MB的redo，那么当所有的redo log都用光的时候，请问你认为此时数据库没hung么？

尛样儿 · 发表于 2010-8-27 09:34

提交过于频繁
等待事件会出现
log file sync 和 log file parallel write等待事件。就是因为提交过于频繁，导致lgmr忙不过来而出现的等待。

我上面有人 · 发表于 2010-8-27 09:37

原帖由 viadeazhu 于 2010-8-27 09:34 发表
设想一个场景，你的redo log是100MB一个，一共有三个，那就是300MB。

如果此时你做了一个大事务的update语句，其间会产生400MB的redo，那么当所有的redo log都用光的时候，请问你认为此时数据库没hung么？

数据库hung是因为dbwr没有将脏数据写入datafile造成redo的状态为active，这跟你commit没有直接关系。你可以增加redo组，或增大redo，或者增加dbwr_writer，但绝不是靠commit能解决。