手動升級到 Oracle Database 11gR2 (11.2)的完整核對清單 (文件 ID 1674333.1)

適用於:

用途

本文件可用作手工將 Oracle 9iR2 (9.2)， Oracle 10gR1 (10.1)， Oracle 10gR2 (10.2) 或者 Oracle 11gR1 (11.1) 版本資料庫升級至 Oracle 11gR2 (11.2) 版本資料庫的指南與核對表。

適用範圍

資料庫管理人員/技術支援

詳細資訊

推薦在源庫上完成的

1) 在升級前確保所有 oracle 提供的元件和物件都是有效的

2) 除了下面的物件外， 確保在 sys 和 system schema 下沒有重複存在的物件

下面的物件是允許重複的：

 OBJECT_NAME OBJECT_TYPE

3) 禁用所有自定義的 before/after DDL 型別的觸發器，完成升級後再啟用它們

4) 在升級一個安裝了 XDB 元件的資料庫或者安裝 XDB 之前，需要先按照文件 Note 1573175.1 "Upgrading or Installing XDB could result in data loss if XDB_INSTALLATION_TRIGGER exists "  中的程式碼檢查是否需要刪除一些物件. 注意，如果不這麼做的話，可能會引發使用者資料或者使用者物件（如表，索引）的丟失

推薦/需要在目標庫上完成的

• 在下載安裝 11gR2 軟體之前，需要先檢查軟體版本與您的硬體平臺/作業系統是否相容。您可以透過 My Oracle Support 網站來確認這一點。
• 下載安裝 11gR2 軟體到一個新的 ORACLE_HOME 並確認沒有編譯錯誤
• 如果有的話， 安裝最新的補丁集 （PatchSet）
• 如果有的話， 安裝最新的 OPatch （要安裝跟作業系統平臺及資料庫版本一致的 OPatch）
• 如果有的話， 安裝最新的 Critical Patch Update
• 對源庫做備份 （冷備份或熱備份都可以， 推薦冷備份）
• 如果目標庫版本為 11.2.0.2 並且安裝了 XDB， 那麼在升級前需要安裝 patch 10368698。如果沒有當前作業系統對應的這個 patch， 請開 SR 申請. 這個 bug 會使得啟用了 XDB 的資料庫升級時間變得非常長。Bug 10368698 在 11.2.0.3 中被修復。
• 如果目標庫版本為 11.2.0.2 並且安裝了 XDB， 那麼在升級前需要安裝 patch 10419629。請參照文件  Note 1305561.1 While Upgrading From 10.2.0.4.0 To 11.2.0.2.0 Catupgrd.sql=ORA-31061 ORA-19202 LSX-23
• 如果您安裝了 XDB元件， 在升級前需要設定 SHARED_POOL_SIZE = 250M 或更高和 JAVA_POOL_SIZE = 250M 或更高，否則會碰到以下文件中提到的問題。
  Note 1127179.1 ORA-07445 [qmkmgetConfig()+52] During Catupgrd.sql (11.2.0.1).

 如果資料庫使用了 ASMM， 那麼也需要按上面來設定兩個 pool 的大小做為最小值。

• 出於對 11.2.0.2 上效能問題的瞭解，請您參考文件  Note 1320966.1 "Things to Consider Before Upgrade to 11.2.0.2 in Relation to Database Performance"
• 出於對 SQL Profile 相關已知問題的瞭解，請您參考 - SQL PROFILES LOST AFTER UPGRADE ORA-00001 (SYS.I_SQLOBJ$AUXDATA_PKEY) 。當前開發人員仍然在處理這個問題中。 如果下面的語句返回一些行，那麼從 10.2 升級到 11gR2 時會丟失 SQL PROFILE。
  
  select sp.signature, sp.category, count(*) from sqlprof$ sp,sqlprof$desc sd,sql$ s
  where sp.signature = sd.signature(+) and sp.signature = s.signature
  group by sp.signature, sp.category having count(*) > 1;
   
• 假如使用Oracle Text,在11.2.0.4上要意識到有相關問題，請參照 Oracle Text Release 11.2.0.4.0 Mandatory Patches (Doc ID 1608029.1)

• 如果源庫上打了Mitigation Patch 19721304,那麼Oracle JVM元件是被禁用的.您可能在升級資料庫時碰到下面的錯誤:
           

  ORA-02290 - check constraint (SYS.JAVA_DEV_DISABLED) violated.

       在升級資料庫前啟用JVM元件
      

         使用sysdba使用者連線到資料庫
         SQL> exec dbms_java_dev.enable;

           參照：Database Upgrade failed with Errors “ORA-02290: check constraint (SYS.JAVA_DEV_DISABLED) violated” & “ORA-04045: SYS.DBMS_ISCHED” (Doc ID 1985725.1) 

 注意：這步僅僅適用於假如您在原資料庫上應用了遷移補丁        

相容性矩陣

 能夠直接升級到 Oracle 11g Release 2 的資料庫最小版本

以下的資料庫版本需要間接升級：

比如：

如果源庫是 8.1.7.0.0，升級路徑如下：
8.1.7.0.0 --> 8.1.7.4 --> 10.2.0.2（或 10GR2 的其它更高版本）--> 11.2.x。

