PeopeSoft 环境下的 Oracle 数据库 9i 升级到 10g

去年年底之前，匆匆忙忙地把数据可给升级了。本来想要在夏天做的，因为查出来我们的  HR 系统使用中的 PeopleTools 是 8.44 的，不支持 10g 的数据库，就打算先把 PeopleTools 给升级到最新版本 8.49。但是又查出来，我们的 OS 是 AIX 5.2 的版本， PeopleTools 只支持 5.3 的版本。 OS 那边一时确定不了什么时候可以做升级，我又不想等，就算了，把 PeopleTools 先升级到 8.47 好了。

不想 PeopleTools 升级远比想象中的要麻烦。虽说这是好几个月的工作量，我硬要在三四个星期内做完，不过还是按时做完了。其中不乏跟 PeopleSoft 的技术支持吵了好几架。我承认 PS 自从跟 Oracle 合并了之后好了很多，冰冻三尺，非一日之寒哪。那升级的文档，要用猜的，许多步骤，一运行就是好几个钟头，运行的结果根本没用上，不知道为什么要运行它。最后终于搞明白了，也跟 function 的人沟通好了，暑假结束之前终于做好了升级。

然后问题就来了，OS 那边要重新作 file system, 还要做 OS 升级。又让我等，我等了四五个星期，实在不耐烦了，我说我不等了。时值年度结尾结算时期，downtime 越来越难拿，我如果等下去，要等到 2008 年的不知道那一天，之后的工作全部没法子做。所以我强行坚持要升级。一般来说，做这样的升级我通常要求 DR 系统五天，周五晚上，或者周六做 Prod.  DR 希同上面的数据库比较多，有六个到八个，Prod 上面有两个。用 DR 的升级来计算时间，如果不超过六小时，就在周五完成，如果超过了，就干脆周六才做。而DR 的那边，一般一天半搞定，剩下的时间可以开放给特定用户做几天测试，确定数据库升级对应用方面没有影响。

这次升级，因为我坚持，所以只拿到了二天的 DR  downtime。想来用户最多有半天时间测试，而且他们大概也不会测试什么，我也知道数据库的升级对用户完全是透明的。所以我也就坚持说两天就两天好了，这种升级原本也不是什么大事，我还没有做升级失败的前科呢。实际上，就算再有经验，也要预留充足的时间，运气的是，有惊无险。

我还是做了很多准备工作的，包括阅读了所有有关的文档，还把 metalink 上面相关的文章都看了一遍。另外，还请 Oracle 里面的哥们儿，打听了一下 Oracle 的相关顾问对升级有什么内部的注意事项。唯一不太充足的就是，没怎么充分的玩过 10g.

Oracle 有两项新的东西，值得介绍一下的：

1.  Pre-install checks for 10gR2 RDBMS 的脚本，这个需要按照平台，在 metalink 上面下载，大概要 check 20-30 项 OS 的参数。我觉得这是一个很好的主意。美中不足的地方，Oracle 新版本特别要求的 OS patches 并不在检测之列，你还是要一个一个地去自己 check.

2. 运行一个安装了 10g 之后才有的脚本： utlu102i.sql。这个脚本要在旧的数据库状态下运行，检查旧的数据升级到新的数据库需要增加的 tablespace 的 size，以及需要建立新的 tablespace 之类的。需要注意的地方是，升级到不同的 Oracle 版本，需要运行的脚本不一样的，我上面没说，我是从 9.2.0.4 升级到 10.2 的。由于这个文件必须安装之后才能找到，你如果没有安装过 10g ，可以在别的平台下装一个，或者跟朋友要一个。sql 在那里都是一样的脚本，并没有平台的限制。

之后呢，就要选择升级的模式了。基本上三种：

1. export/import

2. Database upgrade assistant

3. Manually

我一直使用 manually 的方法。原因是因为这个方法简单方便。

之后，就是要把 tnsnames.ora 和 listener.ora 备份出来。另外，要把 $ORACLE_HOME/dbs 这个目录做一个 ls 的截屏。

安装 oracle 10gR2 是很顺利。但是安装完成之后，问题就来了。sqlplus / as sysdba 报错。

检查不出毛病，干脆全部卸载，重新安装一次。没有报错呀。没办法，打电话给 Oracle。这时候，第一天已经快要结束了。跟 Oracle 的技术支持说了情况，结果，他们的电话系统又出了毛病，打不进去也打不出来，这样有耗费掉了两个钟头。我都快疯了。

