假如我们的数据库有一天遭受crash，而且没有可用备份，使用_allow_resetlogs_corruption都打不开数据库，这时我们改怎么办？
这时我们可以使用类似odu的软件来从数据文件中抽取数据，不过如果数据非常巨大哪么这种方法会非常慢甚至无法正常抽取，况且如果有CLOB、BLOB的字段可能还无法恢复；哪么我们的数据库还有没有办法以非常规的方法open呢？

我们知道ORACLE打开数据库的步骤有下面两步
第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.如果相等,进行第二次检查.
第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.
前两步检查都通过后数据库OPEN,把数据文件的STOP SCN置为无穷大。

也就是说我们只要保证每一个数据文件的checkpoint cnt和他在control file中的checkpoint cnt一致（但是数据文件之间的cnt可能不一致）并且每一个数据文件的start scn和他在control file中的stop scn一致（数据文件本身的stop scn数据库启动时并不检查）我们的数据库就能正常打开，这种思路可行否？如果可行的话通过类似bbed、uedit32等二进制编辑软件来修改cnt和scn使得这两个条件完全一致不就可以了

具体的做法：
比如说数据库中有五个数据文件，找到每个数据文件的checkpoint cnt和start scn，修改control file对应的数据文件的cnt和scn和数据文件一致。然后打开数据库，对数据库进行exp imp即可。

想做一个这样的试验，但是由于没有相关的control file和data file的详细结构说明，无法修改control file和data file文件。

有意思，但是我也觉得不太可能如此容易能骗过oracle！

崔华对于ORACLE internal特别是对block层面的知识可以说在中国也是前几了。用他的话说，无论是什么类型的数据块，每一个字段他都烂熟于心了。如果我们也可以做到这个地步，并且对ORACLE的open流程非常熟悉，当然也可以做到骗过ORACLE，我们甚至可以自己手工凭空建造一个datafile，并且让ORACLE正常打开。

http://www.itpub.net/viewthread. ... hlight=%D1%AA%B0%B8

最后催华以非常规方式打开数据库，挽救了几乎100%的数据我想知道的是它是以什么方式打开的数据库？我猜测他应该就是用上面的方法，毕竟在上面的情况发生时，数据的一致性就不是哪么重要了，能够挽回数据库中的数据才是最重要的。

这种方法没有可行性，因为数据块中、数据块的itl中，事务表中都有scn，即使打开了，在读取的时候，如果碰到大的scn，系统还是会报ora600错误而退出。
你可以强行提高数据文件头部的scn，让他大于所有的数据块的scn，然后就可以打开，但是一致性可能会有问题。

另外，ODU之类的工具直接从datafile上抽数据会比exp慢？？？

支持一下2楼的，oracle开机启动的时候检查的相很多。所以，这个方法可行性不是很高啊。

第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.如果相等,进行第二次检查.
第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.
这两点只是数据库open过程中的两步而已，只是一个方面。在open时oracle要检查的东西非常多的，如某些关键的数据字典的检查，对于system表空间回滚段的状态的修改，对于上次shutdown时最后一个写入数据块的检查等等等等等等。上面某一个发生问题就无法正常open.
换句话说，我们一般遇到的数据库不能正常open的问题并不一定就是那两种问题中的一个。