刚开始觉得数据库恢复这部分知识要点还算清楚了，现在觉得以前得有些理解都错了，看来oracle这行还真不能说自己很会，oracle的内部世界可能现在的我根本无法去想象。哎，坚持oracle热爱oracle吧。入门找到属于自己的领地吧！

关于表空间和检查点的:

表空间脱机

Alter tablespace users offline

此时将表空间离线将触发检查点，所以此时的控制文件中记录该数据文件检查点

Select checkpoint_change# from v$datafile

数据文件头部记载的数据文件启动scn也会变化

Select checkpoint_change# from v$datafile_header

如果此时再进行表空间上线又会触发检查点，同样控制文件中记载的关于users表空间的checkpoint scn也会分别增加。

数据文件脱机了：

数据文件脱机不会触发文件检查点，和shutdown abort关闭数据库一样没有checkpoint，此时数据文件的stop scn和checkpoint scn不一致，所以数据文件重新上线就需要实行介质恢复。

不管是表空间还是数据文件offline然后onlin跟别的数据文件的checkpoint scn其实不一致了，不过如果是发生系统检查点则可以达到一致。

以前就整理过关于scn和数据库恢复的文章，不过说到底其实到现在也不能算完全理解。

不过看了点帖子和平时积累还是颇有收获：

介质恢复：有数据文件损坏，需要你手动去恢复，restore 备份的文件，然后利用归档日志recover数据库到介质失败前，

实例恢复，一般指数据文件和控制文件里记录的数据文件信息不一致，根据情况，会有事务前滚或回滚，使用的当前重做日志。Smon进程在数据库再次启动时会自动完成实例恢复，通常shutdown abort，startup force都会导致，一般都由oracle自动执行的。

就今天关于控制文件的重建来恢复数据库的要点：

1 noresetlogs重建ctl，此时由于是noresetlogs方式oracle会认为当前日志文件都在，所以新建的ctl会从日志文件中获取全部信息（checkpoint scn也是从日志文件获取的）

至于控制文件中记载的数据文件checkpoint scn和stop scn 数据文件头部的启动scn也应该是通过redo来实现还原的吧。

当通过redo全部让数据文件和控制文件的的几个scn一致，数据库的恢复也就完毕了。

2 resetlogs重建ctl，此时oracle其实认为当前的redo已经丢失。

Recover database using backup controlfile unitl cancel

指定日志: {=suggested | filename | AUTO | CANCEL}在这里有几个选项
suggested:在上面ORA-00289: 建议:....会按这个文件去恢复
filename:自己指定日志文件
auto:自动选择，但我个人觉得好像和suggestted一样呢:(
cancel:这个可以不从介质恢复

其实更多的会选择auto让oracle帮助恢复到最后scn，不过由于oracle认为当前redo已经丢弃，oracle只是利用归档日志来恢复数据文件，但是由于当前日志还在归档日志还没有生成当前redo的备份信息，而oracle又认为当期的redo已经损坏，所以此时恢复也就无法完成了。

可以指定当前最新的redo来对数据库进行恢复然后resetlogs打开即可。

所以在制定日志时输入当前

redo： e:oracleproduct10.2.0oradatatestredo03.log

然后数据库就可恢复到最后scn。

[@more@]