Heim >Datenbank >MySQL-Tutorial >ORA-00312 ,ORA-00313

ORA-00312 ,ORA-00313

WBOY
WBOYOriginal
2016-06-07 17:10:481165Durchsuche

损坏非当前联机日志 1、启动数据库,遇到ORA-00312 or ORA-00313错误,如 ORA-00313: open failed for members of log group 1 o

损坏非当前联机日志

1、启动数据库,遇到ORA-00312 or ORA-00313错误,如
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'
从这里我们知道日志组1的数据文件损坏了
从报警文件可以看到更详细的信息
2、查看V$log视图
SQL> select group#,sequence#,archived,status from v$log;

    GROUP#  SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
         1          1 YES      INACTIVE
         2          2 YES      INACTIVE
         3          3 NO       CURRENT
可以知道,该组是非当前状态,而且已经归档。
3、用CLEAR命令重建该日志文件
SQL>alter database clear logfile group 1;
如果是该日志组还没有归档,则需要用
SQL>alter database clear unarchived logfile group 1;
4、打开数据库,重新备份数据库
SQL>alter database open;
说明:
1、如果损坏的是非当前的联机日志文件,一般只需要clear就可以重建该日志文件,但是如果该数据库处于归档状态但该日志还没有归档,就需要强行clear。
2、建议clear,特别是强行clear后作一次数据库的全备份。
3、此方法适用于归档与非归档数据库


损坏当前联机日志
归档模式下当前日志的损坏有两种情况,
一、是数据库是正常关闭,日志文件中没有未决的事务需要实例恢复,当前日志组的损坏就可以直接用alter database clear unarchived logfile group n来重建。
二、是日志组中有活动的事务,数据库需要媒体恢复,日志组需要用来同步,有两种补救办法
A.        最好的办法就是通过不完全恢复,可以保证数据库的一致性,但是这种办法要求在归档方式下,,并且有可用的备份
B.        通过强制性恢复,但是可能导致数据库不一致。
下面分别用来说明这两种恢复方法
5.1.2.1 通过备份来恢复
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) 系统找不到指定的文件

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

3、发现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'

4、拷贝有效的数据库的全备份,并不完全恢复数据库
可以采用获取最近的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;
5、利用alter database open resetlogs打开数据库
说明:
  1、这种办法恢复的数据库是一致的不完全恢复,会丢失当前联机日志中的事务数据
  2、这种方法适合于归档数据库并且有可用的数据库全备份。
  3、恢复成功之后,记得再做一次数据库的全备份。
  4、建议联机日志文件一定要实现镜相在不同的磁盘上,避免这种情况的发生,因为任何数据的丢失对于生产来说都是不容许的。


如果没有备份,进行强制性恢复
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) 系统找不到指定的文件

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

3、发现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'

4、把数据库down掉
  SQL>shutdown immediate

5、在init.ora中加入如下参数
   _allow_resetlogs_corruption=TRUE

6、重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
如果出错,不再理会,发出
SQL>alter database open resetlogs;

7、数据库被打开后,马上执行一个full export

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

9、重建库

10、import并完成恢复

11、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
说明:
1、该恢复方法是没有办法之后的恢复方法,一般情况下建议不要采用,因为该方法可能导致数据库的不一致
2、该方法也丢失数据,但是丢失的数据没有上一种方法的数据多,主要是未写入数据文件的已提交或未提交数据。
3、建议成功后严格执行以上的7到11步,完成数据库的检查与分析
4、全部完成后做一次数据库的全备份
5、建议联机日志文件一定要实现镜相在不同的磁盘上,避免这种情况的发生,因为任何数据的丢失对于生产来说都是不容许的。

linux

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn