共计 3079 个字符，预计需要花费 8 分钟才能阅读完成。
生产库要做升级，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
