归档模式下当前日志的损坏有两种情况，

一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损坏就可以直接用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、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。

5.1.2.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) 系统找不到指定的文件

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、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。

5.2 损坏控制文件的恢复方法

5.2.1 损坏单个控制文件

  损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。

1、控制文件损坏，最典型的就是启动数据库出错，不能mount数据库

SQL>startup

ORA-00205: error in identifying controlfile, check alert log for more info

查看报警日志文件，有如下信息

alter database  mount

Mon May 26 11:59:52 2003

ORA-00202: controlfile: 'D:\Oracle\oradata\chen\control01.ctl'

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) 系统找不到指定的文件。

2、停止数据库

SQL>shutdown immediate

3、拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数，取消这个坏的控制文件。

4、重新启动数据

SQL>startup

说明：

1、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简单的拷贝一个好的就可以了

2、建议镜相控制文件在不同的磁盘上

3、建议多做控制文件的备份，长期保留一份由alter database backup control file to trace产生的控制文件的文本备份

5.2.2 损坏全部控制文件

损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。

同时注意，alter database backup control file to trace可以产生一个控制文件的文本备份。

以下是详细重新创建控制文件的步骤

1、关闭数据库

SQL>shutdown immediate;

2、删除所有控制文件，模拟控制文件的丢失

3、启动数据库，出现错误，并不能启动到mount下

SQL>startup

ORA-00205: error in identifying controlfile, check alert log for more info

查看报警日志文件，有如下信息

alter database  mount

Mon May 26 11:53:15 2003

ORA-00202: controlfile: 'D:\Oracle\oradata\chen\control01.ctl'

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) 系统找不到指定的文件。

4、关闭数据库

SQL>shutdown immediate;

5、在internal或sys下运行如下创建控制文件的脚本，注意完整列出联机日志或数据文件的路径，或修改由alter database backup control file to trace备份控制文件时产生的脚本，去掉多余的注释即可。

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "TEST" NORESETLOGS NOARCHIVELOG

    MAXLOGFILES 32

    MAXLOGMEMBERS 2

    MAXDATAFILES 254

    MAXINSTANCES 1

    MAXLOGHISTORY 226

LOGFILE

  GROUP 1 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'  SIZE 1M,

  GROUP 2 'D:\ORACLE\ORADATA\TEST\REDO02.LOG'  SIZE 1M,

  GROUP 3 'D:\ORACLE\ORADATA\TEST\REDO03.LOG'  SIZE 1M

DATAFILE

  'D:\ORACLE\ORADATA\TEST\SYSTEM01.DBF',

  'D:\ORACLE\ORADATA\TEST\RBS01.DBF',

  'D:\ORACLE\ORADATA\TEST\USERS01.DBF',

  'D:\ORACLE\ORADATA\TEST\TEMP01.DBF',

  'D:\ORACLE\ORADATA\TEST\TOOLS01.DBF',

  'D:\ORACLE\ORADATA\TEST\INDX01.DBF'

CHARACTER SET ZHS16GBK;

-- Recovery is required if any of the datafiles are restored backups,

-- or if the last shutdown was not normal or immediate.

RECOVER DATABASE

--if the last shutdown was not normal or immediate

--noarchive

-- RECOVER DATABASE UNTIL CANCELUSING BACKUP CONTROLFILE

--archive

-- RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

-- Database can now be opened normally.

ALTER DATABASE OPEN;

--if recover database until cancel

--ALTER DATABASE OPEN RESETLOGS;

6、如果没有错误，数据库将启动到open状态下。

说明：

1、重建控制文件用于恢复全部数据文件的损坏，需要注意其书写的正确性，保证包含了所有的数据文件与联机日志

2、经常有这样一种情况，因为一个磁盘损坏，我们不能再恢复(store)数据文件到这个磁盘，因此在store到另外一个盘的时候，我们就必须重新创建控制文件，用于识别这个新的数据文件，这里也可以用这种方法用于恢复

5.3 损坏回滚数据文件的恢复方法

回滚段表空间中的一个数据文件丢失或者损坏导致数据库无法识别它，在启动数据库的时候会出现ORA-1157, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7360。在关闭数据库的时候(normal或者immediate)会出现ORA-1116, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7368。

感谢coolyl的辛勤工作，关于回滚段的大部分内容都是摘自他在itpub的文章。

5.3.1 损坏数据文件，但数据库处于Open状态

如果你发现有回滚段的数据文件丢失或者损坏了，而此时的数据库是处于打开的状态下并且在运行，就千万不要关闭数据库了，因为在大多数的情况下打开的时候比关闭的时候好解决问题一些。

一般也是存在有两种情况：

A。是offline丢失或损坏的数据文件，然后从一个备份中恢复，执行介质恢复以保持一致性。但是这种情况要求数据库是归档方式下才可以采用的。

B。是offline那个存在丢失或损坏的数据文件所在的整个回滚段表空间，然后删除整个回滚段表空间并重建，但是你必须要杀掉那些在回滚段中已经激活的用户进程才可以offline的。

