/ /
环境简介：操作系统： Windows XP数据库版本： 10.2.0.1归档模式： 非归档策略： 没有任何的备份策略，无备份可用用途： 数据库【故障描述】今天在启动本机测试用数据库时惊现数据库无法启动，提示如下：C:\>sqlplus / as sysdbaSQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 16 18:25:43 2009Copyright (c) 1982, , Oracle. All rights reserved.Connected to an idle instance.SQL> startup;ORACLE instance started.Total System Global Area 167772160 bytesFixed Size 1247876 bytesVariable Size 75498876 bytesDatabase Buffers 83886080 bytesRedo Buffers 7139328 bytesDatabase mounted.ORA-00313: open failed for members of log group 1 of thread 1ORA-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 3SQL> alter database clear logfile group 2;Database altered.SQL> alter database clear logfile group 3;Database altered.此时查看日志文件所在的目录会依次恢复出两个50M的日志文件REDO02.LOG和REDO03.LOG（注释：如果是该日志组还没有归档，则需要用如下的命令进行操作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 1ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\REDO01.LOG'ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) The system cannot find the file specified.4.设置隐含参数_allow_resetlogs_corruption为“TRUE”生成pfileSQL> create pfile from spfile;File created.停掉数据库SQL> shutdown immediate;ORA-01109: database not openDatabase dismounted.ORACLE instance shut down.在生成的pfile（对应文件是C:\oracle\product\10.2.0\db_1\database\INITsec.ORA）最后一行添加如下内容，保存退出_allow_resetlogs_corruption=TRUE5.使用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 bytesFixed Size 1247876 bytesVariable Size 75498876 bytesDatabase Buffers 83886080 bytesRedo Buffers 7139328 bytesDatabase mounted.6.利用until cancel进行恢复SQL> recover database until cancel;ORA-00279: change 274548 generated at 06/16/2009 19:15:54 needed for thread 1ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\SEC\ARCHIVELOG\2009_06_16\O1_MF_1_1_%U_.ARCORA-00280: change 274548 for thread 1 is in sequence #1Specify log: {<RET>=suggested | filename | AUTO | CANCEL}cancelORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error belowORA-01194: file 1 needs more recovery to be consistentORA-01110: data file 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\SYSTEM01.DBF'ORA-01112: media recovery not started7.resetlogs方式打开数据库SQL> alter database open resetlogs;Database altered.这时在日志文件所在的目录中就可以看到被恢复出来的当前联机日志REDO01.LOG8.到此，恢复过程完成，后续任务一：进行全库的EXP备份C:\>exp system/system file=exp_full_backup.dmf log=exp_full_backup.log full=y9.后续任务二：取消隐含参数_all_resetlogs_corrupt10.后续任务三：重建数据库11.后续任务四：使用IMP将刚刚备份的文件导入到数据库中12.检查一下是否有无效的对象，处理之13.搞定！【总结】针对这个测试库，如果我有备份，恢复过程将大大简化，也许只需要此恢复过程的1/10时间。所以，请每一位亲爱的DBA记住，为了缩短故障时间，最有效的方法就是——————备份！制定有效的备份策略，即便这个数据库仅仅用于测试和娱乐。