Oracle集群断电恢复实例（续）

上一篇 Oracle集群断电恢复 介绍了当Redo日志没有损坏的情况下如何进行恢复的实例，本文介绍当Redo日志损坏的情况下如何进行恢复。

按照上一篇文章进行恢复时，当进行到日志重做时，如果出现以下情况，则可判断日志文件已经损坏了。

SQL> recover database until cancel using backup controlfile;
ORA-00279: change 89774677 generated at 07/08/2016 21:00:54 needed for thread 1
ORA-00289: suggestion : /work/11.2.0.4/oracle/db/dbs/arch1_493_898210382.dbf
ORA-00280: change 89774677 for thread 1 is in sequence #493

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+DATA/orcl/ONLINELOG/group_6.288.898210555
ORA-00326: log begins at change 90628357, need earlier change 89774677
ORA-00334: archived log: '+DATA/orcl/onlinelog/group_6.288.898210555'


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: '+DATA/orcl/datafile/system.275.898210283'

此时需要修改Oracle的启动参数，允许进行强制修改同步标志。

首先从spfile生成pfile

SQL> startup mount
ORACLE instance started.

Total System Global Area 1.0796E+11 bytes
Fixed Size                  2266024 bytes
Variable Size            6.0935E+10 bytes
Database Buffers         4.6976E+10 bytes
Redo Buffers               50450432 bytes
Database mounted.
SQL> create pfile='/tmp/pfile27.ora' from spfile;

File created.

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.

然后修改pfile文件，增加以下内容

*._allow_read_only_corruption=TRUE
*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE

重新用pfile文件启动Oracle实例到mount状态

SQL> startup pfile='/tmp/pfile27.ora' mount
ORACLE instance started.

Total System Global Area 1.0796E+11 bytes
Fixed Size                  2266024 bytes
Variable Size            6.0935E+10 bytes
Database Buffers         4.6976E+10 bytes
Redo Buffers               50450432 bytes
Database mounted.

查询一致性标志的序号

SQL> select checkpoint_change#,to_char(checkpoint_change#,'XXXXXXXXXXXXXXXXX')  from v$database;

CHECKPOINT_CHANGE# TO_CHAR(CHECKPOINT
------------------ ------------------
          90629778            566E692

随便选择一个比当前标志大的数值，转化为16进制表示

SQL> select to_char(91629893,'XXXXXXXXXXXXXXXX') from dual;  

TO_CHAR(91629893,
-----------------
          5762945

开启强制修改模式，用上面这个值覆盖当前的标志位

SQL> oradebug setmypid
Statement processed.
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SQL> oradebug poke 0x06001AE70 8 0x0000000005762945
BEFORE: [06001AE70, 06001AE78) = 00000000 00000000
AFTER:  [06001AE70, 06001AE78) = 05762945 00000000
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 05762945 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000

好了，现在可以打开实例了

SQL> alter database open RESETLOGS;

Database altered.

经过以上操作，数据库实例是正常恢复了，但由于是强制恢复，其中存在数据丢失，undo表空间错误等潜在问题，甚至会出现数据无法插入修改等现象，因此强烈建议重建db，至少要重建undo表空间。