提醒：

  9.2.0.8 補丁集 （PatchSet）:
10.1.0.5 補丁集 （PatchSet）:
10.2.0.2 補丁集 （PatchSet）:

如果要快速得到各個補丁集對應的補丁號，可以參考下面的兩個文件：
Note 438049.1 : How To Find RDBMS patchsets on My Oracle Support
Note 753736.1 : Quick Reference to Patchset Patch Numbers

升級前步驟

這個部分中的所有步驟都需要在設定了舊的資料庫的環境變數後執行執行，每個步驟都需要執行。源資料庫必須處於正常的狀態。

按照下面的文件下載或使用最新的 Pre-Upgrade Information Tool：
How to Download and Run Oracle's Database Pre-Upgrade Utility Note 884522.1

或者 

直接執行 Pre-Upgrade Information Tool 來收集安裝前需要檢查的資訊

 第1步

• 使用新 11gR2 軟體的所有者使用者登入作業系統。
• 把 11gR2 的 ORACLE_HOME/rdbms/admin 目錄中的 Pre-Upgrade Information Tool （utlu112i.sql）複製到 Oracle Home 以外的一個目錄裡，比如系統的臨時目錄。

如果不執行 pre-upgrade tool （utlu112i.sql） 那麼稍後在執行 catupgrd.sql 指令碼時會碰到下面錯誤：

這時候就只能把升級前備份的資料庫恢復然後再執行 preupgrade tool（utlu112i.sql ）。


第2步

• 進入第1步複製 utlu112i.sql 到的那個臨時目錄中。

• 啟動 sqlplus 並使用 sysdba 許可權連線進入 Oracle 資料庫，執行 utlu112i.sql 檔案並 spool 輸出到一個日誌檔案。注意此時資料庫是使用低版本的 ORACLE_HOME 啟動的。

檢查 spool 的日誌檔案中 Upgrade Information Tool 產生的輸出。
下面的部分解釋了輸出的各個部分的含義。
點選檢視一個Upgrade Information Tool產生的輸出示例。

Database
這部分顯示關於當前資料庫的全域性資訊，比如資料庫名，版本資訊和相容版本（compatibility level）. 如果需要在升級資料庫前更改 COMPATIBLE 初始化引數，警告資訊也在這部分顯示。

Logfiles
這部分顯示當前資料庫中所有比 4MB小 的重做日誌（redo log）檔案。對於這樣的檔案，會顯示檔名， 哪個組的，以及推薦的大小。
在使用 SQL 指令碼及其它工具手工升級資料庫前，所有小於 4MB 的日誌檔案都應該被刪除，新的最小為 4MB（10MB 較好）的日誌檔案需要建立好. 如果使用DBUA升級，那麼這些步驟會被自動完成。

Tablespaces
這部分顯示當前資料庫的 tablespace 相關的資訊。對於每個 tablespace， 都會顯示 tablespace 的名字和升級需要的 tablespace 大小的最小值。另外， 如果滿足升級需要的最小值， 也會有提示資訊。在使用 SQL 指令碼及其它工具手工升級資料庫前， 空閒空間不夠的 tablespace 都應該增加大小。如果使用 DBUA 升級，那麼這些步驟會被自動完成。

Update Parameters
這部分顯示在升級前引數檔案中必須修改的初始化引數。調整的工作必須在把引數檔案複製到新的 11G ORACLE HOME 前完成。

Deprecated Parameters
這部分顯示了所有在初始化引數檔案中已被 11.2 資料庫不推薦使用的引數。
: "Deprecated Initialization Parameters" for a list of initialization parameters that are deprecated in Oracle Database 11g release 2 (11.2).

Obsolete Parameters:
這部分顯示了所有在初始化引數檔案中已被 11.2 資料庫廢棄掉的引數。這些被廢棄的引數需要在升級前從初始化引數檔案中移出。被廢棄的引數在新的 11.2 資料庫中不再有效。
"Obsolete Initialization Parameters" for a list of initialization parameters that are obsolete in Oracle Database 11g release 2 (11.2)

Components
這部分顯示在當前的資料庫被升級後，新的 11.2 資料庫中被升級或者安裝的資料庫元件。

Miscellaneous Warnings
這部分顯示在升級前和升級後其它特定的需要注意的地方。

SYSAUX Tablespace
這部分顯示 SYSAUX tablespace 的最小值， 這個 tablespace 在新的 11.2 資料庫中是必要的。在新的資料庫啟動後但是沒有執行升級指令碼前， 這個 tablespace 如果不存在的話需要被建立 （比如 Oracle9i）。

注意：如果 SYSAUX 是在 9i 資料庫中建立的，那麼在用新的資料庫軟體啟動資料庫後，這個 tablespace 需要被重建. 如果 SYSAUX 是在 10g 或之後版本資料庫中建立的，那麼不需要重建。

為升級資料庫做準備

第3步

檢查源庫的一致性。

在升級前從 My Oracle Support 文件下載並執行 dbupgdiag.sql 指令碼來檢查源庫的一致性：

