ITPub博客

首页 > 数据库 > Oracle > 10g升级11g没有运行utlu112i.sql的后果

10g升级11g没有运行utlu112i.sql的后果

Oracle 作者:www_xylove 时间:2016-07-19 17:45:45 0 删除 编辑

客户的数据库从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/21266384/viewspace-2122243/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-11-12

  • 博文量
    99
  • 访问量
    221235