10g升級11g沒有執行utlu112i.sql的後果

客戶的資料庫從10.2.0.5單機升級到11.2.0.4RAC 由於是新伺服器新儲存，所以之前已經做過一次完成的模擬升級測試，由於客戶提供了近3個小時的停機時間，所以我們計劃採用物理升級的方式進行，有測試升級沒有發現問題，正式升級是由我同事進行，在正式升級那天，晚上同事突然說upgrade模式開啟後執行catupgrd.sql，無法重新整理資料字典，以下為具體的硬體環境及資料庫版本

原始版本：
伺服器：P550
作業系統版本：AIX 5.3
資料庫版本10.2.0.3

新伺服器：IBM P824
計劃升級版本：11.2.0.4.4

在升級過程中，執行catupgrd.sql出現報錯:

DOC>#######################################################################
DOC>#######################################################################
DOC>   The following error is generated if the pre-upgrade tool has not been
DOC>   run in the old ORACLE_HOME home prior to upgrading a pre-11.2 database:
DOC>
DOC>   SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
DOC>                       *
DOC>      ERROR at line 1:
DOC>      ORA-01722: invalid number
DOC>
DOC>     o Action:
DOC>       Shutdown database ("alter system checkpoint" and then "shutdown abort").
DOC>       Revert to the original oracle home and start the database.
DOC>       Run pre-upgrade tool against the database.
DOC>       Review and take appropriate actions based on the pre-upgrade
DOC>       output before opening the datatabase in the new software version.
DOC>
DOC>#######################################################################
DOC>#######################################################################
DOC>#
Session altered.
Table created.
Table altered.
SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
              *
ERROR at line 1:
ORA-01722: invalid number

從報錯原因上似乎也很明確，在SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
從上面反饋的資訊中也看到：
Revert to the original oracle home and start the database.Run pre-upgrade tool against the database.
我仔細詢問了同事，同事告知，確實沒有執行utlu112i.sql該指令碼，由於認為之前測試升級的時候已經執行過了，所以認為沒有必要執行，此處已經出現了第一個錯誤，錯誤的認為utlu112i.sql指令碼僅僅參與一個預檢查工作，其實不然，utlu112i.sql指令碼不僅會檢查升級環境的要求，還會在資料庫中插入一些重要的資訊，包括時區等等。既然確認問題了，那麼我們就回退整個環境，重新執行該指令碼。
我們重新切回老生產庫環境變數並執行預檢指令碼：utlu112i.sql
繼續重新整理資料字典，報錯依舊。
此時問題出現了盲區，到底是為什麼呢，已經成功回退並執行該指令碼了，但是似乎依舊沒有生效。
沒辦法，客戶給的時間只有2個半小時，已經被我們在這裡浪費了近20分鐘。資料庫升級工作就是這樣，順利的時候順風順水，不順利的時候就痛苦了，由於是客戶的核心繫統，各個部門的領導都等著結果，壓力可想而知
靜下心來細細想想，現在我們也只能透過去跟蹤catupgrd.sql看看到底報錯是在哪個位置，看看能不能繞過這一步
我們跟蹤了catupgrd.sql指令碼
在執行catupstr.sql指令碼中出現該報錯：
而報錯時段的程式碼如下：

CREATE TABLE registry$database                (platform_id NUMBER, platform_name VARCHAR2(101),                 edition VARCHAR2(30), tz_version NUMBER); ALTER TABLE registry$database add (tz_version number); Rem Check if tz_version was populated if the db is pre-11.2 SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')    FROM sys.props$    WHERE      (        (         (0 = (select count(*) from registry$database))         OR         ((SELECT tz_version from registry$database) is null)        )        AND        (         ((SELECT substr(version,1,4) FROM registry$ where cid = 'CATPROC') =           '9.2.') OR         ((SELECT substr(version,1,4) FROM registry$ where cid = 'CATPROC') =           '10.1') OR         ((SELECT substr(version,1,4) FROM registry$ where cid = 'CATPROC') =           '10.2') OR         ((SELECT substr(version,1,4) FROM registry$ where cid = 'CATPROC') =           '11.1')        )      );

建立registry$database並進行查詢時候報錯
檢查資料庫，發現該表不存在：
SQL>  select count(*) from registry$database;
 select count(*) from registry$database
                      *
ERROR at line 1:
ORA-00942: table or view does not exist
 
由於在報錯的時提示：   
DOC>       Shutdown database ("alter system checkpoint" and then "shutdown abort").
DOC>       Revert to the original oracle home and start the database.
DOC>       Run pre-upgrade tool against the database.
DOC>       Review and take appropriate actions based on the pre-upgrade
DOC>       output before opening the datatabase in the new software version.
那麼證明在執行utlu112i.sql指令碼的時候一定是做了類似的建立表操作。
我們檢查utlu112i.sql指令碼發現以下程式碼：

IF sqlcode = -942 AND NOT db_readonly THEN — no registry$database table so create it          EXECUTE IMMEDIATE            'CREATE TABLE registry$database(              platform_id   NUMBER,              platform_name VARCHAR2(101),              edition       VARCHAR2(30),              tz_version    NUMBER              )';          IF substr(db_version,1,3) != '9.2' THEN — no v$ views for 9.2             EXECUTE IMMEDIATE                'INSERT into registry$database                      (platform_id, platform_name, edition, tz_version)                 VALUES ((select platform_id from v$database),                         (select platform_name from v$database),                          NULL,                         (select version from v$timezone_file))';

          
搜尋MOS，發現以下文件：
Bug 14174083 : PRE-UPGRADE FAILS TO CREATE REGISTRY$DATABASE & POPULATE THE TZ VALUE
嚴重性 2 – Severe Loss of Service 產品版本 10.2.0.3
WORKAROUND:
————————–
Can the registry$database table be created manually & if the Value of the DST 
Patch is inserted into the Table,Will it impact the Upgrade Process in any 
Way??
 
我們嘗試手工建立該表格，從以上程式碼中複製建立語句：
CREATE TABLE registry$database
               (platform_id NUMBER, platform_name VARCHAR2(101),
                edition VARCHAR2(30), tz_version NUMBER);
                
並做insert 操作：
INSERT into registry$database
                     (platform_id, platform_name, edition, tz_version)
                VALUES ((select platform_id from v$database),
                        (select platform_name from v$database),
                         NULL,
                        (select version from v$timezone_file))
                        
再次執行upgrade升級指令碼，升級成功
整個過程算是順順利利，在客戶規定的時間內，我們也順利的完成了這次升級工作。簡單總結一下這次的心得，如下幾點：
1.永遠不要按照最順利的時間來制定整個升級時間，一定要給自己預留一定的時間以防止一些突發事件。

2.不要試圖為了加快升級時間而去想當然的忽略一些細節的東西，一步一個坑的幹活方式永遠要比三步並作兩步來的穩妥。

3.出現故障的時候，不要慌不要亂，用個兩三分鐘時間沉靜一下自己，想想接下來的方向，往往比頭腦一熱向前衝來的要好。

4.客戶需要的是穩定，如果確實沒有辦法解決問題，不要忘記，你還有回退這一個終極方案，不要硬著頭皮硬上，沒把握的事情給客戶帶來的傷害是無法想象的。

 ------------------------------------------------------------------------------------

原部落格地址：http://blog.itpub.net/23732248/
原作者：應以峰 (frank-ying)
-------------------------------------------------------------------------------------