如果 dbupgdiag.sql 指令碼報告了任何無效物件，則執行 $ORACLE_HOME/rdbms/admin/utlrp.sql（可能需要多次）以使資料庫中的無效物件變為有效，直至無效物件數目不發生變化為止：

使無效物件有效之後，再次在資料庫中重新執行 dbupgdiag.sql，然後確保一切正常。

建議使用hcheck.sql指令碼對資料庫做一個健康檢查,請從下面的文件中下載指令碼. 

Note 136697.1 hcheck.sql" script to check for known problems in Oracle8i, Oracle9i, Oracle10g and Oracle 11g

第4步

棄用的 CONNECT 角色。

在資料庫從 9.2 版本或 10.1 版本升級到 11.2 版本之後， CONNECT 角色就只包含 CREATE SESSION 許可權了；在低版本資料庫中賦予 CONNECT 角色的其它許可權在升級的過程中都被收回了。在你的資料庫找到哪個使用者或者角色被賦予CONNECT角色，可以使用下面的語句：

如果這些使用者或者角色需要除了 CREATE SESSION 以外其它的許可權，可以在升級前顯式的賦予這些許可權。
升級的指令碼會自動調整 ORACLE 提供的使用者的相關許可權。

在 9.2.x 和 10.1.x 資料庫中， CONNECT 角色包含下面的許可權：

從 ORACLE 資料庫 10.2 開始，CONNECT 角色就只包含 CREATE SESSION 許可權了

第5步

為 DBLINK 建立指令碼 （如果升級後的資料庫需要再降級，才需要執行這個步驟）。

在資料庫從 9.2 版本或 10.1 版本升級到 11.2 版本時，所有 dblink 的密碼會被加密。在需要降級資料庫到之前版本的時候， 所有擁有加密的密碼的 dblink 都需要在降級前被刪除掉，因此降級後的資料庫中就沒有 dblink 了。如果有預感這個資料庫還要被降級到之前的版本，那麼從 SYS.LINK$ 表儲存受到影響的 dblink 的資訊，這樣在降級後可以重建這些 dblink：

第6步

檢查 TIMESTAMP WITH TIMEZONE 型別的資料

資料庫 DST patching 在 11gR2 上有了極大的改進，和升級之前的版本（比如從 10.2.0.4 升級到 11.1.0.7）不同， 在升級前不需要再打任何"dst patches"了。

如果把一個低版本的資料庫升級到 11.2， 那麼升級後 DST 的版本應該還和升級前的 DST 版本一致。

但是對於一些特殊的情況，還有一些額外的步驟需要做。根據需要升級到的 11.2 的具體版本不同， 在升級前請一定檢查下面的文件：

Note 1579838.1 :  Actions For DST Updates When Upgrading To Or Applying The 11.2.0.4 Patchset
Note 1358166.1 :  Actions For DST Updates When Upgrading To Or Applying The 11.2.0.3 Patchset
Note 1201253.1 :  Actions For DST Updates When Upgrading To Or Applying The 11.2.0.2 Patchset
Note 815679.1 :   Actions For DST Updates When Upgrading To 11.2.0.1 Base Release

雖然在大部分的情況下不需要做什麼額外的操作，但是穩妥起見還是要遵循上面的文件。

如果文件提到要在升級前對 11gR2 的 ORACLE_HOME 打 DST 補丁，那麼在執行這個文件的其它步驟前，一定先做下面的操作：


確保

返回的資料庫 DST 版本是源資料庫版本的 DST 版本。

如果 select 返回錯誤或者一個其它的版本， 那麼需要重新執行 utlu112i.sql （Pre-Upgrade Information Tool） 指令碼並再次檢查。

第7步

檢查國家字符集（NLS_NCHAR_CHARACTERSET）是否是 UTF8 或者 AL16UTF16。

select value from NLS_DATABASE_PARAMETERS where parameter = 'NLS_NCHAR_CHARACTERSET';

如果返回結果是 UTF8 或者 AL16UTF16，那麼什麼都不需要做了。
如果返回結果不是 UTF8 或者 AL16UTF16，那麼請參考下面的文件：

第8步

最佳化器統計資訊

在升級資料庫到 11gR2 時，會對缺少統計資訊的資料字典收集統計資訊。對於擁有很多資料字典表的資料庫，這個操作可能會很消耗時間. 統計資訊收集的工作隻影響缺少統計資訊的表，或者在升級過程中改變很大的表。

要檢查哪些 schemas 缺少統計資訊，可以檢查 utlu112i.sql 指令碼的輸出或者下載並執行下面文件中的指令碼：

為了減少因為統計資訊收集而造成的停機時間， 可以在升級資料庫之前完成收集統計資訊的工作。對於 10.1 版本的資料庫，ORACLE 推薦使用 DBMS_STATS.GATHER_DICTIONARY_STATS 來收集統計資訊。如，可以使用下面的命令：

對於 9.2 版本的資料庫可以使用 DBMS_STATS.GATHER_SCHEMA_STATS 來收集統計資訊.要完成這個工作，可以使用 中提供的指令碼。

有一個示例指令碼，它會建立 dictstattab 表，並把資料庫相關元件所對應的 schema 的統計資訊匯入到這個表。如果資料庫中缺少某個元件或者相關元件是失效的，那麼這個指令碼可能會報一些錯誤。

