http://epub.itpub.net/6/4.htm国庆前夕公司正式和某市的某通信公司签署97系统的升级合同，我公司作为集成商，将负责和应用程序开发商，硬件厂商（HP），数据库供应商（ORACLE）的协调。两台HP7410主机已于国庆前到货，我公司负责主机到货后的初步验收，（也就是看着一个大柜子安全地放在机房外，确保没有外部损伤）。
背景
该通信公司97营业系统确实一直在使用，下属400多个客户端每天都在ORACLE数据库中存取数据，通信公司提出如下要求：
1. 不能停止营业。
2. 升级失败后要能安全回退旧系统。
3. 要快。
他们的旧系统环境如下：97年的系统，HPK系统机型，ORACLE 7.3.2 。应用程序开发商不能肯定他们的系统能在ORACLE9I下无异常反应，向该通信公司提出提供测试环境的要求，出于拿到集成合同的目的，我公司承诺提供测试机。结果HP不答应，我们承诺无法兑现，该通信公司反应强烈，（该通信里面的和我们接触的人全是女的掌权，开协调会的时候7,8个女的把我们项目管理人员骂得狗血喷头，连说话的机会都没有）。
惊险历程
入场
10月8号
过完国庆，10月8号，我们公司项目人员进驻该通信公司，一个管理人员A，原计划还有系统人员B的，只因他在另一个项目里脱不开，暂时就没来，还有一个就是我，公司想省了ORACLE的服务费，由我负责数据库的安装。 日程安排大致如下：一天系统安装，一天数据库测试，一天应用程序测试，晚上升级，第二天早上7：00－8：00业务人员在前端测试，8：00开始正式营业。此计划已经由该通信公司公司向上汇报，并在当地的电视台发布该通信公司为了更好的为用户服务，将在某月某日进行系统更新，给用户带来不便，深表歉意的字样。
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号，无事，真是舒服。
安装
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个小时。”
当然我还有一句话没说，不顺利的话就说不准了。呵呵。
我事先将安装程序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该通信公司公司的人来上班，看我通宵工作，客气了几句，说：“不要太劳累了。”呵呵。
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在那里敲了一下午的键盘。
试运行
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上查，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区已经耗尽。
电话响了，我急速在我本机上退出几个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方法启动。
当然，我把这次异常当机事件归咎于网卡失灵了。
那天晚上，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总：
您好，我向你汇报一下这边的情况：
原来三个主要的数据库问题是：
1.不同的连接方式时间不一致
2.单个连接占用的内存过大
3.单个连接占用的SWAP区过大。
目前已经解决了前面的两个，最后一个问题根据资料分析需要把数据库的版本从 9.2.0 .1升级到9.2.0.4才能解决。今天和局方数据库管理员讨论，他们担心如果升级到9.2.0.4会导致数据库起不来，影响第二天的营业，希望让他们的主任来决定是否要升级。（他们的主任明天度假回来。）。
我倾向于做升级操作。我们在实施RAC的过程中，发现有些问题是和当前使用的ORACLE数据库的版本有关，在排查过程中对我们干扰很大，浪费了不少的精力。而且看到在这一版本
的ORACLE在某些平台上RAC运行两天后其中一个结点出现异常情况。我们不能排除在我们运行的环境下也会有这种情况的可能性；另外，升级过后三个问题也就算都解决了，比较好 跟用户交代。
但是升级还是有一定风险的，在正常情况下升级比较简单，会比较顺利，万一出现问题， 就要根据具体的问题来具体解决了，不会出现第二天不能营业的情况。
关于是否要从ORACLE派人过来的事情，我个人的态度是：一：从现在的情况分析看，还没有到这一步。二：根据前几天ORACLE的支持来看，他们的帮助并不大，当然如果他们过来的话，我们的压力会小很多。
升级过后，在正常情况应该观察7－10天。
还有就是：目前他们的客户端是ORACLE7，所以RAC的动态负载平衡功能是用不起来的。
祝好
IAMWENG
XX总看了我这封信以后，说要不要从ORACLE那边派人，由我说了算，并授权我全权处理这边的事情，实际这边也就只有我一个人了，呵呵。后来销售人员给我打电话说我们公司根本没有买ORACLE的现场支持服务，说不到万不得已的情况，不要向客户说起这个事情，如果要ORACLE的人过来，就涉及到要向ORACLE下单的商务操作，要花大笔的服务费，公司心痛得很，我的邮件正好让公司松了一口气，因为项目管理人员回到公司后，极力要求通过向ORACLE下单来解决当前的问题。
升级之路
11 月5 日
11 月 5 日 ，他们主任度假回来了，(本来他们这次度假是安排在项目之后的，可是项目期延长了，也没有耽误主任度假，真是挺有大将风度的。)上午9：00，我们开了一个会，这次我吸取了上次的教训，向他们讲述了升级的利与弊，并表明了我的态度。在会议上，我们的主要内容是如果升级中出了问题应该怎么办。我如实把在METALINK上看到的出现的问题列了10几个给他们，他们都有点吓住了，看上去升级中会有这么多问题可能出来啊。所以我们更多地讨论了升级失败后的恢复问题。下午，我给他们列了一个不到一页的数据库升级方案，大致如下：
升级过程
一． 备份A，B两个用户的数据。保存其它用户的创建脚本，以及相互授权的脚本。
方式：采用EXP命令。详细方式参看现行日常备份。
二． 备份全库数据
方式：采用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个半钟头内，升级操作才两个钟头，而大部分时间都是为了保证安全了，这个计划是我自己拟定的，我可不想出什么问题。
我们决定于11月7号晚上20： 00 升 级。
11月6号
11月6号，我主要做了如下几件事情:
n 自己编写了一个数据库压力测试程序，主要是用来测试数据库联接数的，它可以在短时间内高强度地联接数据库。
(注，我是程序员出身的数据库管理员，精通ORACLE，JAVA，DELPHI，POWERDESIGNER，ROSE，大家有活的话，可以找我啊。打个广告先。呵呵。)
n 在咱们PUB上发了帖子，Fenng，biti_rainy，chao_ping也给予了指导，在此感谢一下。
n 打电话询问了几个ORACLE人员。
n 在生产机上建了一个小型测试库，用来对数据库进行试验性升级.
总的感觉是：10个做ORACLE的，有5个对HP上安装ORACLE比较熟，在这5个中，有2个对安装ORACLE9I比较熟，在这2个中，可能只有1个，或者半个实施过RAC，而我象这样要做升级操作的就更少了。
我比较信任有实际实施经历的人，在我的咨询中，大部分有资格做判断的都认为只要严格按照升级手册操作“应该”是没问题的，这使我安心了不少。
只有一个ORACLE支持用肯定的语气告诉我：
“出问题是难免的，ORACLE数据库软件升级失败倒没关系，要是数据库升级失败了，数据不能用了，你就惨了。哈哈。”
我没办法，只好尽可能地收集出问题案例进行分析，以期在遇到的时候不会措手不及。我大概准备了近30种异常案例。
11月7号
11月7号20：00，升级操作开始，这一次他们的主任也来了，还给我们带来了夜宵，比上次待遇要好一点了。呵呵。
这次升级很顺利，没有遇到什么问题，我就不细写。
当时有点恍然若失的感觉，咋就不出点问题呢，我可是准备了30个案例啊，一个都没用上太亏了吧。呵呵 。
现在我也可以说只要按照操作手册做“应该”是没什么问题的。
顺便提醒大家的是：ORACLE的负载平衡在高密度高强度的联接操作中根本不发挥作用，它更倾向于联接其中的一台主机。
凌晨6：00的时候，我给公司发邮件，上面只有四个字：“升级成功。”。
是不是有点象乔峰当年经过一番恶战，干掉一厉害对手后回到丐帮轻描淡写地说：
“把某某给杀了。”
呵呵。
总结
总结：这是我搞IT以来压力第三大的一次实施。
我的经验：
l 最重要的是一定要有在强大压力下保持冷静头脑的能力。
l 紧张没关系，害怕没关系，但是头脑一定要清楚。
l 别人的意见要听，自己要有主见。
每个人在压力之下崩溃的症状是不一样的，有的人可以从面部表情看出来，有的人可能面部没反映出来，可是他却发出错误的指令。你所要做的就是要保持清醒的头脑。说句实话，这个项目有几次都到了失败的边缘，我很佩服自己没有乱了阵脚。
扫一扫
366
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
