Oracle 当尝试重建控制文件时生成ORA-01503 ORA-01189

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

适用于：

Oracle Database – Enterprise Edition – 版本 11.2.0.1 及以上

本文信息适用于任何平台。
****在16-NOV-2015检查相关性****

症状

由于ORA-16433无法进行恢复：

Sun Aug 17 14:04:07 2014
Media Recovery failed with error 16433
Slave exiting with ORA-283 exception
Errors in file /oradump/prod/edwp/logs/diag/diag/rdbms/edwprod/EDWPROD/trace/EDWPROD_pr00_32964892.trc:
ORA-00283: recovery session canceled due to errors
ORA-16433: The database must be opened in read/write mode.
Recovery Slave PR00 previously exited with exception 283
ORA-283 signalled during: ALTER DATABASE RECOVER  database using backup controlfile until cancel  …

正常情况下，解决方案是重建控制文件。但是尝试重建控制文件时生成以下错误：

CREATE CONTROLFILE REUSE DATABASE “EDWPROD” RESETLOGS  ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01189: file is from a different RESETLOGS than previous files
ORA-01110: data file 2: ‘/ora/prod/edwprod/data/EDWPROD/datafile/o1_mf_undotbs1_334h0kxm_.dbf’

原因

要重建控制文件，所有数据文件必须在相同incarnation或resetlogs 时间。
我们无法使数据文件在不同incarnation。

使用当前控制文件，即之前用于恢复但失败的，我们发现所有数据文件的RESETLOGS_TIME 都是17-AUG-2014 13:28:19，除了datafile# 1：

SQL> select status,checkpoint_change#,checkpoint_time, resetlogs_change#,
2  resetlogs_time, count(*), fuzzy from v$datafile_header
3  group by status,checkpoint_change#,checkpoint_time, resetlogs_change#,
4  resetlogs_time, fuzzy;

STATUS     CHECKPOINT_CHANGE# CHECKPOINT_TIME      RESETLOGS_CHANGE# RESETLOGS_TIME              COUNT(*) FUZ
———- —————— ——————– —————– ————————- ———- —
ONLINE          3645505893814 17-AUG-2014 11:37:33                 1 27-APR-2007 14:07:53               1 NO
ONLINE          3645505893818 17-AUG-2014 13:34:48     3645505897826 17-AUG-2014 13:28:19             156 YES

SQL> select file#, status, checkpoint_change#, checkpoint_time, resetlogs_change#, resetlogs_time, fuzzy from v$datafile_header;

FILE# STATUS     CHECKPOINT_CHANGE# CHECKPOINT_TIME      RESETLOGS_CHANGE# RESETLOGS_TIME            FUZ
——- ———- —————— ——————– —————– ————————- —
1 ONLINE          3645505893814 17-AUG-2014 11:37:33                 1 27-APR-2007 14:07:53      NO
2 ONLINE          3645505893818 17-AUG-2014 13:34:48     3645505897826 17-AUG-2014 13:28:19      YES
…
157 ONLINE          3645505893818 17-AUG-2014 13:34:48     3645505897826 17-AUG-2014 13:28:19      YES

157 rows selected.

解决方案

建议

在重建如下所述的控制文件之前，对当前的控制文件进行操作系统备份是安全之举。

解决问题的步骤：

仅当你有恢复数据库所需的重做日志（归档和/或联机）时，以下方法才能起作用。

1) 仅使用较低incarnation或resetlogs时间的数据文件来重建控制文件。
该列表必须包括系统数据文件。

在之前的示例中，CREATE CONTROLFILE 命令必须有RESETLOGS TIME 为 27-APR-2007 14:07:53的数据文件。
在这里，它会是datafile# 1：

CREATE CONTROLFILE REUSE DATABASE “EDWPROD” RESETLOGS ARCHIVELOG
MAXLOGFILES 40
MAXLOGMEMBERS 3
MAXDATAFILES 200
MAXINSTANCES 8
MAXLOGHISTORY 37744
LOGFILE
GROUP 1 (
‘/ora/prod/edwprod/data/EDWPROD/onlinelog/o1_mf_1_1PN15JjCD_.log’,
‘/ora/prod/edwprod/index/EDWPROD/onlinelog/o1_mf_1_1PN15ZLTY_.log’
) SIZE 1000M BLOCKSIZE 512,
…

  GROUP 12 (
‘/ora/prod/edwprod/data/EDWPROD/onlinelog/o1_mf_12_1PN0wPCV4_.log’,
‘/ora/prod/edwprod/index/EDWPROD/onlinelog/o1_mf_12_1PN0wdYFq_.log’
) SIZE 1000M BLOCKSIZE 512
— STANDBY LOGFILE
DATAFILE
‘/ora/prod/edwprod/data/EDWPROD/datafile/o1_mf_system_334h00q2_.dbf’
CHARACTER SET WE8MSWIN1252
;

2) 一旦控制文件被重建，执行恢复来bring it / rollforward 到新的incarnation：

SQL> recover database using backup controlfile until cancel;

应用请求的（多个）重做日志直到它到新的incarnation

3) 现在再次重建控制文件来包括“ALL Datafiles”。且最后执行所有数据文件的恢复：

SQL> recover database using backup controlfile until cancel;

应用请求的（多个）重做日志以到达所需的时间点

4) 使用resetlogs打开数据库：

SQL> alter database open resetlogs;