如果我們想把這些統計資訊再導回到資料庫中，這個指令碼是很有用的。

比如下面的 PL/SQL 程式碼可以在刪除掉 SYS schema 的統計資訊後再導回：

第9步

禁用 Oracle Database Vault

如果升級的是 10.2 版本的資料庫，並且當前的 ORACLE_HOME 啟用了 Oracle Database Vault， 那麼在升級前必須要把目標 11gR2 資料庫的 Oracle Database Vault 禁用掉，並在升級結束後啟用。
如果 Oracle Database Vault 在升級時是啟用的，那麼 DBUA 會返回一個錯誤要求我們把 Oracle Database Vault 禁用。

我們在升級前必須要把資料庫的 Oracle Database Vault 禁用掉，並在升級結束後再次啟用。

請參照下面的文件來獲得關於禁用/啟用 Oracle Database Vault 的詳細資訊：



或者

參照下面的文件來禁用/啟用 Oracle Database Vault：

第10步

備份 Enterprise Manager Database Control 的資料。如果 Enterprise Manager Database Control 沒有配置或者沒有使用，這個步驟可以忽略。

如果在升級資料庫到 11.2 版本後，有需要把 Oracle Enterprise Manager Database Control 降級，那麼我們必須在升級前備份 Database Control 的檔案才可以. 工具 emdwgrd 可以用來在升級前儲存 Database Control 的資料，這個工具存在於 11.2 版本的資料庫的 ORACLE_HOME/bin 目錄下。

1. 設定 ORACLE_HOME 到舊的資料庫版本
2. 設定 ORACLE_SID 為要升級的資料庫 SID
3. 設定 PATH， LD_LIBRARY_PATH 和 SHLIB_PATH 到舊的 ORACLE_HOME 相關的目錄下

     如 : export SHLIB_PATH=$ORACLE_HOME/lib:$SHLIB_PATH
                    export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
4. 切換目錄到 11gR2 資料庫軟體的 ORACLE_HOME/bin
5. 執行 emdwgrd 命令
   a. 對於單資料庫例項 （非 RAC） 執行下面的命令

old_SID 是要升級的那個資料庫的 SID， save_directory 是用來存放 Database Control 檔案和資料的目錄。

 b. 對於 RAC 資料庫，需要跨節點遠端複製.定義一個環境變數來指向遠端複製的命令。如

注意，如果 10g 資料庫的 ORACLE_HOME 是放在共享儲存上的，那麼上面的命令還需要指定 -shared 引數。

上面的命令可能會在 HPUX 上失敗，這個一個已知問題，請參照下面的文件：

6. 輸入 SYS 使用者的密碼。
注意：在 RAC 資料庫上，還需要在每個節點上執行'/tmp/racdwgrd_dbctl.sh' 。

第11步

配置 Network ACL

Oracle 11gR2 對於使用了 XDB 的 UTL_TCP， UTL_SMTP， UTL_MAIL， UTL_HTTP， 或者 UTL_INADDR 包引入了更加細粒度的訪問控制. 如果你有應用程式用到了這些包，那麼必須安裝 XDB. 在這些包能正常使用前，必須配置網路訪問控制列表（ACLs）。具體的步驟會在第35步提到，因為需要使用的包 DBMS_NETWORK_ACL_ADMIN 是在升級後才有的，升級前沒有。

第12步

這個步驟是選做的，是為了檢查底層表和依賴的表是否有損壞引入的。
這個步驟可以避免稍後在升級過程中因為資料損壞造成的失敗，如果有資料損壞，那麼升級很有可能會失敗。

可以在 sqlplus 使用下面語句檢查資料字典的損壞（connected as sys）：

它會建立一個指令碼 analyze.sql。
現在執行這個指令碼：

這個指令碼（analyze.sql）不應該返回任何錯誤。

注意：
1. 如果存在外部表，那麼可能會發生ORA-30657. 但是根據文件 Note 209355.1 ORA-30657: Using ANALYZE TABLE for an External Table，這個錯誤可以忽略掉。

2. 在執行指令碼時下面這樣的錯誤可以忽略掉：
SP2-0734: unknown command beginning "SQL> SELEC..." - rest of line ignored.
SP2-0042: unknown command "SQL>" - rest of line ignored.
SP2-0734: unknown command beginning "SQL> spool..." - rest of line ignored.

3. 在分析 AWR 相關的表（WRH$_...）可能會返回"ORA-00054： resource busy and acquire with NOWAIT specified"的錯誤。變通方案是把 AWR 臨時禁用。

3.a) 找到當前快照間隔時間（snapshot interval）

3.b) 把快照間隔時間改為 0 來臨時禁用 AWR：

3.c) 分析以 WRH$ 開頭的表

3.d) 把快照間隔時間恢復到原來的值：
   

 

第13步

在升級資料庫前，我們需要確認所有的物化檢視都已經完成了重新整理，並且複製已經停止。
用下面的語句檢查當前是否有物化檢視正在重新整理：

如果第二個語句返回一些行， 請參照文件 Note 1442457.1 : During 11g Upgrade, Mview refresh warning

