Oracle 11.2.0.3升级到11.2.0.4报错ORA-01157 ORA-01110

2017-01-04 10:32:19来源:作者:Linux公社人点击

生产库要做升级,Oracle从11.2.0.3升级到11.2.0.4,但是遇到了ORA-01157 ORA-01110报错,数据库无法startup upgrade。

环境:HP-UX B.11.31+11.2.0.3+祼设备,数据库大小近8T

由于之前做过一次,也有现成的文档算是轻车熟路了,11.2.0.4软件和补丁已经提前打好,停完业务之前就开始做升级。

刚开始做检查都比较顺利,一直到RMAN备份完成。由于数据库数据量太大,采用把所有业务表空间置为read only状态,只备份系统相关表空间(SYSTEM/SYSAUX/UNDOTBS1)的方式来减少备份时间。

备份完成记录当前SCN号,就停数据库,切到新环境变量开始startup upgrade,升级数据字典

但是实例在从MOUNT到OPEN状态时报错

SQL> startup upgrade pfile='/home/oracle/update/initdb1.ora';

ORACLE instance started.

Total System Global Area 6.8413E+10 bytes

Fixed Size 2222664 bytes

Variable Size 4966057400 bytes

Database Buffers 6.3351E+10 bytes

Redo Buffers 93634560 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 2 - see DBWR trace file

ORA-01110: data file 2: '/dev/vgdb1ora8/rlvorasysaux'

ALERT日志也有大量的报错

ERROR: clonedb parameter not set. Make sure clonedb=TRUE is set

Errors in file /oracle11g/app/oracle/diag/rdbms/db1/db1/trace/db1_dbw0_20898.trc:

ORA-01157: ????/?????? 2 - ??? DBWR ????

ORA-01110: ???? 2: '/dev/vgdb1ora8/rlvorasysaux'

ORA-17503: ksfdopn: 1 ?????? /dev/vgdb1ora8/rlvorasysaux

ORA-17515: ???????? clonedb ???

......

于是到MOS查相关错误,还真有一篇与我们现在的情况类似:ORA-01157 Cannot Identify Lock On Datafile Error During Upgrade (文档 ID 1917635.1)。但是从文档描述来看,说是祼设备有坏块导致的,但是明明几分钟前的shutdown immediate干净关闭数据库的,怎么会有坏块,而且,RMAN备份时也没有报错。

于是关闭现在的实例,环境变量切回到11.2.0.3,启动数据库,神奇的一幕发生了,数据库居然正常启动了

SYS@db1> startup

ORACLE instance started.

Total System Global Area 6.8413E+10 bytes

Fixed Size 2199712 bytes

Variable Size 1.5569E+10 bytes

Database Buffers 5.2748E+10 bytes

Redo Buffers 93655040 bytes

Database mounted.

Database opened.

现在情况变的复杂了,原环境变量,可以OPEN数据库,新的环境变量就无法OPEN数据库。

于是关闭旧实例,切到新环境变量,检查pfile文件,发现compatible=11.2.0.3,那会不会是这个的问题呢,把这个参数改为11.2.0.4,重新启动新实例,报错依旧。

打开组里老大帮忙看,检查了vg各种状态都是正常,存储也没有异常情况。重新挂载存储vg,重启了服务器,均无效果。

于是说切到旧环境看看是否还能OPEN,结果连MOUNT都不行了,下面是报错信息。

SYS@db1> startup

ORACLE instance started.

Total System Global Area 6.8413E+10 bytes

Fixed Size 2199712 bytes

Variable Size 1.5569E+10 bytes

Database Buffers 5.2748E+10 bytes

Redo Buffers 93655040 bytes

ORA-00201: control file version 11.2.0.4.0 incompatible with ORACLE version 11.2.0.3.0

ORA-00202: control file: '/dev/vgdb1ora8/rlvoracontrol01'

看到报错信息立马觉察到自己掉进了自己挖的坑里,前面操作改compatible=11.2.0.4造成的,当时那个后悔啊。。。这个参数升级完成前不能修改。否则会给回退带来麻烦,就像我这样。

时间已经到了凌晨1点多,业务还要部署新功能上线,留给数据库的时间不多了,没办法只能恢复备份了,好在做了备份,备份重于一切啊!

这里多说一句,整个过程中也有在baidu上根据ORA-01157 ORA-01110搜索,找到的解决方法都是把报错的数据文件offline drop,当时心里就在想,如果真有人在生产上这样搞,那第二天就应该是他收拾东西离开的日子了。

恢复过程比较顺利

restore controlfile from /home/oracle/backup/bak_control_20161227;

alter database mount;

restore tablespace system,sysaux,undotbs1;

recover database until scn xxxxxxxx;

alter database open resetlogs;

恢复完成,旧环境OPEN成功,心里的一块石头算是落地了(最起码可以恢复业务了),此时是凌晨1点半。然后跟业务沟通数据库最多还有1个半小时的时间,然后老大说要不再试一次升级,如果不行回退也还来得及。于是又shutdown旧环境,启动新环境(先把pfile里的cpmpatible改为11.2.0.3),奇迹的事情发生了,数据库居然OPEN成功了。

SQL> startup upgrade pfile='/home/oracle/update/initdb1.ora';

ORACLE instance started.

Total System Global Area 6.8413E+10 bytes

Fixed Size 2222664 bytes

Variable Size 4966057400 bytes

Database Buffers 6.3351E+10 bytes

Redo Buffers 93634560 bytes

Database mounted.

Database opened.

更多Oracle相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

本文永久更新链接地址 : http://www.linuxidc.com/Linux/2017-01/139043.htm

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台