检查点与实例恢复

1.以system用户登录SQL*Plus。

 

2.禁用检查点调整功能。

 

 SQL>alter system set fast_start_mttr_target=0;

 

3.创建一个表和启动一个事务，从而模拟一个工作负荷。

 

  SQL>create table t1 as select * from all_objects where 1=2;

 

  where 1=2 恒为假，但是会输出查询表的所有列，单没有任何行，以上就创建了一个表建构。

 

  SQL>insert into t1 select * from all_objects;

 

4.运行如下查询，查看此时出现奔溃时的情况下恢复实例需要完成的工作。

 

SQL> select recovery_estimated_ios,actual_redo_blks,estimated_mttr from v$instance_recovery;

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR
---------------------- ---------------- --------------
                   101            12510             19

SQL>

 

  这个查询会显示实例恢复期间需要在数据文件上进行的读/写操作数以及必须处理的重做数据块，此外，estimated_mttr列显示了以秒为单位的实例恢复时间。

 

5.提交这个事务，然后重新执行上面的查询，看到变化不大，说明commit命令不会对DBWn进程产生影响，并且不会迁移检查点位置。

SQL> commit;

Commit complete.

SQL> select recovery_estimated_ios,actual_redo_blks,estimated_mttr from v$instance_recovery;

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR
---------------------- ---------------- --------------
                   106            12529             19

SQL>

 

6.手动执行检查点进程。

 

 SQL>alter system checkpoint;

 

 因为DBWn进程需要将所有变化的数据块都写至磁盘，所以这个操作将会在数秒中后结束。

 

7.重新执行上面的查询。

 

SQL> select recovery_estimated_ios,actual_redo_blks,estimated_mttr from v$instance_recovery;

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR
---------------------- ---------------- --------------
                     0                0             19

SQL>

  可以看到recovery_estimated_ios,actual_redo_blks被彻底清除（可能全部为零），ESTIMATED_MTTR列中的值可能不会变小，这是因为该列的内容不会被实时更新。

 

8.最后删除创建的表。

 

 SQL>drop table t1;