我跟技术支持说，我就两天，要升级十来个数据库，现在已经一天没了。他问我，你升级这么多数据库就要两天，你知道不知道你在做什么呀，你老板知道不知道你要做多少事情？我是有苦说不出，箭在弦上，不能不发。他说，这样好了，他要下班了，他把我的 case 提高到最高级别，相当生产库当机的那种级别，派一个级别比较高的技术支持给我，第二天他跟进。这也是最好的办法了。于是我也回家，在家用 vip 工作。

回到家里可跟 oracle 的技术支持联系，然后跟那个大姐一起工作了四个小时，检查了所有的东西，都没出错，最后这个大姐说，你的 tnsnames.ora 是 copy 以前 9i 的，是呀。她肯定地说，这个文件 10g 的跟 9i 的肯定不一样的。我有点懵了，我也不是没玩过 10g 不过不是在 aix 上面玩的，是在 windows 上面而已，哪里有不一样呢。（为此，之后还麻烦了 600 去别人机器上面比较了几个版本的 tnsnames.ora 文件）。电话四个小时之后，大姐撑不住了，一边说没道理，一边说，我们先挂断吧，她要去做一下 research.

四十分钟之后，她再挂电话给我，跟我说，她终于发现了原因，10gR2 在 aix 上面有个 bug，如果用户不是 oracle, 如果用户group 不是 dba 就会触发这个 bug。我的环境，用户是 oracle，但是 用户组 是 oradba。 所以，要另外建立一个用户组叫做 dba，把用户 oracle 加进去。于是赶紧给 SA 打电话，让他建立dba 这个 OS  group。电话打过去，我们的 SA 睡得迷迷糊糊地听电话，跟我叫，你爱建什么建什么，明儿跟我讲一声就好了。汉，这人睡觉真早。

之后就是一帆风顺了，运行几个脚本。（有几个需要很长的时间）。

忘了一件事情。就是 parameter file。有些旧的参数不能使用了，有些新增加的参数，还有一些参数要修改数值。在我的环境下面，我修改了下面的参数：

New Parameter for profiles:

#add by 10g upg, ISA
pga_aggregate_target      = 100M  # 100 Mb
session_max_open_files   = 50
streams_pool_size         = 100M
java_pool_size            = 350M
LARGE_POOL_SIZE    =150M

Modify:
SHARED_POOL_SIZE=500M
LARGE_POOL_SIZE=150M

optimizer_feature_enable
complibilities

整个过程的脚本：

cd $ORACLE_HOME/rdbms/admin
SQL> spool /oracle/app/oracle/admin/HSYS88/upgrade.log
SQL> startup upgrade

CREATE TABLESPACE sysaux DATAFILE '/oradata/HSYS88/db3/sysaux01.dbf'
SIZE 500M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;

alter database datafile '/oradata/HSYS88/db1/system01.dbf' resize 600M;

@catupgrd.sql
@utlu102s.sql TEXT
spool off
shutdown immediate;
startup restrict
@olstrig.sql
@utlrp.sql

patch:
cd $ORACLE_HOME/rdbms/admin
spool '/oracle/app/oracle/admin/HSYS88/patch.log'
startup upgrade
@catupgrd.sql
@utlrp.sql

catupgrd.sql 运行需要一个多小时。如果数据库大，还要更长时间。utlrp.sql 也许要 50 分钟。数据库大小为 25 G。

我先升级了数据库，之后再安装 patch 包的。我比较喜欢这样做，如果出了问题，可以清楚的指导是哪一步骤出的问题。其实呢，也没有多用很多时间。

上面就是数据库部分的升级，总结一下：

1.运行两种 pre-check, others

2. drop all dblink before upgrade

3. shutdown system

4.  OS user profile.  copy tnsnames.ora, listener.ora to a temp directory

5. 远程安装需要 x windows

6. install oracle database server (about 1 hour)

7. copy tnsnames.ora and listener.ora back.

8. modify parameter file, modify $ORACLE_HOME/dbs directory

9. startup upgrade, run scripts

******************************

应用方面：

1. modify application OS user profile

2.  drop all application cache and schedule cache

3. re-configure application server and scheduler

********************************

OS 方面：

1. /etc/oratab

2. all OS relative scripts (backup, import/export, monitor scripts)

几乎所有的问题都跟新建立的 ORACLE_HOME 有关。

故事到这里还没完。因为周四忙到太晚，周五又忙了一天，到下午二点钟所有 dr 的数据库都升级完毕，太累了。准备生产机周六再做。正在跟同事聊这件事，我老板来了，说周六公司的这个区域有暴风雨预告，可能导致断电，不建议我做生产机，逼到我没办法，只好周五连轴转。比较悲惨。先做了一个备份，再做升级，全程大概七个小时。