昨天晚上生产库要做升级,从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.
于是开始升级数据字典,做后续升级工作,到凌晨2点11.2.0.4升级完成。
那现在问题就是为什么把数据恢复了一下之后就好了呢,通道真的是有坏块?还是其他什么原因,就不得而知了。这个留着问原厂的工程师看有没有好的解释。