RAC 历险记 转贴自ITpub

RAC 历险记
作者：iamweng
国庆前夕公司正式和某市的某通信公司签署97 系统的升级合同，我公司作为集成商，
将负责和应用程序开发商，硬件厂商（HP），数据库供应商（ORACLE）的协调。两台HP7410
主机已于国庆前到货，我公司负责主机到货后的初步验收，（也就是看着一个大柜子安全地
放在机房外，确保没有外部损伤）。
背景
该通信公司97 营业系统确实一直在使用，下属400 多个客户端每天都在ORACLE 数据
库中存取数据，通信公司提出如下要求：
1. 不能停止营业。
2. 升级失败后要能安全回退旧系统。
3. 要快。
他们的旧系统环境如下：97 年的系统，HPK 系统机型，ORACLE7.3.2。应用程序开发
商不能肯定他们的系统能在ORACLE9I 下无异常反应，向该通信公司提出提供测试环境的
要求，出于拿到集成合同的目的，我公司承诺提供测试机。结果HP 不答应，我们承诺无法
兑现，该通信公司反应强烈，（该通信里面的和我们接触的人全是女的掌权，开协调会的时
候7,8 个女的把我们项目管理人员骂得狗血喷头，连说话的机会都没有）。
惊险历程
入场
10 月8 号
过完国庆，10 月8 号，我们公司项目人员进驻该通信公司，一个管理人员A，原计划还
有系统人员B 的，只因他在另一个项目里脱不开，暂时就没来，还有一个就是我，公司想
省了ORACLE 的服务费，由我负责数据库的安装。日程安排大致如下：一天系统安装，
一天数据库测试，一天应用程序测试，晚上升级，第二天早上7：00－8：00 业务人员在前
端测试，8：00 开始正式营业。此计划已经由该通信公司公司向上汇报，并在当地的电视台
发布该通信公司为了更好的为用户服务，将在某月某日进行系统更新，给用户带来不便，深
表歉意的字样。
ITPUB 电子杂志(总第六期) 48 of 82
10 月9 号
10 月9 号，HP 工程师A 如期进场，我们协助将主机搬到机房中的预定位置。（也就是
搬机子，当民工，也是挺讲究的，暂先不表），直到深夜12：00HP11i 操作系统还没安装完
毕，其间HP 工程师避着我们到厕所里打了好几个电话，神色有些不对。
10 月10 号
10 月10 号9：00，HP 工程师B 过来，该通信公司公司召集我们开会，对我们准备实施
RAC 有些担心，认为技术太新，怕出问题，HP 工程师表示没有问题，当我承认我没有在
HP 机上实施过RAC，该通信公司那几个女的很是不愉。随后HP 工程师A，B 继续系统安
装直到晚上，其间，A，B 工程师向北京的HP 支持打了好几个电话，从他们的交谈中，我
们知道他们在磁盘阵列的安装上出了问题，对该通信公司的解释是这是一种新型号，他们没
配过。
10 月11 号
10 月11 号，磁盘阵列配置成功，A，B 工程师发现缺少四根光纤跳线，无法和主干网相
连，该通信公司大急，查阅备忘录，我公司老早就提醒过负责设计的邮电设计院，他们疏忽
了，4 条光纤跳线，总共3000 多块钱，本市没有，要从北京买，来回三天，工程停下来了。
10 月12 号
10 月12 号，应用程序开发商如期进场，无事可做，面色不愉。（后知，该通信公司还有
一部分开发费没有给，南邮这次不想来的）。我们乘机到周围的风景区玩去了。呵呵。
10 月13 号
10 月13 号，无事
10 月14 号
10 月14 号，无事，真是舒服。
ITPUB 电子杂志(总第六期) 49 of 82
安装
10 月15 号
10 月15 号，光纤到了，当时真是担心质量不好，又得往北京跑一趟，呵呵。今天HPA
工程师退场了，我们看到，B 的技术和职位比A 要高些，前者只负责安装硬件。下午，HPB
告诉我们在软件清单中的MC/SERVICE Guard 不是用于ORACLE RAC 的并行版本，正确
版本的售价要比这个版本贵6 万块，这回大家都傻眼了。HP 向上汇报，该通信公司向上汇
报，我们向上汇报，顿时感觉到销售人员出马了，暗潮涌动。我亲耳听到那个女主任对他们
设备处的人说这件事时略带一点幸灾乐祸的意思：“某某啊，HP 说你们软件买错了呢。”那
几个女的又把我们管理人员叫过去骂了个狗血喷头。公司开始先是要我们骗客户，随便安上
数据库说是RAC，反正他们狗屁不懂；后来又指示我们就这么赖着，让该通信公司去逼HP，
给他们装上，反正这个钱我们公司是不会出的。HP 开始说那么先装个试用版本，有一个月
期限，该通信公司不答应。就这么僵着。
10 月16 号
10 月16 号，僵局ING，我乘着这个机会在两台主机上装了好几次ORACLE9I，算是先
练练手。呵呵。
10 月17 号
10 月17 号，上午，HPB 说公司同意先安装正确版本的MC，然后从包中拿出一张光盘
笑笑说：
“我这里什么都有，公司叫我安，我就安了。”
这小子挺憨厚的，我喜欢。
我开玩笑说：
“我要是该通信公司，我就把不把服务费给HP 了，给你算了。”
直到晚上7：00，HPB 没有能把MC 装上，我在陪他装的时候，我无意中发现有一个软
件叫MC/SERVICE Guard For RAC extention，我意识到应该是这个，我在资料看到这是HP
为ORACLE RAC 出的最新的支持软件，我坚持应该装这个，他打电话问了以后才明白，
原来应该在原来的MC 才再安装这个支持包，而不是卸下原来的MC 装新的MC。
20：00，MC 安装成功。
开始了数据库的安装。该通信公司问我要多久，我说：“顺利的话4,5 个小时。”
ITPUB 电子杂志(总第六期) 50 of 82
当然我还有一句话没说，不顺利的话就说不准了。呵呵。
我事先将安装程序COPY 就硬盘上，我不能保证我就安一次就成功，加载ORACLE 安
排盘的命令特古怪，有时还弹不出来，当时在HP 体验中心的时候，我是加载一次，重起一
次，加载一次，重起一次，反复者四，才将四张安装盘拷到硬盘上。
现在有HPB 在，每CP 一张盘，我们就KILL 一次，不用重启了。事实证明，我重装了
3 次。呵呵。
安装之前，我检查了核心参数设置。
我有一套核心参数设置是参考了GOTOTOP 和COOLY 提供的文档做的。
和HP B 进行讨论，因为不是对所有的核心参数意义都了解，在他的建议下做了调整，
而事实证明，他说的都错了。
我检查了磁盘阵列的宿主关系，发现没有改成ORACLE，我检查了系统补丁包，因为资
料没有提供和HP11i 相关的补丁包列表，我想了想就没有打任何包，因为我在网上看到有人
说没打包也一样装上的情况。
当出现选择其它结点的界面出来时，我一阵狂喜，我最担心的事情没发生。
当要求执行ROOT 脚本时，我犯了一个错误，我只在一个主机上执行，而没在另一个主
机上执行。
两个半小时以后，软件安装成功，自动启动了DBCA，我发现DBCA 没有使用的定义好
的DBCA_RAW_CONFIG 的文件，只好手工一个一个指定，这时候，我觉得的为裸设备取
的名字太长。
一切OK 以后，开始建库，启动数据库实例失败，我冷汗下来了。
当时已经24 点，我叫HPB 回去了，现在我记不得是为什么失败了。我镇定了一下，扔
开主机，开始看书了。呵呵。
为这次RAC 的实施，我准备了大量的资料，基本上都看过一遍，主要是ORACLE 提供
的Oracle9i Real Application Clusters Setup and Configuration，Oracle9i Real Application
Clusters Concepts， Oracle9i Real Application Clusters Administration，以及COOLY 提供的
step-by-step installation of rac on hp-ux.doc，聚贤庄JJM 的安装Oracle9i for HP-UX.
想来想去，决定重装。
这一次，我发现ROOT.SH 要执行两遍，心中一阵激动，在建库时，实例顺利启动。这
时候已经是凌晨5：00 了，LISTNER 出错，我不知道为什么，好在的留下了建库的脚本，
reading。
9：00 该通信公司公司的人来上班，看我通宵工作，客气了几句，说：“不要太劳累了。”
呵呵。
ITPUB 电子杂志(总第六期) 51 of 82
12：00，reading,13：00，metaline 帐号生效，在metalink 上查资料，
14：00，拨打ORACLE 支持电话，那个女生说：“请登录我们的Metalink 网站，开个TAR."
15:00，向已离开公司的一个同事请教，在此之前，我不认识他。
16：00，该通信公司的几个女的急了，叫人跑来问我，行不行，不行的话叫ORACLE
公司的人来，我大怒，妈的，我都还没乱阵脚，你们慌什么？他们HP 装几天你们一句话不
吭，我还在规定的时间里面你就叽叽歪歪。
17：00，我决定建新库，使用LISTER1，还是报LISTNER 的错，我无奈，按下ABORT
键。
20：00，我决定重新安装所有的东西。
23：00 到建库的时候，我在选择裸设备的时候，发现设备文件不见了。现在知道是我在
ABORT 时安装程序自作聪明给删除了，当时不知道，在划分磁盘陈列时，出于对应用系统
的不了解，我建议HPB 先不要全部划完，等应用测试通过后在划一下比较合理，给现在造
成的问题时我无法建库了，我打电话叫HPB，HPB 说要划分的话MC 要停下来，弄来弄去
跟重做一遍没什么两样，还是你们商量好再划吧，我说：”如果不划分，我想重恢复已有的
设备文件呢？“你这样做。。。”，于是我又暂时客串一下系统人员了，呵呵。
24：00，设备文件恢复，开始建库，这次我一切使用默认设置，数据库叫ORCL，服务
名叫ORCL.WORLD，呵呵，结果顺利通关。现在已是2：00 了，我应该是36 小时不眠不
吃了，喝还是有的。呵呵。
预测试
10 月19 日
10 月19 日，应用开始测试。我回去睡觉。
10 月20 日，应用开发商说好了，没问题。我表示怀疑。看看他们的恢复方案，如果升
级失败，按他们这么做能回得去才怪呢。项目管理人员偷偷跟我说，不管，出问题是他们的
事。我说好吧，但最起码的数据库压力测试还是要做吧，400 个联接总要联一下吧，只要这
个没问题，剩下的问题就是不大了，他说他们联过了，到了40 个联接，测试机的内存就没
了，没法测了。我只好说，我已经说过了。下午HP B 把裸设备全部划完，除了几个25G
大小的裸设备外，730G 的磁盘阵列以0＋1 的方式，全是2G 大小的裸设备。HPB 在那里敲
了一下午的键盘。
ITPUB 电子杂志(总第六期) 52 of 82
试运行
10 月21 日
10 月21 日，周五，据说主吉。
晚上8：00，开始从旧系统中导出数据。
凌晨1：00，数据导入新系统。
3：00 应用开始割接前的测试。
3：30 应用说汉字是乱码。
3：40 重建数据库，修改字符集。
5：00 重导数据完毕。
5：30 应用说用SELECT SYSDATE FROM DUAL 取出的时间不对。查看系统时间，
A 机正确，B 机时区不正确，修改B 机系统时间，SELECT SYSDATE FROM DUAL 取
出的时间不对，重启数据库，SELECT SYSDATE FROM DUAL 取出的时间不对，查看
数据库时区设置，不对，修改后重启，还是不对。要晚10 几个小时。经查发现CONNECT
DATA=服务名,时间不对connect data=实例名,时间正确。
7：00，陷入僵局。怎么办？该通信公司招集我们几方的人开现场会，这个问题能不能
解决？要不要割接？如果割接后还有新问题出来怎么办？有没有把握？大家说不上来。
7：10，业务人员打电话来问我们可不可以开始测试？该通信公司问我们，我一咬牙说，
把TNSNAME 改过来，下发下去开始测试。现在我也想不起我做这个决定的原因了，可能
也是赌了一把吧。
7：20，开始测试，一切正常。
8：00 正式开始营业，下面各局的客户端开始启动，联入数据库，40 个，80 个，100 个，
120 个，140 个，我们看着联接数在不断增加，下面说程序响应很快，大家绷紧的脸开始露
出了笑容。
该通信公司为首的那个女主任说：“看来我们坐上好车了。”
只有我觉得不妙。因为我通过GLANCE 看到可用内存不多了。
我们有4G 内存，SGA 用了800M，这也是他们说快的原因，因为他们以前的系统SGA
才300M，我看到命中率很低。
可是我看到一个联接平均占用内存尽达到20M，有的还更大。
当到160 个联接的时候，客户端再也不能联接上来了，LISTENER 报出超过最大联接数，
ITPUB 电子杂志(总第六期) 53 of 82
这个错误我没看到过，错误提示和系统核心参数有关，建议修改核心参数。
我在ITPUB 上查，matalink 查，也有不少是这样建议的，我回忆起当时和HP B 在修改
核心参数时他倾向于保守的参数设置时，我意味到这可能是出现问题的原因。
下面不断有电话打上来，纷纷抱怨不能联上数据库了，问是怎么回事？
此时我高度紧张，连后悔当初为什么不坚持做压力测试的心思都没有。
此时已经是11：30 分了，我决定修改系统参数。
系统重启，我按照我的思路，重新修改系统参数。
系统参数之间存在函数关系，我是从MAXUSER 开始改起，很多参数的含义我也是不
太清楚，我也只有硬着头皮改下去了，拿不准的参数一率偏大的取。
我已经不管电话了，局方人员对下面解释说数据库正在调整，请耐心等待。
重启的时候，原来4G 的SWAP 区也快满了，我叫系统人员顺便把它增大到6G。
12：00 系统重启，我旁边的系统人员紧紧地挤着我，我明显感觉他在发抖。呵呵。
12：30 系统重启成功，MC 启动成功，数据库启动成功，但是这些核心参数的修改是否
有效，我没有十分把握，我这时候开始后悔没有自己做过压力测试程序，结果自己倒霉。
下午14：30，营业人员进入工作岗位，客户端程序启动，联接数开始上升，40 个，80
个，100 个，120 个，140 个，160 个，180 个，200 个，参数修改起作用了。
这一次，我有意识到观察到随着联接数的增加各个指数的变化，我发现SWAP 区消耗太
大，一个联接竟要30M－60M 不等。
我要系统人员再一次扩大SWAP 到8G，系统人员好象手都软了，扩大以后，他告诉我
没有空间了，不能再扩了。
我心里一紧，竟不想说话了。
今天，用户联接数一直保持在210 左右，内存还剩300M，SWAP 占用70%。
18：00 营业结束。
（编者按：真是紧张的一天，偶排版的时候都紧张得手心出汗）
10 月23 日
10 月23 日，数据库联接数达到260 个，内存已经降下来，平均每个2－3M，反应正常，
SWAP 还是异常的大。
SWAP 还剩20%的时候，我打电话叫系统人员过来。
系统人员到的时候，还剩10%，我对他说，我把一整个mount 点/TD 给你,共20G，你
拿去吧。
系统人员说，我的天，这么大的SWAP 区，我说：“先做吧。”。
还剩5%的时候，我和机房人员将他们原来在这个目录的做的备份成功移走。
还剩2%时，我对系统人员说，你可以做了。
这时候，系统人员发现sam 不能使用了，我发现SWAP 区已经耗尽。
ITPUB 电子杂志(总第六期) 54 of 82
电话响了，我急速在我本机上退出几个TELNET 窗口，叫系统人员在主机用命令行执
行建立SWAP 的命令。
执行成功，A 机的SWAP 目前有28 个G，GLANCE 显示SWAP 区占用率为30%，我
忍不住对着主机伸出了中指。
我接了电话，他们抱怨接不上数据库了。
我说，不会吧，你们再试试，他们在电话里发出噢噢的声音，看来又联进数据库了。
我偷偷笑了。
现在还剩两个问题，时间和SWAP。采用目前TNSNAME 的写法，这样写法直接指向
了具体的实例，使得LOAD＿BALANCE 的功能不能用上，另外下面的客户端仍然是7 的，
所以目前这个问题还不大。只有当他们全部采用了9i 的客户端以后修改TNSNAME 才会提
到日程上来。
但是为什么这个时间不对呢？
以前在ORACLE8I 的时候，SWAP 区的占用量也不大，为什么9i 会这么大呢？
一个28G 的SWAP 区，怎么看怎么别扭，安装系统的时候，有70G 的磁盘两张，系统
人员作为镜像，为系统安装留了5G，为ORACLE 目录留了10G，为HOME 目录留了3G，
临时目录留了10G，剩下的空间不知道拿来办什么了。
我们说：“以前穷惯了，总是为100M，200M 的空间伤脑筋。现在有这个多空间，都不
知道拿来干什么，跟暴发户的感觉一个样。”
这下好了，28 个G 的空间我们用来做SWAP 区了。
公司打电话来，问现在的情况怎么样，项目管理人员就说不怎么好，我听了心里有点不
舒服。
我在METALINK 开了个TAR，描述了时间的问题，一来二去，他们就要我搞个ITAR，
我只好算了。
同时我给销售部门打电话，让他们通过ORACLE 的销售部门给我联系他们的工程师，
请他们务必联线过来看看，同时也给HP 的支持人员打电话，叫他们联线过来看看SWAP 的
问题。
古语有云：“不怕不识货，就怕货比货。”
事实证明，ORACLE 的支持服务是烂的，HP 的支持服务是好的，ORACLE 的800 热线
打过去就这样。而HP 就好多了，他在电话里说不清楚，就主动说拨过来看看，解决不了就
会有其它的工程师再拨过来看看，还把两个HP 工程师也派过来看了，虽然也没有解决问题，
（他们都倾向于向ORACLE 的人咨询）但是这种为客户服务的态度是好的。
没办法了，只有靠我自己了，于是我开始在metalink 上泡着，进行大量的阅读。
该通信公司的人问我们什么时候能解决这个问题，我说现在还解决不了要观察一两天。
该通信公司的人悻悻而去。
就这样过了四五天，通过我的TAR，我知道SWAP 过大是由于BUG 的原因，它在9.2.0.3
版本中得到修正，其间，HPA 在一天上午的巡检中发现一块网卡异常。
下午ORACLE 报出ORA－29740 的错误，B 机的ORACLE 实例崩溃，我采用多种方式
启动数据库，不能成功。半个小时后，数据库启动成功。后来我读到资料是说，B 机的ORACLE
实例崩溃以后，A 机将接管B 机的回退恢复，在这段时间内，A 机是以独占的方法在工作，
所以在这期间B 机是无法启动的，要等A 机回退完成之后，B 机才能以SHARE 方法启动。
ITPUB 电子杂志(总第六期) 55 of 82
当然，我把这次异常当机事件归咎于网卡失灵了。
那天晚上，HPA 更换了失灵的网卡，HPA 说：“我在HP 干了这么久，还第一次换网卡。”
他是吹嘘HP 的网卡是比较好的，只能算他们该通信公司公司倒霉运气不好给撞上了。呵呵。
换网卡时要停机，当数据库起来时，我发现时间对了。呵呵。
我在查阅关于ORA－29740 相关资料时，我看到有的平台上的某一版本的ORACLE 存
在两天或在大负载就报ORA－29740 的错误，其中一台主机上的ORACLE 实例崩溃，别我
们也是这样的情况啊，该通信公司的人还不杀了我。
要升级，要升级，宜早不宜迟。可是，我没有做过升级操作，要是做砸了，只怕我在公
司也呆不长了。
呵呵。升还是不升，这是个问题。
10 月30 号
10 月30 号，公司给项目管理人员打电话，一边说我们在这边辛苦了，一边说这个项目
做的时间太长了，再做下去公司要亏本了，要项目管理人员回去述职。项目管理人员急得不
得了，向该通信公司打了声招呼就匆匆走了，说句实话，我对他这个做法有点意见，虽然他
在这里在我遇到问题的时候帮不上什么忙，我也没指望他能帮忙，但是在这个结骨眼上离开
项目的举动，说得轻一点叫不够仗义，说得重一点叫临阵脱逃。他这一去，就再也没有回来。
10 月31 号-11 月4 日
数据库没有新的异常情况发生。
这段时间里，我从OTN.ORACLE.COM 上下载了9.2.0.1 for windows,在METALINK 上
下载了9.2.0.4 FOR windowns 和HP 的补丁包。
我在WINDOWS 上演练了几次将9.2.0.1 升级到9.2.0.4 的步骤，包括带着业务数据和不
带业务数据的升级，很顺利。
为了避免在WINDOWS 上升级操作所形成的思维定势，我仔细比较了在HP 和
WINDOWS 平台上的升级过程，特别注意了它们之间的不同之处。还在HP 机上运行了一下
升级程序，以确定下载包的正确性。
(ORACLE FOR HP 根据操作系统的不同，下载类别的不同有好几种下载包，第一次在
上面找的时候容易糊涂)。
11 月4 日这一天，我先和该通信公司的人讨论了升级的想法，然后向公司汇报当前工
程的情况。
附件如下：
XX 总：
ITPUB 电子杂志(总第六期) 56 of 82
您好，我向你汇报一下这边的情况：
原来三个主要的数据库问题是：
1.不同的连接方式时间不一致
2.单个连接占用的内存过大
3.单个连接占用的SWAP 区过大。
目前已经解决了前面的两个，最后一个问题根据资料分析需要把数据库的版本
从9.2.0.1 升级到9.2.0.4 才能解决。今天和局方数据库管理员讨论，他们担心如果
升级到9.2.0.4 会导致数据库起不来，影响第二天的营业，希望让他们的主任来决定
是否要升级。（他们的主任明天度假回来。）。
我倾向于做升级操作。我们在实施RAC 的过程中，发现有些问题是和当前使用
的ORACLE 数据库的版本有关，在排查过程中对我们干扰很大，浪费了不少的精力。
而且看到在这一版本
的ORACLE 在某些平台上RAC 运行两天后其中一个结点出现异常情况。我们不能
排除在我们运行的环境下也会有这种情况的可能性；另外，升级过后三个问题也就
算都解决了，比较好
跟用户交代。
但是升级还是有一定风险的，在正常情况下升级比较简单，会比较顺利，万一
出现问题，
就要根据具体的问题来具体解决了，不会出现第二天不能营业的情况。
ITPUB 电子杂志(总第六期) 57 of 82
关于是否要从ORACLE 派人过来的事情，我个人的态度是：一：从现在的情况
分析看，还没有到这一步。二：根据前几天ORACLE 的支持来看，他们的帮助并不
大，当然如果他们过来的话，我们的压力会小很多。
升级过后，在正常情况应该观察7－10 天。
还有就是：目前他们的客户端是ORACLE7，所以RAC 的动态负载平衡功能是用不
起来的。
祝好
IAMWENG
XX 总看了我这封信以后，说要不要从ORACLE 那边派人，由我说了算，并授权我全
权处理这边的事情，实际这边也就只有我一个人了，呵呵。后来销售人员给我打电话说我们
公司根本没有买ORACLE 的现场支持服务，说不到万不得已的情况，不要向客户说起这个
事情，如果要ORACLE 的人过来，就涉及到要向ORACLE 下单的商务操作，要花大笔的服
务费，公司心痛得很，我的邮件正好让公司松了一口气，因为项目管理人员回到公司后，极
力要求通过向ORACLE 下单来解决当前的问题。
升级之路
11 月5 日
11 月5 日，他们主任度假回来了，(本来他们这次度假是安排在项目之后的，可是项目
期延长了，也没有耽误主任度假，真是挺有大将风度的。)上午9：00，我们开了一个会，
这次我吸取了上次的教训，向他们讲述了升级的利与弊，并表明了我的态度。在会议上，我
们的主要内容是如果升级中出了问题应该怎么办。我如实把在METALINK 上看到的出现的
问题列了10 几个给他们，他们都有点吓住了，看上去升级中会有这么多问题可能出来啊。
所以我们更多地讨论了升级失败后的恢复问题。下午，我给他们列了一个不到一页的数据库
升级方案，大致如下：
升级过程
一． 备份A，B 两个用户的数据。保存其它用户的创建脚本，以及相互授权的脚本。
方式：采用EXP 命令。详细方式参看现行日常备份。
ITPUB 电子杂志(总第六期) 58 of 82
二． 备份全库数据
方式：采用EXP 命令。
三． 停止两个数据库实例，停止LSNRCTL，AGENTCLT，GSDCTL。确保ORACLE 用
户没有进程运行。
四． 全系统备份
方式：磁带。
五． 运行升级包，将数据库软件由9.2.0.1 更新到9.2.0.4
方式：详见ORACLE 升级手册
六． 升级数据库，以MIGRATE 方式打开数据库，运行数据库升级脚本。
（先在测试库上进行试验性升级，再在正式库上升级）
七． 关闭数据库，以正常方式打开数据库。
八． 测试数据库，根据情况修改数据库参数。
主要指标：SGA，PROCESS，MEM/CONNECTION,SWAP,时间。
方式：运行联接测试程序。
九． 备份数据库
可能出现的问题
一． 在运行升级包时出现异常。
不能解决将取消升级。
二． 在升级数据库时出现异常。
删除测试库，创建新库，全库导入
三． 注意升级后EXPORT 应用程序是否有问题。
升级时间表
阶段时间说明
备份TDYY，WXXLT 20:00~22:00
备份全库22:00~24:00
停止数据库24:00~0:20 注意检查进程
运行升级包0:20~1:00
升级数据库
测试数据库2:30~6:30
备份数据库6:30~8:30
(注：
1. 全系统备份可以提前做。
2. 如果在5:00 时还不能进入测试数据库阶段，就启动数据库恢复操作，取消升级。
)
注中的第2 条我是特意有红字显出来的，他们看来特不舒服，远不如以前写的计划那样
让人觉得踏实。还有就是嫌字数太少了，不够正式，我就把上述内容扩展成共10 页的<<升
级工作计划>;>;，呵呵，真正有用的，这就是这点东西。
从这个计划我们可以看出，从当天晚上20：00 到第二天8：30 的11 个半钟头内，升级
操作才两个钟头，而大部分时间都是为了保证安全了，这个计划是我自己拟定的，我可不想
ITPUB 电子杂志(总第六期) 59 of 82
出什么问题。
我们决定于11 月7 号晚上20：00 升级。
11 月6 号
11 月6 号，我主要做了如下几件事情:
  自己编写了一个数据库压力测试程序，主要是用来测试数据库联接数的，它可以在
