oracle 查看自增队列,oracle 检查点队列 & 增量检查点

就像上图，检查点队列的每个节点，都保存有脏块的地址和脏块对应的重做记录的编号。脏块在Buffer cache中的位置是随机的，用户不一定修改那个块。但重做记录是顺序生成的，就和检查点队列的排列顺序一样。因为，它们都是当块被修改而变脏时产生的。块A先被修改，块A的重做记录就排在前面，块B后被修改，块B对应的重做记录会被排在块A对应的重做记录的后面。和它们在检查点中的顺序是一样。每当数据库因异外而当机，比如异常死机、断电等等，Buffer cache中有许多脏块没来的及写到磁盘上。以图为例，比如说现在断电了，现在磁盘上还有7个脏块，它们里面有用户修改过的数据，Oracle已经将反馈信息“你的修改完成”发送给用户，用户也以为他们的修改完成了，将为一直保存到数据库中。但是，断然的断电，令这几个脏块中的数据丢失了，它们没来得及写到磁盘上。

Oracle如何解决这个问题呢？很简单，当数据库重新启动时，Oracle只需从控制文件中读出检查点位置，检查点位置中记录有重做记录编号，根据此编号，Oracle可以很快的定位到日志文件中的重做记录n，它读出重做记录n中的重做数据，将用户的修改操作重现到数据库。接着，Oracle读取重做记录n+1中的重做数据，重现用户修改，这个过程将沿着日志流的顺序，一直进行下去，直挡最后一条重做记录，在上图的例子中，最后一条重做记录是第n+6条。这个过程完成后，用户所有的修改又都被重现了，一点都不会丢失。只要你的日志文件是完整，日志流是完整的，就一点信息都不会丢失。

有人可能会有一个问题，重做记录在生成后，也是先被送进重做缓存，再由重做缓存写往日志文件。这样的机制下，一定会有某些重做记录在没来的及写到日志文件中时，数据库突然当机，而造成这些重做记录丢失。这样，这些重做记录所对应的脏块，将得不到恢复。用户还是会丢失一些数据。

这种情况的确会发生，但丢失的都是没用的信息。为什么这么说的。Oracle会在用户每次发出提交命令时，将事务所修改脏块对应的重做记录写进日志文件，只有当这个操作完成时，用户才会收到“提交完成”，这样的信息，对于一个完整的事务，当用户看到提交完成后，也就意味着所对应的重做记录一定被写到了日志文件中，即使发生异常死机，它也是绝对可以恢复。而当用户没有提交，或没来得及提交，数据库就崩溃了，那么事务就是不完整的，这个事务必须被回滚，它根本用不着恢复。对于这样不完整的事务，它对应的重做记录有可能丢失，但这无所谓了，因为不完整的事务根本不需要恢复。也就是说，只有用户的事务提交了，用户的修改一定不会丢失。不过这还有一个前提，就是日志文件千万不能损坏，DBA所要做的就是要保证日志文件不能损坏。DBA可以使用RAID1这样的磁盘镜像技术，或者多元备份日志文件，等等，这个我们在前面章节中已经讲过了的。

我们上面所讲到的这种恢复，是自动进行的，并且不需要DBA参与，它被称之为实例恢复。

检查点队列与增量检查点的作用我们已经说的差不多了，它们的主要目的就是让DBWn沿检查点队列的顺序刷新脏块。还有，就是实例恢复。

下面我们来讨论一下增量检查点的设置

