REDO文件丢失的恢复__没有任何备份的情况

以下为没有任何备份的前提下，但是控制文件、其他所有文件都是OK的情况下


online redo inactive\unused文件丢失，可以恢复,只要启动到mount状态，alter database clear logfile即可
比如手工删除了active状态的group 1的所有日志文件，启动的时候报错ORA-00313: open failed for members of log group 1 of thread 1
SQL> startup mount;
SQL> alter database clear logfile group 1;
SQL> alter database open;


online redo   active文件丢失，无法恢复。
SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS from v$log;
    GROUP#    THREAD#  SEQUENCE# STATUS
---------- ---------- ---------- ----------------
         1          1         10 CURRENT
         3          1          9 ACTIVE
         2          1          8 ACTIVE

SQL> select status from v$instance;
STATUS
------------
MOUNTED

SQL> alter database clear logfile group 2;
alter database clear logfile group 2
*
ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance orcl (thread 1)
ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/orcl/redo02.log'



online redo current文件丢失,基本上是无法恢复了
没有任何备份的环境下online redo current文件丢失（归不归档都一样），一般恢复不过来。但仍有如下大概的恢复方法，无法保证一定能成功，运气好的话可能成功。
遇到这样的问题，一般是如下场景
SQL>startup mount;
RMAN> restore database;
RMAN> recover database;
RMAN>alter database open resetlogs;
后会有如下提示
ORA-01194: file 1 needs more recovery to be consistent 
ORA-01110: data file 1: '/u01/app/oracle/oradata/DB/system01.dbf' 
这是因为当前的redo log写入不完整导致库无法打开，我们需要使用强制open数据库的方式，使其跳过数据库对redo和undo 表空间的检验。 


恢复方法
1.备份所有数据文件（强制开库后所有文件都会有一次写入行为，如果强制开库失败，可能会导致最后一招DUL数据抽取工具都无法使用）
2.截取出报错ORA-01110中数据文件的UNDO信息，如上为system01.dbf
strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u
3.根据上面显示的UNDO信息，在pfile中新增参数_CORRUPTED_ROLLBACK_SEGMENTS，如下_SYSSMU1$表示以1开头的所有UNDO信息，一般如下配置就包括了所有的UNDO信息，1开头到9开头的所有UNDO
_CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$) 
4.pfile中继续新增如下参数
UNDO_MANAGEMENT=MANUAL 
_ALLOW_RESETLOGS_CORRUPTION = TRUE
5.启动数据到mount状态
SQL>startup mount pfile='/..../init.ora' 
SQL>show parameter corrupt; 
SQL>show parameter undo 
6.Recover and open the database: 
SQL>RECOVER DATABASE UNTIL CANCEL; 
==>输入CANCEL 
SQL>ALTER DATABASE OPEN RESETLOGS; 
ALTER DATABASE OPEN RESETLOGS 
* 
ERROR at line 1: 
ORA-00603: ORACLE server session terminated by fatal error 
ORA-00600: internal error code, arguments: [2662], [2380], [2470549886], 
[2380], [2470550245], [12583040], [], [], [], [], [], [] 
ORA-00600: internal error code, arguments: [2662], [2380], [2470549885], 
[2380], [2470550245], [12583040], [], [], [], [], [], [] 
ORA-01092: ORACLE instance terminated. Disconnection forced 
ORA-00600: internal error code, arguments: [2662], [2380], [2470549881], 
[2380], [2470550245], [12583040], [], [], [], [], [], [] 
Process ID: 4066 
Session ID: 3753 Serial number: 3 
7.如果上面报错ora-00600 [2662]，则需要推进SCN，执行一次10015 level 1表示推进100万，执行两次表示推进200万，10015 level 1表示推进500万，如下表示推进了700万，推进多次后alter database open还是报ORA-01113的话就没辙了 
SQL> shutdown abort;
SQL> startup mount pfile='/..../init.ora'; 
SQL> ALTER SESSION SET EVENTS '10015 TRACE NAME ADJUST_SCN LEVEL 1'; 
Session altered. 
SQL> ALTER SESSION SET EVENTS '10015 TRACE NAME ADJUST_SCN LEVEL 1'; 
Session altered. 
SQL> ALTER SESSION SET EVENTS '10015 TRACE NAME ADJUST_SCN LEVEL 5'; 
Session altered. 
SQL> alter database open; 
alter database open 
* 
ERROR at line 1: 
ORA-01113: file 1 needs media recovery 
ORA-01110: data file 1: '/u01/app/oracle/oradata/DB/system01.dbf' 





注意：利用上面这种方法打开的数据库，很有可能存在不一致的地方,所以用exp/imp的方法将数据导入到新库中。 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30126024/viewspace-2142751/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30126024/viewspace-2142751/