RAC历险记

iamweng

国庆前夕公司正式和某市的网通公司签署97系统的升级合同，我公司作为集成商，将负责和应用程序开发商（南邮），硬件厂商（HP），数据库供应商（ORACLE）的协调。两台HP7410主机已于国庆前到货，我公司负责主机到货后的初步验收，（也就是看着一个大柜子安全地放在机房外，确保没有外部损伤）。
背景：网通公司97营业系统确实一直在使用，下属400多个客户端每天都在ORACLE数据库中存取数据，网通公司提出如下要求：1.不能停止营业。2.升级失败后要能安全回退旧系统。3.要快。他们的旧系统环境如下：97年的系统，HPK系统机型，ORACLE7.3.2。应用程序开发商不能肯定他们的系统能在ORACLE9I下无异常反应，向网通公司提出提供测试环境的要求，出于拿到集成合同的目的，我公司承诺提供测试机。结果HP不答应，我们承诺无法兑现，网通反应强烈，（网通里面的和我们接触的人全是女的掌权，开协调会的时候7,8个女的把我们项目管理人员骂得狗血喷头，连说话的机会都没有）
过完国庆，10月8号，我们公司项目人员进驻网通，一个管理人员A，原计划还有系统人员B的，只因他在另一个项目里脱不开，暂时就没来，还有一个就是我，公司想省了ORACLE的服务费，由我负责数据库的安装。　日程安排大致如下：一天系统安装，一天数据库测试，一天应用程序测试，晚上升级，第二天早上7：00－8：00业务人员在前端测试，8：00开始正式营业。此计划已经由网通公司向上汇报，并在当地的电视台发布网通公司为了更好的为用户服务，将在某月某日进行系统更新，给用户带来不便，深表歉意的字样。
10月9号，HP工程师A如期进场，我们协助将主机搬到机房中的预定位置。（也就是搬机子，当民工，也是挺讲究的，暂先不表），直到深夜12：00HP11i操作系统还没安装完毕，其间HP工程师避着我们到厕所里打了好几个电话，神色有些不对。
10月10号9：00，HP工程师B过来，网通公司召集我们开会，对我们准备实施RAC有些担心，认为技术太新，怕出问题，HP工程师表示没有问题，当我承认我没有在HP机上实施过RAC，网通那几个女的很是不愉。随后HP工程师A，B继续系统安装直到晚上，其间，A，B工程师向北京的HP支持打了好几个电话，从他们的交谈中，我们知道他们在磁盘阵列的安装上出了问题，对网通的解释是这是一种新型号，他们没配过。
10月11号，磁盘阵列配置成功，A，B工程师发现缺少四根光纤跳线，无法和主干网相连，网通大急，查阅备忘录，我公司老早就提醒过负责设计的邮电设计院，他们疏忽了，4条光纤跳线，总共3000多块钱，本市没有，要从北京买，来回三天，工程停下来了。
10月12号，应用程序开发商如期进场，无事可做，面色不愉。（后知，网通还有一部分开发费没有给，南邮这次不想来的）。我们乘机到周围的风景区玩去了。呵呵。
10月13号，无事
10月14号，无事，真是舒服。

iamweng

10月15号，光纤到了，当时真是担心质量不好，又得往北京跑一趟，呵呵。今天HPA工程师退场了，我们看到，B的技术和职位比A要高些，前者只负责安装硬件。下午，HPB告诉我们在软件清单中的MC/SERVICE Guard不是用于ORACLE　RAC的并行版本，正确版本的售价要比这个版本贵6万块，这回大家都傻眼了。HP向上汇报，网通向上汇报，我们向上汇报，顿时感觉到销售人员出马了，暗潮涌动。我亲耳听到那个女主任对他们设备处的人说这件事时略带一点幸灾乐祸的意思：“某某啊，HP说你们软件买错了呢。”那几个女的又把我们管理人员叫过去骂了个狗血喷头。公司开始先是要我们骗客户，随便安上数据库说是RAC，反正他们狗屁不懂；后来又指示我们就这么赖着，让网通去逼HP，给他们装上，反正这个钱我们公司是不会出的。HP开始说那么先装个试用版本，有一个月期限，网通不答应。就这么僵着。
10月16号，僵局ING，我乘着这个机会在两台主机上装了好几次ORACLE9I，算是先练练手。呵呵。
10月17号，上午，HPB说公司同意先安装正确版本的MC，然后从包中拿出一张光盘笑笑说：“我这里什么都有，公司叫我安，我就安了。”这小子挺憨厚的，我喜欢。我开玩笑说：“我要是网通，我就把不把服务费给HP了，给你算了。”直到晚上7：00，HPB没有能把MC装上，我在陪他装的时候，我无意中发现有一个软件叫MC/SERVICE　Guard For RAC extention,我意识到应该是这个，我在资料看到这是HP为ORACLE　RAC出的最新的支持软件，我坚持应该装这个，他打电话问了以后才明白，原来应该在原来的MC才再安装这个支持包，而不是卸下原来的MC装新的MC。20：00，MC安装成功。

