昨天晚上生产库要做升级，从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>startupupgradepfile='/home/oracle/update/initdb1.ora';
ORACLEinstancestarted.

TotalSystemGlobalArea6.8413E+10bytes
FixedSize2222664bytes
VariableSize4966057400bytes
DatabaseBuffers6.3351E+10bytes
RedoBuffers93634560bytes
Databasemounted.
ORA-01157:cannotidentify/lockdatafile2-seeDBWRtracefile
ORA-01110:datafile2:'/dev/vgdb1ora8/rlvorasysaux'

ALERT日志也有大量的报错

ERROR:clonedbparameternotset.Makesureclonedb=TRUEisset
Errorsinfile/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
ORACLEinstancestarted.

TotalSystemGlobalArea6.8413E+10bytes
FixedSize2199712bytes
VariableSize1.5569E+10bytes
DatabaseBuffers5.2748E+10bytes
RedoBuffers93655040bytes
Databasemounted.
DatabaSEOpened.

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

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

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

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

SYS@db1>startup
ORACLEinstancestarted.

TotalSystemGlobalArea6.8413E+10bytes
FixedSize2199712bytes
VariableSize1.5569E+10bytes
DatabaseBuffers5.2748E+10bytes
RedoBuffers93655040bytes
ORA-00201:controlfileversion11.2.0.4.0incompatiblewithORACLEversion11.2.0.3.0
ORA-00202:controlfile:'/dev/vgdb1ora8/rlvoracontrol01'

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

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

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

恢复过程比较顺利

restorecontrolfilefrom/home/oracle/backup/bak_control_20161227;
alterdatabasemount;
restoretablespacesystem,sysaux,undotbs1;
recoverdatabaseuntilscnxxxxxxxx;
alterdatabaSEOpenresetlogs;

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

sql>startupupgradepfile='/home/oracle/update/initdb1.ora';
ORACLEinstancestarted.

TotalSystemGlobalArea6.8413E+10bytes
FixedSize2222664bytes
VariableSize4966057400bytes
DatabaseBuffers6.3351E+10bytes
RedoBuffers93634560bytes
Databasemounted.
DatabaSEOpened.

于是开始升级数据字典，做后续升级工作，到凌晨2点11.2.0.4升级完成。

那现在问题就是为什么把数据恢复了一下之后就好了呢，通道真的是有坏块？还是其他什么原因，就不得而知了。这个留着问原厂的工程师看有没有好的解释。