有没有昨天的dump你把原数据库的文件拷贝,重安装数据库,建相同的tablespace和库,
在把原来的覆盖回去。

解决方案 »

  1.   

    在有日志文件的情况下
    将系统时间调回到发生灾难的时刻!!!
                  试试看,也许有救!!!
         GOOD LUCK!!!
      

  2.   

    TO: penitent(只取一瓢)
    操作系统没有崩溃,可能是硬件出现了点问题,然后数据库就报出了一大堆错误。重起机器后,监听器和数据库服务器在服务里面都启动起来了,但不能登陆进出。同事用命令shutdown abort强行关闭数据库,数据库半天没有反应,关掉后再重起了一下机器。数据库在服务里面还是能够很好的启动起来,但用
    internal/oracle在SQL/PLUS中登录的时候,系统报ora-0192:oracle instance terminated.disconnection forced错误。转到DOS,svrmgrl命令下面,1。shutdown 出现一串问号,oracle实例关闭,2。startup 就报ora-00214又是一串问号,里面可以看到控制文件。所以此时我估计是控制文件有错,所以我就试着在init.ora中去删掉控制文件列中的控制文件,3个控制文件我都试过,但都不成功。要么是报ora-00214错误,要么报ora-00205错误。
    我本来数据库水平就只有个半灌水,又好几天没有休息好,所以后来我没有办法就重建了数据库,造成丢失了昨天的业务数据。数据库以前是运行在归档模式,请问还有办法恢复吗。
      

  3.   

    ORA-00214: control file name version num inconsistent with file name version num 
    Cause: An inconsistent set of control files, datafiles, and redo log files was used. Action: Use a consistent set of control files, datafiles, and redo log files. That is, all the files must be for the same database and from the same time period. 
    ORA-00205: error in identifying control file name 
    Cause: The system could not find a control file of the specified name and size. Action: Either Check that the proper control filename is referenced in the CONTROL_FILES initialization parameter in the initialization parameter file and try again. 
    When using mirrored control files, that is, more than one control file is referenced in the initialization parameter file, remove the control filename listed in the message from the initialization parameter file and restart the instance. If the message does not recur, remove the problem control file from the initialization parameter file and create another copy of the control file with a new filename in the initialization parameter file.
      

  4.   

    首先我们解决你的命令后为什么都是???
    这个问题是语言环境的不一样引起的
    修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0\nls_lang为AMERICAN_AMERICA.你的字符集
    然后再说备份与恢复的问题。
    其一,数据库以前是运行在归档模式,如果有热备份或冷备份就肯定能恢复,如果没有文件备份,就要看你的运气。光有归档是不行的,还需要备份。
    svrmgrl,先startup mount(startup)中,首先遇到的是ORA-00214错误,是说你的控制文件之间或控制文件与其他数据文件,联机日志的scn号不一致引起的,一般情况下它会提示有错误的那个控制文件,解决的办法是在重新关闭数据库的情况下(一定要先关闭)在init.ora中去删掉控制文件列中的显示的错误的控制文件(不是全部),或在关闭情况下删除错误的控制文件,用其他的控制文件复制一个(控制文件都是一样的)。
    如果没有问题了,再startup mount,如果正确,表示控制文件已经恢复了。但是如果全部控制文件都毁坏了,那就需要控制文件的备份了。这种情况少,也就不说了。
    如果在startup mount没有问题
    就试着alter database open,看有什么错误或提示,如果有数据文件错误的提示或查询v$recover_file有恢复内容,那就需要备份了,只要是文件备份就可以,如果没有,就不好办了。
    再说如果没有数据文件的损坏,又打不开数据库,一般是联机日志的损坏。
    可以用recover database until cancel;
    然后输入cancel
    alter database open resetlogs;
    打开数据库。
    -------------
    说了这么多,其实还只是备份与恢复中的一小部分,建议大家多看看备份与恢复,我发现csdn上,有很少的人对备份与恢复有比较深的见解。
      

  5.   

    其二,说了这么多,如果你以前有备份就好了。
    建议以后数据库不仅要运行在归档方式下,还要经常进行备份,最好是热备份。
    你可以参考一下,
    这里面就有我一直在用的备份代码
    http://www.csdn.net/expert/topic/1025/1025428.xml?temp=.468548
    虽然我的数据库也崩溃过,但我从来没有丢过数据