短时间内高强度地联接数据库。
(注，我是程序员出身的数据库管理员，精通ORACLE，JAVA，DELPHI，POWERDESIGNER，
ROSE，大家有活的话，可以找我啊。打个广告先。呵呵。)
  在咱们PUB 上发了帖子，Fenng，biti_rainy，chao_ping 也给予了指导，在此
感谢一下。
  打电话询问了几个ORACLE 人员。
  在生产机上建了一个小型测试库，用来对数据库进行试验性升级.
总的感觉是：10 个做ORACLE 的，有5 个对HP 上安装ORACLE 比较熟，在这5 个中，
有2 个对安装ORACLE9I 比较熟，在这2 个中，可能只有1 个，或者半个实施过RAC，而
我象这样要做升级操作的就更少了。
我比较信任有实际实施经历的人，在我的咨询中，大部分有资格做判断的都认为只要严
格按照升级手册操作“应该”是没问题的，这使我安心了不少。
只有一个ORACLE 支持用肯定的语气告诉我：
“出问题是难免的，ORACLE 数据库软件升级失败倒没关系，要是数据库升级失败了，
数据不能用了，你就惨了。哈哈。”
我没办法，只好尽可能地收集出问题案例进行分析，以期在遇到的时候不会措手不及。
我大概准备了近30 种异常案例。
11 月7 号
11 月7 号20：00，升级操作开始，这一次他们的主任也来了，还给我们带来了夜宵，
比上次待遇要好一点了。呵呵。
这次升级很顺利，没有遇到什么问题，我就不细写。
当时有点恍然若失的感觉，咋就不出点问题呢，我可是准备了30 个案例啊，一个都没
用上太亏了吧。呵呵。
现在我也可以说只要按照操作手册做“应该”是没什么问题的。
顺便提醒大家的是：ORACLE 的负载平衡在高密度高强度的联接操作中根本不发挥作
用，它更倾向于联接其中的一台主机。
ITPUB 电子杂志(总第六期) 60 of 82
凌晨6：00 的时候，我给公司发邮件，上面只有四个字：“升级成功。”。
是不是有点象乔峰当年经过一番恶战，干掉一厉害对手后回到丐帮轻描淡写地说：
“把某某给杀了。”
呵呵。
总结
总结：这是我搞IT 以来压力第三大的一次实施。
我的经验：
  最重要的是一定要有在强大压力下保持冷静头脑的能力。
  紧张没关系，害怕没关系，但是头脑一定要清楚。
  别人的意见要听，自己要有主见。
每个人在压力之下崩溃的症状是不一样的，有的人可以从面部表情看出来，有的人可能面部没反
映出来，可是他却发出错误的指令。你所要做的就是要保持清醒的头脑。说句实话，这个项目有
几次都到了失败的边缘，我很佩服自己没有乱了阵脚。
好了，回去找公司加工资去。88。