第14步

確保沒有資料檔案需要介質恢復（media recovery）或處於備份的狀態。

以上的語句不應該有任何返回行。

第15步

密碼保護的角色。

在 11.2 版本的資料庫裡，密碼保護的角色預設是不啟用的。
如果你的程式依賴預設啟用的密碼保護的角色，那麼它無法來使用 set role 命令來啟用密碼。建議刪除這些角色的密碼。
關於更多資訊，請參考下面的文件：

Note 745407.1 : What Roles Can Be Set as Default for a User?
Oracle Database Security Guide 10g Release 2 (10.2) Part Number B14266-07
Oracle Database Security Guide 11g Release 1 (11.1) Part Number B28531-15
Oracle Database Security Guide 11g Release 2 (11.2) Part Number E16543-09


第16步

在升級前把未決的分散式事務處理掉。

如果它有返回行，那麼用下面的命令處理掉未決的分散式事務：

第17步

用下面的命令檢查是否配置了 standby 資料庫：

如果上面的語句有返回行，那麼把相應的 standby 資料庫與主庫進行同步。
1. 確保最後一次 log switch 之後的所有日誌都已經傳輸到 standby 庫中。
2. 在standby庫中，使用NODELAY的選項來恢復standby庫。

第18步

禁用所有的cron job和資料庫。
對於 Oracle 資料庫的 job，可以使用 DBMS_JOB， DBMS_SCHEDULER 去停掉它們；對於 cron job（由 OS 控制的 job）， 需要您的系統管理員來幫忙禁掉它們。

對於使用 DBMS_JOB， DBMS_SCHEDULER，以下文件可以參考：

Note 404238.1 : How to Disable an Entry from DBMS_SCHEDULER
Note 1335741.1 : How To Stop A Running Job Using DBMS_JOB
Note 67695.1 : PROCEDURE DBMS_JOB.BROKEN Specification

第19步

確保 sys 和 system 使用者的預設 tablespace 是 SYSTEM。
必須確保 system tablespace 裡有足夠的空間或者設定成 extents 無限制。

default_tablespace 的值應該是 SYSTEM， 如果不是的話，可以用下面命令糾正。

第20步

確保如果 AUD$ 表存在，它需要屬於 SYS 使用者並存在於 SYSTEM 表空間。

如果在升級前 AUD$ 表不屬於 SYS 使用者或者不存在於 SYSTEM 表空間，那麼需要在升級前把它放回 SYSTEM 表空間並屬於 SYS 使用者。

注意：如果 AUD$ 存在並且非空，那麼表裡的資料的多少會影響升級的效能。

第21步

檢查資料庫是否有外部驗證的的 SSL 使用者（externally authenticated SSL users）。

如果有，那麼在升級後做第33步。

第22步

記下資料檔案，重做日誌和控制檔案的路徑，並且備份所有的配置檔案，如 listener.ora， tnsnames.ora 等等。

第23步

如果你已經升級了 Grid Infrastructure， 那麼這一步可以忽略，因為它已經包含在 Grid Infrastructure 的升級裡了。

a) 停掉資料庫的 listener。

之前版本的 listener 不能用在 11.2 的資料庫上，但是 11.2 的 listener 可以用在之前版本的資料庫上。
如果是從 9i 升級或者手工升級，那麼需要在升級 RAC 資料庫之前執行 netca。

它包含兩個步驟：
需要先執行舊的 Oracle_home 裡的 netca 刪除當前的 listener。
- 執行 Netca
- 選擇配置 => 選擇 Listener Configuration
- 選擇刪除選項 => Delete
- 選擇要刪除的 listener 來刪除它

 然後在新的 ORACLE_HOME 裡執行 netca 來新增新 listener。

- 執行 Netca
- 選擇配置 => 選擇 Listener Configuration
- 選擇新增選項 => Add
- 提供詳細資訊來新增 listener

必須在新增新 listener 之前刪掉舊的，如果新 listener 和舊 listener 用到了相同的名字或者埠號，netca 會返回錯誤。

注意： 如果要手工升級 RAC 資料庫，那麼這一步是必須要做的。

b) 停掉其它的相關程式，如 dbconsole， isqlplus 等。

第24步

停掉資料庫。

備份資料庫

1. 冷備份
或者
2. 使用RMAN備份

--> backup_directory >> 存放資料庫備份的目錄。
--> controlfile_backup_directory >> 存放控制檔案備份的目錄。

第25步

- 從源 ORACLE_HOME 複製初始化引數檔案到目標 ORACLE_HOME/dbs 下（如果是 Windows 平臺，那麼是 ORACLE_HOME/database 目錄）

- 之後修改目標 ORACLE_HOME/dbs 下（如果是Windows平臺，那麼是 ORACLE_HOME/database 目錄）的引數檔案：

註釋掉被廢棄的引數 （），然後修改所有不推薦的引數 （）。

同時建議在升級前刪掉所有手工設定的隱藏引數。

* DIAGNOSTIC_DEST 初始化引數替換掉了 USER_DUMP_DEST， BACKGROUND_DUMP_DEST 兩個初始化引數。

