《Oracle 12c升級檢查問題分析》要點：
本文介紹了Oracle 12c升級檢查問題分析，希望對您有用。如果有疑問，可以聯系我們。

今天計劃把一個測試環境升級到12c,為了練練手,先在備庫上來做.數據庫版本是11.2.0.3.0,計劃升級到12.1.0.2.0.

為了不影響原有的測試主庫,我在備庫上做了Failover,兩個命令下去就立刻生效了.

SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY

SQL>alter database recover managed standby database finish force;
Database altered.

SQL>alter database commit to switchover to primary;
Database altered.

然后使用克隆安裝12c的數據庫軟件,使用下面的命令即可安裝.

$ORACLE_HOME/clone/bin/perl clone.pl ORACLE_BASE=$ORACLE_BASE ORACLE_HOME=$ORACLE_HOME? ORACLE_HOME_NAME=OraDb12c_home1

查看數據庫已經部署了最新的補丁

$ opatch lsinventory
...
Patch? 23054246???? : applied on Mon Oct 17 17:01:16 CST 2016
Unique Patch ID:? 20464632
Patch description:? "Database Patch Set Update : 12.1.0.2.160719 (23054246)"
?? Created on 5 Jul 2016, 07:07:59 hrs PST8PDT

看了下官方文檔,發現對于12c的升級和升級11g差別不大,手工升級的步驟很多腳本都是一樣的,思路完全可以復用.

升級前的檢查需要跑一個腳本/preupgrd.sql

本來想速戰速決,沒想到檢查的時候竟然拋出了一個錯誤.

DECLARE
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 1003 - see DBWR trace file
ORA-01110: data file 1003: '+DATA'
ORA-06512: at "SYS.DBMS_PREUP", line 2380
ORA-06512: at "SYS.DBMS_PREUP", line 981
ORA-06512: at "SYS.DBMS_PREUP", line 5471
ORA-06512: at line 73? 

這個錯誤看得我有些懵,因為我這個備庫是沒有使用ASM的,怎么會拋出和ASM相關的錯誤呢.

查看參數文件里面,倒是有一行這樣的內容

*.db_file_name_convert='+DATA/sgstatdb3/datafile','/U01/app/oracle/oradata/statdb2','+ARCH','/U01/app/oracle/oradata/statdb2','/U01/....

可見原來的主庫是使用了ASM,但是在備庫端壓根沒有用到,怎么會拋出這個錯誤呢.

查看alert日志,發現這個錯誤還挺特別.

Mon Oct 31 22:27:02 2016
WARNING: ASM communication error: op 36 state 0x40 (15077)
ERROR: slave communication error with ASM
Mon Oct 31 22:28:56 2016
WARNING: ASM communication error: op 36 state 0x40 (15077)
ERROR: slave communication error with ASM
Mon Oct 31 22:30:00 2016
Thread 1 advanced to log sequence 3 (LGWR switch)

從錯誤日志可以看出,是在和ASM實例通信的時候出問題了.這個環境壓根沒有用ASM,肯定出問題了.

看錯誤是文件1003,查看v$datafile,文件號最大才是800多,怎么會冒出一個1003的文件呢.繼續查看alert日志,發現1001也有問題,看來有問題的還不止一個文件,但是數據庫Open沒有任何問題.

Dictionary check beginning
Mon Oct 31 22:05:05 2016
Errors in file /U01/app/oracle/diag/rdbms/sstatdb2/statdb2/trace/statdb2_dbw0_27706.trc:
ORA-01186: file 1001 failed verification tests
ORA-01157: cannot identify/lock data file 1001 - see DBWR trace file
ORA-01110: data file 1001: '+DATA'
File 1001 not verified due to error ORA-01157

腦袋里盤算著,一邊翻找日志,發現數據庫啟動的時候拋出了下面的錯誤.

Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Cannot re-create tempfile +DATA, the same name file exists
Cannot re-create tempfile +DATA, the same name file exists
Cannot re-create tempfile +DATA, the same name file exists

如此一來,問題就很明顯了,臨時表空間的文件映射存在問題,導致沒有創建成功,而臨時文件有無不會影響數據庫的啟動,所以這個問題就這樣暫時擱置下來了.

進一步驗證,可以看到存著多個臨時文件

SQL> SELECT FILE#,NAME FROM V$TEMPFILE
???? FILE# NAME
---------- ------------------------------
???????? 3 +DATA
???????? 4 +DATA
???????? 1 +DATA
???????? 2 +DATA
???????? 5 +DATA
???????? 6 +DATA
???????? 7 +DATA

同時使用dba_temp_files會直接拋出之前的錯誤.

SQL> select file_name from dba_temp_files;
select file_name from dba_temp_files
????????????????????? *
ERROR at line 1:
ORA-01157: cannot identify/lock data file 1003 - see DBWR trace file
ORA-01110: data file 1003: '+DATA'

問題的原因找到了,解決起來就很容易了.我們可以重新創建一個臨時表空間,然后刪除原來的.

SQL> create temporary tablespace temp1 tempfile '/U01/app/oracle/oradata/statdb2/temp01.dbf' size 100M;
Tablespace created.

SQL> alter database default temporary tablespace temp1;
Database altered.

SQL> drop tablespace temp including contents and datafiles;
Tablespace dropped.

后臺會繼續檢查+DATA這個不存在的虛擬存儲,然后最終從數據字典層面統一這些信息.

再次做升級前的檢查,就沒有任何問題了.

作者：楊建榮

文章出處：楊建榮的學習筆記(訂閱號ID：jianrong-notes)

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4400.html