ora-01033引起的血案

今天真是倒霉的一天，一大早5：35客户打过来电话，说是系统没法登录，5：35上班？我昨晚2：30才睡的觉，不晓得这么早上班是否是先煮饭，悲催！！

联机看PL/SQL报01033错误，shutdown以后startup发现ora-00314 ora-00312

联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，通常经过clear命令就能够解决问题。

损坏非当前联机日志：
一、启动数据库，遇到ORA-00312 or ORA-00313错误，如:
ORA-00313: open failed for members of log group 4 of thread 1
ORA-00312: online log 3 thread 1: '/opt/oracle/db04/oradata/ORCL/redo03.log'
从这里咱们知道日志组1的数据文件损坏或丢失了
从报警文件能够看到更详细的信息
二、查看V$log视图:
SQL>; select group#,sequence#,archived,status from v$log;

    GROUP#  SEQUENCE# ARC STATUS

---------- ---------- --- ----------------

         1         54 YES INACTIVE

         2         55 NO  CURRENT

3             53 YES INACTIVE


能够知道，该组是非当前状态，并且已经归档。
三、用CLEAR命令重建该日志文件
SQL>;alter database clear logfile group 3;
若是是该日志组尚未归档，则须要用
SQL>;alter database clear unarchived logfile group 3;
四、打开数据库，从新备份数据库
SQL>;alter database open;
说明：
1)、若是损坏的是非当前的联机日志文件，通常只须要clear就能够重建该日志文件，可是若是该数据库处于归档状态但该日志尚未归档，就

须要强行clear。
2)、建议clear，特别是强行clear后做一次数据库的全备份。
3)、此方法适用于归档与非归档数据库。

损坏当前联机日志：

归档模式下当前日志的损坏有两种状况，
1、是数据库是正常关闭，日志文件中没有未决的事务须要实例恢复，当前日志组的损坏就能够直接用alter database clear unarchived

logfile group n来重建。
2、是日志组中有活动的事务，数据库须要媒体恢复，日志组须要用来同步，有两种补救办法
A. 最好的办法就是经过不彻底恢复，能够保证数据库的一致性，可是这种办法要求在归档方式下，而且有可用的备份
B. 经过强制性恢复，可是可能致使数据库不一致。
下面分别用来讲明这两种恢复方法
5.1.2.1 经过备份来恢复
一、打开数据库，会遇到一个相似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件

二、查看V$log，发现是当前日志
SQL>; select group#,sequence#,archived,status from v$log;

GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2

 
YES INACTIVE
3 3 YES INACTIVE

三、发现clear不成功
SQL>; alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'

四、拷贝有效的数据库的全备份，并不彻底恢复数据库
能够采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel
先选择auto，尽可能恢复能够利用的归档日志，而后从新
recover database until cancel
此次输入cancel，完成不彻底恢复，也就是说恢复两次。
如：
SQL>; recover database until cancel;
Auto
……
SQL>; recover database until cancel;
Cancel;
五、利用alter database open resetlogs打开数据库
说明：
一、这种办法恢复的数据库是一致的不彻底恢复，会丢失当前联机日志中的事务数据
二、这种方法适合于归档数据库而且有可用的数据库全备份。
三、恢复成功以后，记得再作一次数据库的全备份。
四、建议联机日志文件必定要实现镜相在不一样的磁盘上，避免这种状况的发生，由于任何数据的丢失对于生产来讲都是不允许的。

若是没有备份，进行强制性恢复
一、打开数据库，会遇到一个相似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件

二、查看V$log，发现是当前日志
SQL>; select group#,sequence#,archived,status from v$log;

GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES INACTIVE
3 3 YES INACTIVE

三、发现clear不成功
SQL>; alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'

四、把数据库down掉
SQL>;shutdown immediate

五、在init<sid>;.ora中加入以下参数
_allow_resetlogs_corruption=TRUE

六、从新启动数据库,利用until cancel恢复
SQL>;recover database until cancel;
Cancel
若是出错，再也不理会，发出
SQL>;alter database open resetlogs;

七、数据库被打开后，立刻执行一个full export

八、shutdown数据库,去掉_all_resetlogs_corrupt参数

九、重建库

十、import并完成恢复

十一、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
说明：
一、该恢复方法是没有办法以后的恢复方法，通常状况下建议不要采用，由于该方法可能致使数据库的不一致
二、该方法也丢失数据，可是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据。
三、建议成功后严格执行以上的7到11步，完成数据库的检查与分析
四、所有完成后作一次数据库的全备份
五、建议联机日志文件必定要实现镜相在不一样的磁盘上，避免这种状况的发生，由于任何数据的丢失对于生产来讲都是不允许的。
用startup force试试！
 

allow_resetlogs_corruption=TRUE
这个我用过,数据库能够起来,可是数据是否是完整,还不必定,但数据库能够起来
须要从新启动一个log
SQL>;RECOVER DATABASE UNTILE CANCEL;
数据库会本身找一些它所须要的文件来进行数据库恢复；
SQL>;ALTER DATABASE OPEN RESETLOGS;
不知道你作没有作归档，若是作了，那么这个RECOVER仍是比较有效的
没作的话估计不行