11.2.0.3升級(jí)到11.2.0.4報(bào)錯(cuò)ORA-01157 ORA-01110

昨天晚上生產(chǎn)庫(kù)要做升級(jí)，從11.2.0.3升級(jí)到11.2.0.4，但是遇到了ORA-01157 ORA-01110報(bào)錯(cuò)，數(shù)據(jù)庫(kù)無(wú)法startup upgrade。

環(huán)境：HP-UX B.11.31+11.2.0.3+祼設(shè)備,數(shù)據(jù)庫(kù)大小近8T

由于之前做過(guò)一次，也有現(xiàn)成的文檔算是輕車(chē)熟路了，11.2.0.4軟件和補(bǔ)丁已經(jīng)提前打好，停完業(yè)務(wù)之前就開(kāi)始做升級(jí)。

剛開(kāi)始做檢查都比較順利，一直到RMAN備份完成。由于數(shù)據(jù)庫(kù)數(shù)據(jù)量太大，采用把所有業(yè)務(wù)表空間置為read only狀態(tài)，只備份系統(tǒng)相關(guān)表空間(SYSTEM/SYSAUX/UNDOTBS1)的方式來(lái)減少備份時(shí)間。

備份完成記錄當(dāng)前SCN號(hào)，就停數(shù)據(jù)庫(kù)，切到新環(huán)境變量開(kāi)始startup upgrade，升級(jí)數(shù)據(jù)字典

但是實(shí)例在從MOUNT到OPEN狀態(tài)時(shí)報(bào)錯(cuò)

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日志也有大量的報(bào)錯(cuò)

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查相關(guān)錯(cuò)誤，還真有一篇與我們現(xiàn)在的情況類似：ORA-01157 Cannot Identify Lock On Datafile Error During Upgrade (文檔 ID 1917635.1)。但是從文檔描述來(lái)看，說(shuō)是祼設(shè)備有壞塊導(dǎo)致的，但是明明幾分鐘前的shutdown immediate干凈關(guān)閉數(shù)據(jù)庫(kù)的，怎么會(huì)有壞塊，而且，RMAN備份時(shí)也沒(méi)有報(bào)錯(cuò)。

于是關(guān)閉現(xiàn)在的實(shí)例，環(huán)境變量切回到11.2.0.3，啟動(dòng)數(shù)據(jù)庫(kù)，神奇的一幕發(fā)生了，數(shù)據(jù)庫(kù)居然正常啟動(dòng)了

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.

現(xiàn)在情況變的復(fù)雜了，原環(huán)境變量，可以O(shè)PEN數(shù)據(jù)庫(kù)，新的環(huán)境變量就無(wú)法OPEN數(shù)據(jù)庫(kù)。

于是關(guān)閉舊實(shí)例，切到新環(huán)境變量，檢查pfile文件，發(fā)現(xiàn)compatible=11.2.0.3，那會(huì)不會(huì)是這個(gè)的問(wèn)題呢，把這個(gè)參數(shù)改為11.2.0.4，重新啟動(dòng)新實(shí)例，報(bào)錯(cuò)依舊。

打開(kāi)組里老大幫忙看，檢查了vg各種狀態(tài)都是正常，存儲(chǔ)也沒(méi)有異常情況。重新掛載存儲(chǔ)vg，重啟了服務(wù)器，均無(wú)效果。

于是說(shuō)切到舊環(huán)境看看是否還能OPEN，結(jié)果連MOUNT都不行了，下面是報(bào)錯(cuò)信息。

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'

看到報(bào)錯(cuò)信息立馬覺(jué)察到自己掉進(jìn)了自己挖的坑里，前面操作改compatible=11.2.0.4造成的，當(dāng)時(shí)那個(gè)后悔啊。。。這個(gè)參數(shù)升級(jí)完成前不能修改。否則會(huì)給回退帶來(lái)麻煩，就像我這樣。

時(shí)間已經(jīng)到了凌晨1點(diǎn)多，業(yè)務(wù)還要部署新功能上線，留給數(shù)據(jù)庫(kù)的時(shí)間不多了，沒(méi)辦法只能恢復(fù)備份了，好在做了備份，備份重于一切啊！

這里多說(shuō)一句，整個(gè)過(guò)程中也有在baidu上根據(jù)ORA-01157 ORA-01110搜索，找到的解決方法都是把報(bào)錯(cuò)的數(shù)據(jù)文件offline drop，當(dāng)時(shí)心里就在想，如果真有人在生產(chǎn)上這樣搞，那第二天就應(yīng)該是他收拾東西離開(kāi)的日子了。

恢復(fù)過(guò)程比較順利

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;

恢復(fù)完成，舊環(huán)境OPEN成功，心里的一塊石頭算是落地了（最起碼可以恢復(fù)業(yè)務(wù)了），此時(shí)是凌晨1點(diǎn)半。然后跟業(yè)務(wù)溝通數(shù)據(jù)庫(kù)最多還有1個(gè)半小時(shí)的時(shí)間，然后老大說(shuō)要不再試一次升級(jí)，如果不行回退也還來(lái)得及。于是又shutdown舊環(huán)境，啟動(dòng)新環(huán)境(先把pfile里的cpmpatible改為11.2.0.3)，奇跡的事情發(fā)生了，數(shù)據(jù)庫(kù)居然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.

于是開(kāi)始升級(jí)數(shù)據(jù)字典，做后續(xù)升級(jí)工作，到凌晨2點(diǎn)11.2.0.4升級(jí)完成。

那現(xiàn)在問(wèn)題就是為什么把數(shù)據(jù)恢復(fù)了一下之后就好了呢，通道真的是有壞塊？還是其他什么原因，就不得而知了。這個(gè)留著問(wèn)原廠的工程師看有沒(méi)有好的解釋。