根據 ，CORE_DUMP_DEST 並沒有被廢棄。

要理解 11g 的目錄結構和 DIAGNOSTIC_DEST 引數，請參考下面的文件：

* 如果要從 9.2.0.x 升級到 11gR2， 那麼 COMPATIBLE 引數最小設成 10.0.0 或更大。10.0.0 是可以升級到 11.2 的最小的 COMPATIBLE 引數值。
這個值在升級的過程中不能變，但是可以在升級成功後改成更大的值。
（請注意，一旦這個 COMPATIBLE 引數設定成了 10.1，那麼這個資料庫再也不能降到 9iR2， 參考文件
Note 388604.1 : ORA-00201 while downgrading from 10gR2 to 10gR1 or 9iR2 ）。

Oracle 建議在升級後做完詳細的測試後再加大 COMPATIBLE 引數的值。

如果是從 10.1.0.x 或者 10.2.0.x 升級，可以先不改 COMPATIBLE 的值，在升級完成後再改動。
這樣可以避免一些升級過程中在 smon trace 裡生成 ORA-942 錯誤 （因為升級會檢查一些還未建立的 10.2 的物件）。

* 更改那些 Pre-Upgrade Information Tool 提示需要設定最小值的初始化引數來滿足需要。
確保引數檔案中的目錄名都是使用的絕對路徑而不是相對路徑。

* 如果升級的是 RAC 資料庫，那麼在升級前把 CLUSTER_DATABASE 設定成 false 並在升級後改回成 true。



第26步

如果你的作業系統是 Windows，那麼需要做這一步，如果不是那麼可以忽略掉這一步。

停掉要升級的那個資料庫的服務 OracleServiceSID， SID 是 instance 的名字.比如，如果 SID 是 ORCL，那麼執行下面的命令：

設定相應的環境變數對應到源庫上（9.2/10.1/10.2/11.1）

1. 停掉資料庫服務。

2. 使用 ORADIM 命令刪掉源庫的服務：

3. 用新庫的 ORADIM 工具建立一個 11gR2 的資料庫 service：

第27步

如果你的作業系統是 UNIX，那麼需要做這一步，如果不是那麼可以忽略掉這一步。

1. 確認下面的環境變數指向了新版本資料庫的目錄：

- ORACLE_BASE
- ORACLE_HOME
- PATH, LD_LIBRARY_PATH , SHLIB_PATH  and LIBPATH ( for AIX )

注意： 如果不知道 ORACLE_BASE， 在 PATH 變數包含了 11gR2的Oracle Home 之後，執行 'orabase' 會提示 ORACLE_BASE 的值。

注意： 如果設定了 ORA_TZFILE 環境變數，需要刪掉這個環境變數。

2. 更改 /etc/oratab 檔案，讓 ORCL 指向新的 ORACLE_HOME 並且禁用自動啟動。

注意： 在改掉 /etc/oratab 之後可以使用 oraenv （/usr/local/bin/oraenv）來設定新的環境變數，需要輸入 /etc/oratab 中的指向 11gR2 的那個 SID。

比如：

第27a步

假如您從10g升級資料庫，校驗下面的資訊

SQL> select DBMS_STATS.GET_PARAM('METHOD_OPT') from dual;

DBMS_STATS.GET_PARAM('METHOD_OPT')
-------------------------------------------------------------
FOR COLUMNS ID SIZE 1

假如輸出是"FOR COLUMNS ID SIZE 1"，它可能在升級過程中會遇到問題。因此作為一個繞過的方法執行

SQL>exec DBMS_STATS.SET_PARAM('METHOD_OPT','FOR ALL COLUMNS SIZE AUTO');

參照: 未公開的 BUG 22454765 - CARRYING METHOD_OPT = "FOR COLUMNS ID SIZE 1" FROM 10G WILL BREAK UPGRADE

升級資料庫到11gR2

第28步

在 OS 裡，進入 11gR2 的 $ORACLE_HOME/rdbms/admin 裡。

注意： 如果是從 9.2 升級並且 SYSAUX 表空間已經存在，那麼需要 drop 掉已存在的 SYSAUX。在資料庫用 11gR2 的軟體使用 upgrade 模式啟動後 SUSAUX 表空間應該立刻被重建。（Compatibility 最小設為 10.1 並且在執行 catupgrd.sql 之前）。

只有在從 9.2 升級到 11gR2 時才需要重建 SYSAUX 表空間，在重建時需要有下面的屬性：

ONLINE
PERMANENT
READ WRITE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO

Pre-Upgrade Information Tool 會在輸出結果的 SYSAUX 表空間部分預估出 SYSAUX 表空間需要的最小值。可以參照在第一步中 utlu112i.sql 指令碼的輸出日誌。
下面的例子會建立一個 500M 的 SYSAUX 表空間：

使用 spool 設定一個日誌檔案，這樣可以在升級後檢查升級的過程，並執行升級指令碼。

這個非常重要的步驟可以確保新的資料庫軟體的完整性和一致性。如果在啟動資料庫時碰到錯誤說引數檔案中含有被廢棄的初始化引數，那麼從初始化引數檔案中刪除這些引數。如果需要的話，可以把 spfile 轉換成 pfile 之後就可以編輯 pfile 並刪除相關引數了。

