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。