通常第一种情况就比较简单实现，但是更多的用户事务将会出错并且回滚。

A的具体步骤：

1。offline丢失或损坏的数据文件

ALTER DATABASE DATAFILE '' OFFLINE;

2。从一个有效的备份中恢复。

3。执行以下查询

SELECT V1.GROUP#, MEMBER, SEQUENCE#

FROM V$LOG V1, V$LOGFILE V2

WHERE V1.GROUP# = V2.GROUP# ;

这个将列出你的所有redolog文件以及它们所代表的sequence numbers。

4。恢复数据文件。

RECOVER DATAFILE ''

5。确信你应用了所有的redolog文件，直至出现提示信息"Media recovery complete"。

6。online那个数据文件。

ALTER DATABASE DATAFILE '' ONLINE;

B的具体步骤：

1。offline存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段。

ALTER ROLLBACK SEGMENT OFFLINE;

2。检测当然回滚段的状态。

SELECT SEGMENT_NAME, STATUS FROM DBA_ROLLBACK_SEGS

WHERE TABLESPACE_NAME = '';

3。删除所有offline的回滚段

DROP ROLLBACK SEGMENT ;

4。处理那些online状态的回滚段。

重新执行第二步的查询

如果你已经执行过offline操作的回滚段状态仍然是online，则说明这个回滚段内有活动的事务。你要接着查询

SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS

FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS

WHERE TABLESPACE_NAME = '' AND SEGMENT_ID = USN;

如果没有返回结果，则证明存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段都已经被offline了，然后重新执行第二步，第三步。如果查询有结果返回，则状态应该是"PENDING OFFLINE".接着查看ACTIVE_TX列，如果值为0，则表明此回滚段中已经没有未处理的事务了，很快就会被offline的，然后等它offline后重新执行2，3步后跳至第六步。如果值大于0，则继续到第五步。

5。强制那些包含活动事务的回滚段offline。

活动的事务应该被提交或者回滚，执行下面的查询看看哪些用户占用了回滚段：

SELECT S.SID, S.SERIAL#, S.USERNAME, R.NAME "ROLLBACK"

FROM V$SESSION S, V$TRANSACTION T, V$ROLLNAME R

WHERE R.NAME IN ('', ... , '')

AND S.TADDR = T.ADDR AND T.XIDUSN = R.USN;

最好能直接联系到那些user让他们自己去回滚或者提交事务，如果不能做到的话，那就只能强制性的杀掉进程了。

ALTER SYSTEM KILL SESSION ', ';

杀掉进程后再过一段时间后回滚段会自动清除那些事务，然后就可以回到第二步继续查询了。

6。删除回滚段。

DROP TABLESPACE INCLUDING CONTENTS;

7。重建回滚段并online它们

说明：

   1、数据库如果是open状态，就可以直接在open状态下解决问题，没有必要停下数据库，增加down机时间

   2、不管上上面那种恢复方法都是正常性的恢复，不会引起数据的不一致或错误。

5.3.2数据库关闭，但是数据文件中没有活动事务

这种情况下最简单的方法就是offline drop掉这个坏了的或者丢失的数据文件，然后以restricted模式打开数据库然后删除并且重建包含损坏文件的回滚段表空间。

具体步骤如下：

1。确定数据库是正常的关闭的。方法是可以去查看alert文件，到最后看是否有如下信息：

"alter database dismount

Completed: alter database dismount"

如果有的话，就证明数据库是正常关闭的，否则就不能用这个方法去恢复。

2。修改init参数文件，移去ROLLBACK_SEGMENTS中包含的损坏数据文件的回滚段表空间的回滚段，如果你不能确定哪些回滚段是坏的，简单的方法是你可以注释掉整个ROLLBACK_SEGMENTS。

3。以restricted模式去mount数据库。

STARTUP RESTRICT MOUNT

4。offline drop掉那个坏的数据文件

ALTER DATABASE DATAFILE '' OFFLINE DROP;

5。打开数据库

ALTER DATABASE OPEN

如果你看到如下信息"Statement processed"，则跳到第7步，如果你看到ORA-604, ORA-376, and ORA-1110的错误信息，继续第6步。

6。正常的关闭数据库，然后在init文件中注释掉ROLLBACK_SEGMENTS，并加入隐含参数

_corrupted_rollback_segments = ( ,...., )

然后以restricted模式打开数据库

STARTUP RESTRICT

7。删除掉那个包含损坏文件的回滚段表空间。

DROP TABLESPACE INCLUDING CONTENTS;

8。重建回滚段表空间，记得创建后要把回滚段都online。

9。重新使数据库对所有用户可用。

ALTER SYSTEM DISABLE RESTRICTED SESSION;

10。然后正常关闭数据库，修改init文件，如果开始只是注释掉了ROLLBACK_SEGMENTS的，就去掉注释即可，如果加了隐含参数的，注释掉它，并在ROLLBACK_SEGMENTS加入所有的回滚段。

11。正常启动数据库。

Startup

说明：

1、这种方法的前提条件是数据库是正常关闭（不是abort）可用

2、这种方法是正常方法，不会引起数据错误