iamweng

开始了数据库的安装。网通问我要多久，我说：“顺利的话4,5个小时。”当然我还有一句话没说，不顺利的话就说不准了。呵呵。我事先将安装程序COPY就硬盘上，我不能保证我就安一次就成功，加载ORACLE安排盘的命令特古怪，有时还弹不出来，当时在HP体验中心的时候，我是加载一次，重起一次，加载一次，重起一次，反复者四，才将四张安装盘拷到硬盘上，现在有HPB在，每CP一张盘，我们就KILL一次，不用重启了。事实证明，我重装了3次。呵呵。

iamweng

安装之前，我检查了核心参数设置，我有一套核心参数设置是参考了GOTOTOP和COOLY提供的文档做的，和HPB进行讨论，因为不是对所有的核心参数意义都了解，在他的建议下做了调整，而事实证明，他说的都错了。我检查了磁盘阵列的宿主关系，发现没有改成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小时不眠不吃了，喝还是有的。呵呵。

iamweng

10月19日，应用开始测试。我回去睡觉。
10月20日，应用开发商说好了，没问题。我表示怀疑。看看他们的恢复方案，如果升级失败，按他们这么做能回得去才怪呢。项目管理人员偷偷跟我说，不管，出问题是他们的事。我说好吧，但最起码的数据库压力测试还是要做吧，400个联接总要联一下吧，只要这个没问题，剩下的问题就是不大了，他说他们联过了，到了40个联接，测试机的内存就没了，没法测了。我只好说，我已经说过了。下午HPB把裸设备全部划完，除了几个25G大小的裸设备外，730G的磁盘阵列以0＋1的方式，全是2G大小的裸设备。HPB在那里敲了一下午的键盘。
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查，也有不少是这样建议的，我回忆起当时和HPB在修改核心参数时他倾向于保守的参数设置时，我意味到这可能是出现问题的原因。下面不断有电话打上来，纷纷抱怨不能联上数据库了，问是怎么回事？此时我高度紧张，连后悔当初为什么不坚持做压力测试的心思都没有。此时已经是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营业结束。

iamweng

现在在我面前的有三个问题，一是时间，二是MEM，三是SWAP。项目管理人员说：“回去先休息吧，明天再说。”项目管理人员其实也就是这个项目的项目经理，因为我没有休息，他也不好意思一个人跑回宾馆睡觉，得陪着，然后让那几个女的骂，光纤的事，MC版本的事，估计公司也没少找他麻烦，私下说我哪知道这么多，早知道就不当这个项目经理了，早就心力交瘁疲惫不堪了。拷，明天还不是我的事。我想了想，今天晚上必须解决MEM问题。（得他也只好陪着，估计心里是大大不爽。）可是我没有思路。好象也没有体力了，呵呵。可是明天的用户数肯定会突破300，到那时，MEM肯定是不够了。怎么办。我在查我的资料，gototop写的＜＜Oracle9i进程的内存占用问题＞＞让我受益非浅。这是ORACLE的BUG，22：00时，我对机房的人说：“要停一下数据库。”他说这可能要给他们主任说，他们主任不在不好办，妈的，都不管了？我观察了数据库的情况，23：00，我停数据库，修改了BUG，重启，没人知道。呵呵。我也回去睡觉了。

biti_rainy

检查你的  
QL> show parameters pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 25165824


workarea_size_policy                 string      AUTO
SQL>

设置为 auto 表示 独立模式登陆下所有进程 PGA 由oracle 自动管理和分配，使用共同的内存空间。整个大小由前者设置。
根据你的情况，若内存4G,SGA若你只设置了 800M还不慢，那该参数可以设置为1G以上都可以（若没有其他应用跑在服务器上可以增加SGA）

至于内核参数，应该往大一点的好些，即使出问题也是资源枯竭连不上的可能性大

狗拿耗子

真够危险的，顶一下。

bloomit

怎么看着和小说似的。。。

连载呀。。。

DBAORACLE

且看下回分解...