客户的数据库从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/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23732248/viewspace-1453158/