oracle基础--检查点设置

         1 前序

         ① 检查点在数据库遭到实例崩溃的恢复阶段有这很重要的意义，我们知道当数据库实例在不完整关闭，或遭遇断电，宕机等危险因数的情况下 ，实例会处于不一致的状态，（归档日志文件中的变更向量，和数据文件中记录不一致。。。已提交的事务，，数据变更没有写入磁盘上的数据文件， 【注意 commit  提交只对 lgwr  日志写入进程有影响】 ） 

② 那么检查点的设置在实例恢复中具体起到了什么作用呢？？

     首先我们应该清楚的是： 检查点保证了在每个特定的时间， 数据写入进程 dbwn   将一个特定的系统更改号的所有数据都写入数据文件，，

     当实例已经崩溃，，尝试重新启动实例的时候smon 进程 需要将上一检查点位置开始生成的所有重做构建事务，检查点之前的生成的全部变更已经写入数据文件  ，是不              需要重新再构建事务的，而构建事务需要回滚的数据已经写入磁盘上的撤销段中，   那很明显检查点越靠前，实例恢复的也就越快，

    但是是不是检查点设置的 越靠前就越好呢？？  这个是需要考虑的，  设置的检查点位置越靠前，，就表明需要设置更多，时间间隔越短，，那在设置检查点的时候，， dbwn' 进程会将数据库缓冲区缓存中的脏数据块写入磁盘上的数据文件， 这会引起磁盘io过多 ， 和cpu 内存占用， 简而言之就是会影响性能嘛，，  会影响服务器进程对实例的处理。

那应该设立较少的检查点吗？ 也不是的，如果设置的检查点较少，scn 位置就靠后，smon 进程在实例恢复的时候就需要执行很多次的读写操作，平均恢复时间mttr 显而易见的就会很长，，这对于业务来说是灾难性的，所以要均衡检查点的设置。

       2 怎样设置检查点呢？？

可以通过参数  fast_start_mttr_target    去控制，，可以设置目标恢复时间（以秒为单位）   oracle  自身会 根据这个参数 dbwn 进程对数据块对数据文件的写入，，以便在数据实例崩溃的时候能够在目标时间内恢复实例。 但是要注意的是，如果设置的目标时间过小，那么oracle 是不会达到这个目标时间的，，

        3检查点概述：

  ① 检查点分类： 增量检查点（由dbwn 数据写入进程自动前移）  、 完整检查点、 局部检查点。

  ② 完整检查点： 将所有的脏缓冲区中的块写入数据文件。缺点是需要非常大的磁盘使用率和cpu使用率   ， 因而只有在两种情况下才能执行完整检查点： 有序关闭数据库实例（normal  transactional   immediate ）、 特定要求。

  ③ 强制执行检查点 altter  system  checkpoint;

  ⑤ 局部检查点:  局部检查点影响的缓冲区因操作而不同：

使表空间脱机： 表空间中所有的块。

使数据文件脱机： 数据文件中的所有块。

删除区间：  区间中的所有块。

截断表：      表中的所有块。

将表空间置于备份模式：  表空间中所有的块。