[转]ORACLE联机日志文件无故全部消失
http://space.itpub.net/519536/viewspace-606533
数据库环境简介：
操作系统： Windows XP
数据库版本： Oracle 10.2.0.1
归档模式： 非归档
备份策略： 没有任何的备份策略，无备份可用
用途： 测试数据库
【故障描述】
今天在启动本机测试用数据库时惊现数据库无法启动，提示如下：
C:\>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 16 18:25:43 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 75498876 bytes
Database Buffers 83886080 bytes
Redo Buffers 7139328 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\REDO01.LOG'
SQL>
如上提示，系统找不到联机日志文件，一身冷汗，就算是测试数据库也不能就这样“挂”了啊！
顺着错误提示的目录，进入到日志文件所在的目录，哇塞，全部的日志文件都不见了！（现在想想，可能是因为这个测试数据库我好久没有问津了，也许在某一次的C盘文件批量整理的过程中连带这些重要的文件一同“整理”掉了），心中不免有些紧张，转念一想幸好是测试数据库，释然一下下，于是……我决定————恢复之，现把整个的恢复过程记录如下，希望屏幕前的您不要再犯我这样的错误了，作为一位DBA是绝对不应该允许自己犯这样的错误，即使是纯纯的测试数据库。
【故障分析】
因为是全部的日志文件都被删除了，所以既包含当前联机日志，也包含非当前联机日志，我恢复的顺序是：先通过Clear的方式恢复非当前联机日志，再通过设置隐含参数_allow_resetlogs_corruption=TRUE的方式恢复当前联机日志（使用这种极端的恢复方式是我不想看到的，没有办法，谁叫我没有备份呢，找了半天连冷备都没做过。如果您有备份，记住要优先考虑使用备份进行恢复）。
【故障处理】
1.通过v$log视图确定哪些是当前联机日志和非当前联机日志
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
------- ------- ---------- -------- ------- --- -------- ------------- ---------
1 1 2 52428800 1 NO CURRENT 272945 16-JUN-09
3 1 1 52428800 1 NO INACTIVE 252940 16-JUN-09
2 1 0 52428800 1 YES UNUSED 0
确定如下：
group 1是当前联机日志
group 2 和group 3是非当前联机日志
2.通过Clear方式恢复非当前联机日志group 2 和group 3
SQL> alter database clear logfile group 2;
Database altered.
SQL> alter database clear logfile group 3;
Database altered.
此时查看日志文件所在的目录会依次恢复出两个50M的日志文件REDO02.LOG和REDO03.LOG
（注释：如果是该日志组还没有归档，则需要用如下的SQL命令进行操作
alter database clear unarchived logfile group 2;）
3.恢复当前联机日志 group 1，先演示确认一下通过clear的方式无法恢复当前联机日志
SQL> alter database clear logfile group 1;
alter database clear logfile group 1
*
ERROR at line 1:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
4.设置隐含参数_allow_resetlogs_corruption为“TRUE”
生成pfile
SQL> create pfile from spfile;
File created.
停掉数据库
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
在生成的pfile（对应文件是C:\oracle\product\10.2.0\db_1\database\INITsec.ORA）最后一行添加如下内容，保存退出
_allow_resetlogs_corruption=TRUE
5.使用pfile启动数据库到mount状态
SQL> startup mount pfile=C:\oracle\product\10.2.0\db_1\database\INITsec.ORA;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 75498876 bytes
Database Buffers 83886080 bytes
Redo Buffers 7139328 bytes
Database mounted.
6.利用until cancel进行恢复
SQL> recover database until cancel;
ORA-00279: change 274548 generated at 06/16/2009 19:15:54 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\SEC\ARCHIVELOG\2009_06_16\O1_MF_1_1_%U_.ARC
ORA-00280: change 274548 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\SYSTEM01.DBF'
ORA-01112: media recovery not started
7.resetlogs方式打开数据库
SQL> alter database open resetlogs;
Database altered.
这时在日志文件所在的目录中就可以看到被恢复出来的当前联机日志REDO01.LOG
8.到此，恢复过程完成，后续任务一：进行全库的EXP备份
C:\>exp system/system file=exp_full_backup.dmf log=exp_full_backup.log full=y
9.后续任务二：取消隐含参数_all_resetlogs_corrupt
10.后续任务三：重建数据库
11.后续任务四：使用IMP将刚刚备份的文件导入到数据库中
12.检查一下是否有无效的对象，处理之
13.搞定！
【总结】
针对这个测试库，如果我有备份，恢复过程将大大简化，也许只需要此恢复过程的1/10时间。
所以，
请每一位亲爱的DBA记住，为了缩短故障时间，最有效的方法就是——————备份！制定有效的备份策略，即便这个数据库仅仅用于测试和娱乐。
操作系统： Windows XP
数据库版本： Oracle 10.2.0.1
归档模式： 非归档
备份策略： 没有任何的备份策略，无备份可用
用途： 测试数据库
【故障描述】
今天在启动本机测试用数据库时惊现数据库无法启动，提示如下：
C:\>sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 16 18:25:43 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 75498876 bytes
Database Buffers 83886080 bytes
Redo Buffers 7139328 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\REDO01.LOG'
SQL>
如上提示，系统找不到联机日志文件，一身冷汗，就算是测试数据库也不能就这样“挂”了啊！
顺着错误提示的目录，进入到日志文件所在的目录，哇塞，全部的日志文件都不见了！（现在想想，可能是因为这个测试数据库我好久没有问津了，也许在某一次的C盘文件批量整理的过程中连带这些重要的文件一同“整理”掉了），心中不免有些紧张，转念一想幸好是测试数据库，释然一下下，于是……我决定————恢复之，现把整个的恢复过程记录如下，希望屏幕前的您不要再犯我这样的错误了，作为一位DBA是绝对不应该允许自己犯这样的错误，即使是纯纯的测试数据库。
【故障分析】
因为是全部的日志文件都被删除了，所以既包含当前联机日志，也包含非当前联机日志，我恢复的顺序是：先通过Clear的方式恢复非当前联机日志，再通过设置隐含参数_allow_resetlogs_corruption=TRUE的方式恢复当前联机日志（使用这种极端的恢复方式是我不想看到的，没有办法，谁叫我没有备份呢，找了半天连冷备都没做过。如果您有备份，记住要优先考虑使用备份进行恢复）。
【故障处理】
1.通过v$log视图确定哪些是当前联机日志和非当前联机日志
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
------- ------- ---------- -------- ------- --- -------- ------------- ---------
1 1 2 52428800 1 NO CURRENT 272945 16-JUN-09
3 1 1 52428800 1 NO INACTIVE 252940 16-JUN-09
2 1 0 52428800 1 YES UNUSED 0
确定如下：
group 1是当前联机日志
group 2 和group 3是非当前联机日志
2.通过Clear方式恢复非当前联机日志group 2 和group 3
SQL> alter database clear logfile group 2;
Database altered.
SQL> alter database clear logfile group 3;
Database altered.
此时查看日志文件所在的目录会依次恢复出两个50M的日志文件REDO02.LOG和REDO03.LOG
（注释：如果是该日志组还没有归档，则需要用如下的SQL命令进行操作
alter database clear unarchived logfile group 2;）
3.恢复当前联机日志 group 1，先演示确认一下通过clear的方式无法恢复当前联机日志
SQL> alter database clear logfile group 1;
alter database clear logfile group 1
*
ERROR at line 1:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
4.设置隐含参数_allow_resetlogs_corruption为“TRUE”
生成pfile
SQL> create pfile from spfile;
File created.
停掉数据库
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
在生成的pfile（对应文件是C:\oracle\product\10.2.0\db_1\database\INITsec.ORA）最后一行添加如下内容，保存退出
_allow_resetlogs_corruption=TRUE
5.使用pfile启动数据库到mount状态
SQL> startup mount pfile=C:\oracle\product\10.2.0\db_1\database\INITsec.ORA;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 75498876 bytes
Database Buffers 83886080 bytes
Redo Buffers 7139328 bytes
Database mounted.
6.利用until cancel进行恢复
SQL> recover database until cancel;
ORA-00279: change 274548 generated at 06/16/2009 19:15:54 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\SEC\ARCHIVELOG\2009_06_16\O1_MF_1_1_%U_.ARC
ORA-00280: change 274548 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\SYSTEM01.DBF'
ORA-01112: media recovery not started
7.resetlogs方式打开数据库
SQL> alter database open resetlogs;
Database altered.
这时在日志文件所在的目录中就可以看到被恢复出来的当前联机日志REDO01.LOG
8.到此，恢复过程完成，后续任务一：进行全库的EXP备份
C:\>exp system/system file=exp_full_backup.dmf log=exp_full_backup.log full=y
9.后续任务二：取消隐含参数_all_resetlogs_corrupt
10.后续任务三：重建数据库
11.后续任务四：使用IMP将刚刚备份的文件导入到数据库中
12.检查一下是否有无效的对象，处理之
13.搞定！
【总结】
针对这个测试库，如果我有备份，恢复过程将大大简化，也许只需要此恢复过程的1/10时间。
所以，
请每一位亲爱的DBA记住，为了缩短故障时间，最有效的方法就是——————备份！制定有效的备份策略，即便这个数据库仅仅用于测试和娱乐。
