探讨ORACLE的SCN机制（1）

oracle 数据库的打开过程进行的检查操作

       第一步：Oracle将数据文件头中的启动SCN与数据文件检查点SCN比较,即比较v$datafile_header.checkpoint_change#与对应文件v$datafile.checkpoint_change#,同时数据库文件头的checkpoint_change#等于v$database 的checkpoint_change#.
       第二步：第一步成功的情况下，Oracle接下来再比较数据文件头中的SCN和控制文件中数据文件的终止SCN.即比较v$datafile_header.checkpoint_change#与对应文件的v$datafile.last_chage#；如果这个值也匹配，就意味着所有数据块已经提交，因此数据 库不需要进行恢复，此时数据库直接打开。当所有的数据文件都打开之后，在线且可读写的数据文件终止SCN再次被设置为NULL，即把v$datafile.last_chage#设置为NULL，表示数据文件已经打开并能 够正常使用了。有些表空间是只读的，这时控制文件中的系统检查点SCN号会不断增长，而数据文件SCN号和文件头中的启动SCN(会停止更新直到表空间又 设置为可读写)，显然这时系统检查点SCN号会大于数据文件SCN和文件头启动SCN。

       下面对上面的结论进行验证：

       上面的第二步提到的是怎么判断是否需要进行实例恢复的原理。那么，对于介质恢复又是怎样呢？

       其实，在第一步的时候，如果对应数据文件的文件头检查点，也就是v$datafile_header.checkpoint_change#，小于v$database.checkpoint_change#的话，这就说明该数据文件是以前版本的数据文件，需要进行物理修复。

       如下，让一个数据文件离线，然后把该文件上线的时候，就会报需要进行介质恢复，而此时的SCN刚好证明了上面的观点。

SQL> alter database datafile  'D:\APP\ASUS\ORADATA\WAREHOUSE\TEST03.DBF' online;alter database datafile  'D:\APP\ASUS\ORADATA\WAREHOUSE\TEST03.DBF' online*ERROR at line 1:ORA-01113: file 8 needs media recoveryORA-01110: data file 8: 'D:\APP\ASUS\ORADATA\WAREHOUSE\TEST03.DBF'SQL> select checkpoint_change# from v$database;CHECKPOINT_CHANGE#------------------           1148279SQL> select file#,checkpoint_change# from v$datafile_header where file#=8;     FILE# CHECKPOINT_CHANGE#---------- ------------------         8            1147868SQL>  select file#,checkpoint_change#,last_change# from v$datafile where file#=8;     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#---------- ------------------ ------------         8            1147868      1148597SQL> select a.file#,b.name ,a.status from v$datafile a,v$tablespace b  where a.ts#=b.ts#  and b.name='TEST01';     FILE# NAME                           STATUS---------- ------------------------------ -------         6 TEST01                         ONLINE         8 TEST01                         RECOVER