这里所说的检查点设置，主要指增量检查点频繁的设置。注意增量检查点只是一个名词，不必按字面的意义去理解它。增量检查点发生时，Oracle会唤醒DBWn沿着检查点队列写脏块，这就是增量检查点。那么到底多长时间一次发生一次增量检查点呢？这个增量检查点的频率是非常重要的，它基本上控制着DBWn多长时间去刷新一次脏块。DBWn活动的太频繁，会影响数据库的整体性能，如果DBWn活动太不频繁，又会使脏块挤压太多，这同样也会影响性能。而且，如果出现异常崩溃，需要实例恢复，脏块越多，实例恢复越慢。。在9i之前DBA主要靠间隔时间等方式来设置增量检查点的频率，比如可以让Oracle每10分钟发生一次增量检查点。如果这个数字设置不合适，对数据库性能的影响是很大的。而且有可能造成实例恢复时间过长。在9i之后，特别是到了10g中，检查点已经相当的智能化了，很少会成为I/O问题的原凶。9i中设置fast_start_mttr_target参数为你所期望的实例恢复时间，系统将自动控制增量检查点的频率。比如，你希望实例恢复可以在5分钟内完成，你可以将此参数设置为300，也就是300称。

如果此参数设置的值超出了硬件实际的限制，比如你将它设置为60，你期望无论在任何情况下，数据库都可以在1分钟内完成实例恢复，但根据数据库的脏块生成速度、存储设备的写性能，1分钟内根本无法完成实例恢复。这时候Oracle会自动设置合适的fast_start_mttr_target参数值，我们可以在参数文件中看到修正后的参数值，也可以在V$instance_recovery视图中的Target_mttr列中看到实际的值。例如：

(举个例子)

我们不能将这个值设置的太小，因为实例恢复必竞只是偶然现象。如果为了让实例恢复尽快完成，而设置fast_start_mttr_target为很小的值，那么DBWn将活动的很频繁，这会造成性能问题的。为了避免用户设置不合理的增量检查点频率，在10G中，如果将fast_start_mttr_target设置为0，Oracle将根据产生脏块的速度、存贮硬件的性能自动调节检查点的频率，尽量使检查点频率不成为I/O问题的原凶。

检查点的主要任务就是催促DBWn刷新脏块，如果DBWn刷新脏块时的等待事件太多，就说明脏块太多、存储设备的写速度太慢，或者就是增量检查点的频率太高了，或太低了。DBWn写脏块的等待事件是Db file parallel write。如果你的增量检查点频率很低，你发现了此事件，在排除了存储设备写性能的问题后，你应该将增量检查点频率设置的高一些。反之，如果你的增量检查点频率本身很高，出现了Db file parallel write事件，这说明检查点频率太高了。

除它之外，还有一个和DBWn、增量检查眯有关的等待事件，它是Write complete waits事件，当前台进程要修改DBWn正要成批写的块中的若干个块时，就会有此等待事件，这个事件是前台进程再等待DBWn写完成。这个等待事太多，说明了存储设备写性能有问题，或者增量检查点太频率了。

我们可以V$instance_recovery中看到有关检查点的很多信息：

Estimated_mttr列如果太大，说明检查点不够频繁，同时也说明脏块产生的太多。同时在V$sysstat资料视图中，还有两个资料background checkpoints started、background checkpoints completed，前面的一个是后台进程检查点开始次数，后一个是后台进程检查点完成次数。后台进程检查点的意义，其实就是增量检查点。只有增量检查点是由后台进程触发的。如果你用Alter system checkpoing命令让系统完成完全检查点，这叫做前台检查点与增量检查点无关，是不会被记入这两个资料了。如果这两个值经常相差一些，比如检查点的开始次数比完成次数大的不至1，这说明有太多次检查点开始，但没有及时完成。这说明检查点太频繁或检查点完成的太慢(eg:select * from v$sysstat where name like 'background checkpoints%';)。

(举例，大量的产生脏块、日志文件比较小5MB，日志文件频率的切换而触发检查点，同时查看一下等待事件)

检查点的问题大多数情况下其实都是DBWn写I/O的问题， DBWn写脏块的等待事件是Db file parallel write，还有Write complete waits等待事件，是当前台进程要修改DBWn正要成批写的块中的若干个块时，就会有此等待事件，这个事件是前台进程再等待DBWn写完成。这个等待事太多，也说明了DBWn有问题。

注意，对于数据文件的I/O问题，除了等待事件外，我们还可以用上几节讲过了V$filestat视图帮助确定问题。)