MTTR平均恢复时间

由于实例恢复需要耗费大量的时间执行前滚和回滚操作，CKPT进程会把系统变更号（SCN）写入到控制文件和数据文件头。SMON就从上一个检查点位置开始执行重做。所以，检查点位置越近，实例恢复就越快。但是频繁地检查点，意味着频繁地将脏块写入磁盘，这也会导致I/O消耗增加，而另一方面，不频繁的检查点，会造成数据库崩溃后实例恢复时间会增加（MTTR）。在数据库版本9i以后，引入了FAST_START_MTTR_TARGET参数，此参数值越小，意味着检查点越近，脏数据写入磁盘越频繁。V$INSTANCE_RECOVERY可以获得建议值。

       FAST_START_MTTR_TARGET默认值是0，发生故障后实例恢复所需要大量的恢复时间，但是性能却是最好的。

检查点

检查点分为三类：完全检查点，增量检查点，局部检查点。

完全检查点：只有在数据库有序关闭:（shutdown normal,shutdown immediate,shutdown transactional），执行完全检查点（alter system checkpoint）时才会发生完全检查点，切换redo日志时。buffer cache中的所有脏数据会写入磁盘

增量检查点：在一般情况下（非完全检查点的两种情况），ckpt写入检查点到控制文件和数据文件头时使用使用的是增量检查点。增量检查点一次只会使脏缓冲区中的部分数据写入磁盘，而不是全部。这也会减少性能消耗。

局部检查点：对于某些操作（如：表空间offline，截断表等）需要局部检查点，局部检查点只会刷新其操作部分影响的块。

checkpoint not complete

问题描述：

告警日志中出现checkpoint not complete的问题

问题原因：

前面提到CKPT进程就是实际做检查点的进程，其中一项检查点触发条件就是切换日志redo log switch

　 　当状态为current的redo log写满之后，Oracle就要停止使用当前的redo log，转而使用另一组状态为inactive的redo log，这就叫做redo log switch。

假设我们只有两个redo log group：group 1和group 2，并且系统中总是有大量的脏数据需要写入磁盘中，当我们从group 1 switch to group 2的时候，会触发checkpoint。然而，当我们再次用完group 2里面的空间，需要再次switch to group 1并重用group 1的时候，发现group1 的redo log状态为active），日志还没有被写入归档或者在等待buffer cache中的脏数据写入磁盘，因为必须保持数据库的一致性，数据库必须等待group 1的状态切换为inactive，这就是checkpoint not complete的问题。可以说ckpt对于保证数据库的一致性是非常重要的。

解决方法：这个问题说明了redo log的配置有问题，解决方法如下

1.    增大redo log

例：

Alter database add logfile group 3 ('路径1 /redolog03_1.log', '路径2/ redolog03_2.log ') SIZE 1024M;

Alter system switch log file;

当磁盘组为inactive时，删除陈旧redolog组

alter database drop logfile group 1；

2.    增加redo log group数量。