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這個不存在的虛擬儲存，然後最終從資料字典層面統一這些資訊。

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