客户的数据库从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)
-------------------------------------------------------------------------------------