執行 Post-Upgrade Status Tool $ORACLE_HOME/rdbms/admin/utlu112s.sql， 它會提供一個關於升級的總結. 它會顯示升級後各個資料庫元件的狀態和各個元件升級花費的時間。任何在升級中碰到的錯誤也會被列出，這些錯誤必須得到妥善的處理。

執行 $ORACLE_HOME/rdbms/admin 目錄下的 catuppst.sql， 完成不需要在資料庫處於 UPGRADE 模式下操作的其它升級的動作：

這個指令碼可以和 utlrp.sql 並行執行. 在另一個 session 裡執行 utlrp.sql 來重新編譯剩下的 PL/SQL 和 Java 程式碼：

執行從下面文件中得到的 dbupgdiag.sql 來檢查升級後資料庫的完整性。

如果 dbupgdiag.sql 發現了一些失效物件，那麼多次執行 $ORACLE_HOME/rdbms/admin/utlrp.sql 來重新編譯這些失效物件，直到失效物件的數目不再變化。

在重新編譯這些失效物件之後，再次執行 dbupgdiag.sql 確認一切都是正常的。

升級後的步驟

第29步

驗證 listener.ora 檔案。

確認 ORACLE_HOME 環境變數指向了升級後的 ORACLE_HOME，然後啟動listener。

第30步

環境變數

1. 確認下面的環境變數指向了新的 Oracle 11gR2：

- ORACLE_BASE
- ORACLE_HOME
- PATH, LD_LIBRARY_PATH, SHLIB_PATH and LIBPATH ( for AIX )

並且檢查 oratab 檔案和其它的客戶端指令碼，確認是指向了正確的 11gR2 HOME。

注意： 如果是升級的 RAC 資料庫，那麼需要在所有的節點上檢查。

2. 更改 /etc/oratab 去開啟自動啟動。

第31步

注意： 這個步驟實際上是根據第6步裡提到的文件裡的內容做的。

在升級後檢查資料庫時區的當前版本：

這個值應該和升級前的值一樣的。

如果這個值大於 11（for 11.2.0.1 ） 或 14 （for 11.2.0.2 and 11.2.0.3）， 那麼忽略這個步驟直接去執行第32步

如果這個值等於 11（for 11.2.0.1 ） 或 14 （for 11.2.0.2 and 11.2.0.3）， 那麼忽略這個步驟直接去執行第32步

如果這個值小於 11（for 11.2.0.1 ） 或 14 （for 11.2.0.2 and 11.2.0.3）， 那麼*推薦*升級 DST 的版本

*對於 11.2.0.1，使用文件 Note 1585343.1 Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12cR1 database 中的指令碼把資料庫 DST 版本升級到 DSTv11 （standard DST version of 11.2.0.1）。
或者
   參照文件 Note 977512.1 Updating the RDBMS DST version in 11g Release 2 (11.2.0.1 and up) using DBMS_DST （從步驟 3a 開始）來升級，把那篇文件裡提到的 the new DST version number 替換成 11。


*對於11.2.0.2 ， 11.2.0.3 和 11.2.0.4， 使用文件 Note 1585343.1 :  Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12cR1 database 中的指令碼把資料庫 DST 版本升級到 DSTv14 （standard DST version of （for 11.2.0.2 ， 11.2.0.3 and 11.2.0.4）。
或者
    參照文件 Note 977512.1 Updating the RDBMS DST version in 11g Release 2 (11.2.0.1 and up) using DBMS_DST （從步驟 3a 開始）來升級，把那篇文件裡提到的 the new DST version number 替換成 14。

第32步

升級那些使用 DBMS_STATS 建立的統計資訊表（Statistics Tables）。

如果我們使用 DBMS_STATS.CREATE_STAT_TABLE 手工建立了一些統計資訊表（statistics tables），那麼執行下面的命令來升級這些表（如果沒有建立過統計資訊表，那這一步驟可以忽略）。例如：

在上面的例子裡， 'SYS' 是統計資訊表的 owner， 'dictstattab' 是統計資訊表的表名。對每個統計資訊表都要執行一遍上面的命令。

第33步

升級外部驗證的的 SSL 使用者。

如果資料庫是從 9.2.0.x 或 10.1.0.x 升級上來的並且之前使用了外部驗證的的 SSL 使用者，那麼需要執行下面的命令來升級這些使用者：

如果是從 10.2.0.x（或更高）升級上來的，那麼這個步驟可以忽略。

第34步

啟用 Database Vault

如果資料庫之前使用了 Database Vault，那麼參考下面的文件來啟用 Database Value （如果之前沒有使用 Database Vault，那這一步驟可以忽略）：

第35步

對外部網路服務（External Network Services）配置細粒度的訪問控制。

為了避免在執行和網路相關的 UTL 程式包的時候引發"ORA-24247： network access denied by access control list （ACL）"的錯誤，訪問許可權需要賦給使用這些程式包的使用者。

