oracle 丢失日志(redoxx_xx)文件后的处理方法

测试部门反映内网1.105oracle数据库服务无法启动，还是惯例性的打开alter_<sid>.log文件，查看里面的日志内容：

Fri Nov 11 11:46:09 2011
Errors in file /u01/app/oracle/admin/center/bdump/center_lgwr_3016.trc:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/u02/oradata/center/redo02_1.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 2 thread 1: '/u02/oradata/center/redo02.log' 
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory

这段日志内容明显说明数据库启动时找不到group 2日志组的日志文件redo02.log'redo02_1.log,于是：

cd /u02/oradata/center

ls

果真在此目录下找不到报错的日志文件，问题原因查明，进行相关处理：

重做日志损坏或者误删或者丢失，那么肯定数据库不能够进行完全恢复，会丢失当前重做日志中的事务数据。

恢复方法需要针对重做日志组丢失的状况以及当前在数据库中的状态而采用不同的方法进行恢复。

首先检查重做日志文件状态，看看报错的日志文件的状态。

SQL> select * from v$log; 
SQL> select * from v$logfile; 

针对：丢失非活动日志文件的恢复，非活动日志文件指的是丢失的日志文件组状态为’INACTIVE',说明该日志组已经完成检查点后丢失的日志文件，

数据库不会发生数据丢失，但是千万不能够忽视，因为当日志切换到该日志组时会发生错误。

主要方法包括方法一、方法二、方法三。

方法一：通过重新生成重做日志文件组

直接删除丢失的重做日志文件组,但是删除后必须保证数据库的重做日志组数目不能小于2个。

删除重做日志文件组：

SQL> alter database drop logfile group 1;

Database altered.

增加重做日志文件组：

SQL>alter database add logfile group 1('/u01/oradata/orcl/redo1.log','/u01/oradata/orcl/redo01.log') size 500m;

Database altered.

方法二：通过增加重做日志文件成员以及删除丢失的日志文件

在丢失的重做日志组中增加同样大小的REDO文件，然后删除丢失的MEMBER。

增加重做日志文件成员：

SQL> alterdatabase add logfile member '/u01/oradata/orcl/redo01.log' to group 1;

Databasealtered.

删除丢失的日志文件：

SQL> alterdatabase drop logfile member '/u01/oradata/orcl/redo1.log';

Database altered.

这种方法只适合丢失的文件组中至少还有一个成员是可用的，如果丢失的日志文件所属的文件组只有这一个文件，那么这种方法是不适合的。

在添加日志文件时会出错：

SQL> alterdatabase add logfile member '/u01/oradata1/redo1.log' to group 1;

alter databaseadd logfile member '/u01/oradata1/redo01.log' to group 1

*

ERROR at line 1:

ORA-00313: openfailed for members of log group 1 of thread 1

ORA-00312:online log 1 thread 1: '/u01/oradata/orcl/redo01.log'

ORA-27037:unable to obtain file status

Linux Error: 2:No such file or directory

Additionalinformation: 3

方法三：通过clear日志恢复

SQL> alterdatabase clear logfile group 1;

Databasealtered.

SQL> alterdatabase open;

Databasealtered.

需要说明的是，如果数据库处于归档模式下，则需要使用下面的命令来清除日志：

alter databaseclear unarchived logfile group 1;

丢失的是一组中的某个日志文件，则clear的那个日志文件

SQL> alter database clear logfile '/u02/oradata/center/redo01.log‘;

针对：丢失当前的日志文件的恢复，指丢失的日志文件的状态如果是ACTIVE或CURRENT（有可能是异常关闭数据库造成），说明没有归档。

如果没有归档的日志组中含有多个日志文件成员，那么丢失或者损坏部分日志文件时，只需要复制正常的日志文件，

来替换丢失或损坏的日志文件即可解决，这样数据不会丢失，也不用做恢复操作。
如果没有归档的重做日志组中所有日志件都丢失或者损坏，将会导致数据库数据丢失，如果没有归档的日志文件组为当前组，

则数据库立即DOWN机。当这个情况发生时，就意味着数据的丢失，我们只能将数据库恢复到前一次的归档日志切换时刻

主要方法包括方法四、方法五。

方法四：先尝试通过clear日志恢复

SQL> alterdatabase clear unarchived logfile group 2;

Databasealtered.

检查发现，日志文件已经恢复，会多出日志文件组中丢失的其中的一个文件（同组中没有所有日志文件都丢失）

SQL> alterdatabase open;

Databasealtered.

方法五：通过设置_allow_resetlogs_corruption参数为true进行恢复。

这是破坏唯一性的情况下强制重置日志，打开数据库，在打开的过程中，ORACLE会跳过一致性检查，使数据库处于不一致的状态下打开。

由于重做日志文件状态为Current，恢复工作较为复杂，有以下四种情况：
1）通过下面步骤，数据库顺利打开

SQL> startup mount 
SQL> recover database until cancel; 

或者恢复到某个以前时间点

SQL> recover database until time '2011-11-09 01:01:01'; 

SQL>alter database open resetlogs; 

2）第一种情况的'recover database until cancel' 操作遇到ORA-01547，ORA-01194，ORA-01110错误，需要整个数据库的物理备份，

并根据归档日志恢复到错误时间点，前提是数据库是归档模式。

SQL> startup mount 
SQL> recover database until cancel using backup controlfile; 
SQL> alter database open resetlogs; 

3）如果数据库是非归档模式，只能恢复整个物理备份，然后直接打开数据库。这种情况将丢失物理备份至故障发生前的全部数据。

4）如果数据库是非归档模式，且没有物理备份，只能通过特殊的隐含参数，允许数据库不一致的状况下打开数据库。

这种恢复方法是没有办法之后的恢复方法，将导致数据库不一致，一般情况下不要采用。如确有需要，请在Oracle的技术人员指导下使用该方法。

#关闭数据库
SQL>shutdown immediate 
#在init<sid>.ora中加入如下参数 
_allow_resetlogs_corruption=TRUE 
# 重新启动数据库,利用until cancel恢复 
SQL>recover database until cancel; 
#打开数据库
SQL>alter database open resetlogs; 
#数据库被打开后，马上执行一个全库导出。

SQL> shutdown immediate; 

#关闭数据库，在init<sid>.ora中去掉_all_resetlogs_corrupt参数

#然后重新启动数据库

SQL> startup

#本次案例通过以上判断是丢失当前的日志文件的恢复，采用了方法五。

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