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

yingyifeng306發表於2015-03-09

客戶的資料庫從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)
-------------------------------------------------------------------------------------


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23732248/viewspace-1453158/,如需轉載,請註明出處,否則將追究法律責任。

相關文章