11.2.0.3升級到11.2.0.4報錯ORA-01157 ORA-01110

昨天晚上生產庫要做升級，從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升級完成。

那現在問題就是為什么把數據恢復了一下之后就好了呢，通道真的是有壞塊？還是其他什么原因，就不得而知了。這個留著問原廠的工程師看有沒有好的解釋。