RAC历险记

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开始正式营业。此计划已经由该通信公司公司向上汇报，并在当地的电视台发布该通信公司为了更好的为用户服务，将在某月某日进行系统更新，给用户带来不便，深表歉意的字样。

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/257699/viewspace-814494/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/257699/viewspace-814494/