环境：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.