下面的例子先查詢當前已經分配給 host_name 的訪問控制列表（ACL）， 如果發現了就賦給 user_name CONNECT 的許可權（如果它沒有的話）。
如果沒有訪問控制列表（ACL）存在，就建立叫做 ACL_name 的訪問控制列表（ACL），並且把 CONNECT 許可權賦給 user_name，然後把這個 ACL 分配給 host_name。

acl_name.xml => 指定訪問控制列表的XML檔案的名字，
ACL description => 檔案的描述，
principal => '使用者或者角色'，
is_grant => TRUE|FALSE，
privilege => 'connect|resolve'，
host_name => 主機名

關於如何使用 DBMS_NETWORK_ACL_ADMIN 程式包並避免 ORA-24247 ： network access denied by access control list （ACL）請參照下面的文件：

第36步

編輯 init.ora

• 如果在升級前改動過 CLUSTER_DATABASE，那麼需要再把它改回來。
• 把 pfile 檔案改回到 spfile

從 pfile 建立 spfile。

它會根據 $ORACLE_HOME/dbs （UNIX）或者%ORACLE_HOME%\database （Windows）目錄下的 pfile 產生一個新的 spfile。

第37步

改 Oracle 提供的使用者的密碼。

根據升級前資料庫的版本，可能會存在一些 Oracle 自帶的使用者。Oracle 推薦把除了 SYS 和 SYSTEM 之外的這樣的使用者都鎖住並讓它們的密碼過期。
這樣在把這些使用者解鎖的時候就會提示重新設定新密碼。

可以用下面的命令檢查所有帳號的狀態：

使用下面的命令鎖定使用者並讓它的密碼過期：

第38步

升級 Oracle Text

只有在使用了 Oracle Text 的時候才需要做這一步。

注意： 如果資料庫升級前/後都是同一個大版本（ 比如從 11.2.0.1 升級到 11.2.0.2）， 那麼是不需要做這一步的。

把下面的檔案從原 ORACLE HOME 複製到新 Oracle Home：

* Stemming user-dictionary 檔案
* User-modified KOREAN_MORPH_LEXER dictionary 檔案
* USER_FILTER 可執行程式

如果版本是 920， 101， 102，那麼下面的檔案包含有這些檔案的列表：

$ORACLE_HOME/ctx/admin/ctxf<version>.txt
$ORACLE_HOME/ctx/admin/ctxf<version>.sql

比如，如果資料庫是從 10.2.0 升級上來的：

如果 Oracle Text 索引用到了 KOREAN_LEXER（在 9i 裡不推薦使用了並在 10gR2 裡被廢棄了）， 那麼參考下面的文件去手工遷移 KOREAN_LEXER 到 KOREAN_MORPH_LEXER：

如果是升級到 11.2.0.3，對於 Lexer Feature Updates 請參考下面的文件：

對第38步，還可以參考下面的文件來獲得更詳細的資訊：

第39步

升級 Oracle Clusterware 的配置

如果升級的是 10.2， 11.1 或 11.2.0.1 的 RAC 資料庫，那麼要用下面的命令在 Oracle 叢集軟體裡升級資料庫的配置：

$ srvctl upgrade database -d db-unique-name -o oraclehome

這裡的 db-unique-name 是指的資料庫的名字（不是 instance name），oraclehome 是 Oracle Home 的路徑。


第40步

配置 Enterprise Manager

只有在資料庫使用了 DBconsole 的時候才需要做這一步，如果沒有配置 Dbconsole 或者這個資料庫沒有被 Grid Control 監控，那麼忽略這一步。

如果資料庫使用了 Enterprise Manager Database Control ， 那麼使用下面的命令升級配置：

這個命令需要在新的 Oracle 11gR2 的 Oracle Home 裡執行。當需要提供 Oracle Home 時指定 Oracle Home。

第41步

TDE (Transparent Data Encryption)

如果你使用了 TDE （Transparent Data Encryption）技術，那麼需要重新鍵入 master key：

對於其它資訊請您參照文件 Note 1260584.1 : Ora-28374 After Migration From 10.2.0.4 To 11.2.0.1。

第42步

收集 Fixed Object 統計資訊

請在升級後兩週後收集 fixed objects 統計資訊：
SQL>EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

It would to good to gather the statistic during non-peak hours

其它有用的升級文件：

Note 1561791.2 Upgrade / Downgrade Assistant: Oracle Database/Client
Note 1351112.2 Information Center: Upgrading and Migration Oracle Database
Note 785351.1 Oracle 11gR2 Upgrade Companion
Note 251.1 Database Upgrade Planner from 10.2 to 11.2
Note 264.1 Database Upgrade Planner from 9.2 to 11.2

Step 43

在升級到11.2.0.4時,如果compatiblity設定的小於11,那麼需要額外的步驟去手工實施bug 14373728的補丁

參照 Note 1537496.1 How to Manually Enable the Patch for Bug:14373728 on Oracle 11g Release 11.2.0.4

修訂歷史:

03-Sep-2009    Article Created

27-Oct-2009  Changed Indirect upgrade table value  from 9.2.0.3(or lower) to 9.2.0.7(or lower)

27-Oct-2009  Check the certification of the 11g R2 with you platform before installing the software 

29-OCt-2009  Note in step 32

參考