急，急！ORACLE不能启动！HELP!!!

parrotao

raid1好象没有用!
不能作为backup
我觉得好象一定要重backup恢复,因为你已经打开了数据库
已经造成了各数据文件的不一致

半瓶醋

我想你应该把你的环境和自从故障后做过一些什么处理等 说出来，别人才能帮你想出解决方案。。。

半瓶醋

我想你应该把你的环境和自从故障后做过一些什么处理等 说出来，别人才能帮你想出解决方案。。。

tom_jxp

你用的是硬件的raid 1吗？它主要是为了防止硬盘物理损坏，但你是软件的逻辑错误，你的两张镜像硬盘上的system表空间文件的内容是一模一样的，要错都错。

白鹭

不要轻易作open resetlog操作,这种情况还是比较有可能恢复的。

yminn

强调READ1方式在于可只对一盘进行操作。
如现在已通过逻辑备份复原了系统，但尚有一盘还处于出故障时的初始状态。
即：

dbstart后
ora-01122:database fle1 failed verfication check
ora-01110:datafile 1 '/usr/oracle/oradata/oracle7/system01.dbf'
ora-01207:file is more recent than control file --- old control file

我希望找到恢复它的方法！！
谢谢各位的继续支持。

白鹭

一般来说,像你这种情况,可以考虑采用如下恢复步骤:
1.备份现有redo log,control file,datafile
2.重建控制文件
3.recover database using backup controlfile;
   注意要用当前的日志文件来apply，当然你要明确用哪一个redo log,确保完全恢复后，才进行下一步,如果你还不清楚，不要进行下一步
4.alter database open resetlogs;

jiang

System 表空间的文件同其他文件时间上不一致了(SCN-- System Change Number不一致)，重建控制文件是解决不了问题的。System 表空间的数据文件是不能删除的。

现在你必须有备份：

1， ARCHIVE 方式下，恢复一个最近的'/usr/oracle/oradata/oracle7/system01.dbf'  COPY, 应用归档日志恢复；

2，NOARCHIVE方式，恢复一个最近的Cold Backup, 这个Backup之后的数据无法恢复。

一定对你的系统分析之后在做决定，毕竟毯子上的人不了解你的真正情况，指点难免有误。

白鹭

有备份的恢复通常比较简单，麻烦的是通常在noarchivelog模式，又没有备份，又发生这种不一致的情况，如果情况不是最坏的情况，
当前redo log还没被覆盖，还是比较有可能恢复的，我曾经帮别人多次恢复。

yminn

redo文件没被覆盖，所有文件在另一硬盘上都存在于出错的初始状态。
因不能影响企业的正常工作，对错误硬盘的处理时间很少，故希望能找到最有效的方法。
谢谢！！！