创建控制文件或从控制文件备份上先恢复控制文件
如果你以前有
alter database backup controlfile to 'filename';
或者
later database backup controlfile to trace;
那么你将有控制文件的备份,否则你只有创建控制文件
通过以上手段,你可以将数据库恢复到mount下
在mount下
recover database until cancel using buckup controlfile;
通过
alter database open resetlogs可以创建联机日志并同步所有文件.
---------------
最后再做一次全备份

解决方案 »

  1.   

    to penitent
    現在控制文件可以恢復﹐创建联机日志日志文件時出錯
      

  2.   


                         控制文件损坏时的恢复根据如下错误信息,我们发现数据库只能启动实例,读控制文件时发生错误。在数据库设计的过程中,从安全的角度考虑,系统使用了三个径向的控制文件,现在三个控制文件version号不一致。
    SVRMGRL>startup
    oracle instance started
    total system global area 222323980 bytes
    fixed size 70924 bytes
    variable size 78667776 bytes
    database buffers 143507456 bytes
    redo buffers 77824 bytes
    ORA-00214: controlfile ‘d:\oracle\oradata\orcl\control01.ctl’ version 57460 inconsistent with file ‘d:\oracle\oradata\orcl\control02.ctl’ version 57452. 
    根据以上分析,我们试着修改参数文件。将参数文件中的control_file参数修改为一个控制文件,分别使用control01、control02、control03。但数据库都无法启动,说明三个控制文件都已损坏。 
    由于没有控制文件的备份,我们只能采取重建控制文件的做法。
    D:\>svrmgrl
    Oracle Server Manager Release 3.1.6.0.0 - Production
    版权所有 (c) 1997,1999,Oracle Corporation。保留所有权利。
    Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production
    With the Partitioning option
    JServer Release 8.1.6.0.0 - Production
    SVRMGR> connect internal
    连接成功。
    SVRMGR> shutdowm abort
    已关闭 ORACLE 实例。
    SVRMGR> startup nomount
    已启动 ORACLE 实例。
    系统全局区域合计有 108475660个字节
    Fixed Size 70924个字节
    Variable Size 46116864个字节
    Database Buffers 62210048个字节
    Redo Buffers 77824个字节
    SVRMGR>create controlfile reuse database orcl noresetlogs archivelog
    Logfile group 1 ‘d:\oracle\oradata\orcl\redo01.log’,
    group 2 ‘d:\oracle\oradata\orcl\redo02.log’,
    group 3 ‘d:\oracle\oradata\orcl\redo03.log’
    datafile ‘d:\oracle\oradata\orcl\system01.dbf’,
    ‘d:\oracle\oradata\orcl\users01.dbf’,
    ‘d:\oracle\oradata\orcl\temp01.dbf’,
    ‘d:\oracle\oradata\orcl\tools01.dbf’,
    ‘d:\oracle\oradata\orcl\indx01.dbf’,
    ‘d:\oracle\oradata\orcl\dr01.dbf’,
    ‘d:\oracle\oradata\orcl\rbs01.dbf’;
    语句已处理。 
    成功地重建控制文件后,我们尝试着打开数据库,但系统报错,提示需要进行介质恢复。
    SVRMGR>recover datafile ‘d:\oracle\oradata\orcl\system01.dbf’;
    介质已恢复。
    SVRMGR> recover datafile ‘d:\oracle\oradata\orcl\users0101.dbf’;
    介质已恢复。
    SVRMGR> recover datafile ‘d:\oracle\oradata\orcl\temp01.dbf’;
    介质已恢复。
    SVRMGR> recover datafile ‘d:\oracle\oradata\orcl\tools01.dbf’;
    介质已恢复。
    SVRMGR> recover datafile ‘d:\oracle\oradata\orcl\indx01.dbf’;
    介质已恢复。
    SVRMGR> recover datafile ‘d:\oracle\oradata\orcl\dr01.dbf’;
    介质已恢复。
    SVRMGR> recover datafile ‘d:\oracle\oradata\orcl\rbs01.dbf’;
    介质已恢复。 
    介质恢复后,重新打开数据库,提示日志文件也需恢复。
    SVRMGR> recover database until cancel;
    日志已恢复。 
    控制文件、数据文件、日志文件全部恢复后,将三种文件同步,并打开数据库,成功地完成了数据库的恢复工作。
    SVRMGR> alter database open resetlogs;
    数据库已更改。 
    立即关闭数据库,并进行数据库的冷备份,将数据库的数据完整地保存下来。 
     
      

  3.   

    to  wanghai(汪海):
    上面的方法試過﹐就是在恢復日志文件時出錯﹐有沒有辦法呢﹖還是玩完了﹖
      

  4.   

    看你的备份是不是按归档方式做的了,如果是,则决对没问题,可以恢复,否则一定是可以恢复的。
    不过,不要担心,只要你所有的数据文件(特别是system表空间数据文件)没丢失,则你的数据一定是不会丢不。
    Oracle有一个叫dul工具可以把这下问题搞定
    必要的时侯叫一下Oracle现场服务吧。
      

  5.   

    还要保证你的数据文件是没有损坏的
    如果有损坏,还需要用到归档日志.
    有归档没有
    --------------------
    to wanghai(汪海) 
    如果用到了
    recover database
    没有必要 
    recover datafile
      

  6.   

    topenitent(只取一瓢):
    有備份﹐但是是半個月以前的數據﹐現在想在現有的數據文件恢復。
    請問你現在在哪﹐可以和你電話連系嗎﹖
      

  7.   

    你先贴出你的解决办法或错误信息,应当这里就可以解决
    我是说你归档了没有,如果归档的话,很多问题就没有那么麻烦
    可能有两个地方需要用到归档
    1是如果你的数据文件有损坏,特别是系统数据文件,不仅需要归档,还需要备份
    2是如果你的数据文件不同步,可能会需要归档日志到同步
    ----------------
    我需要知道
    recover database until cancel出错没有
    alter database open resetlogs出错没有
    如果上一个语句出错,下一个语句肯定出错.
      

  8.   

    to penitent:
    好,謝謝,我試試
      

  9.   

    你还可以参考
    http://expert.csdn.net/Expert/FAQ/FAQ_Index.asp?id=44769
      

  10.   

    请问我用以前旧的数据备份文件备份恢复后再用现在仅有的数据表空间和索引空间直接覆盖后有问题吗?我这样做了之后再用指令恢复控制文件是成功的,可是创建日志出错,打开Database时提示不能找到数据库ID。
      

  11.   

    请问我用以前旧的数据备份文件备份恢复后再用现在仅有的数据表空间和索引空间直接覆盖后有问题吗?
    SCN都不一致,问题大了
      

  12.   

    biti的方法你试过没
    1,参数_allow_resetlogs_corrupton = true 
    2,startup mount 
    3,alter database clear logfile group 3 
    4. recover database until cancel 
    5. alter database open resetlogs