一次波折的现场服务

风云突变的升级

5月２９日，我们在大连一个重要的客户把应用升级到新的版本，升级过程还算顺利，在接下来的周六、周日全天运行正常，项目组的同事老吴等人似乎看到了升级成功的希望，如果系统能够在周一顺利运行，就可以宣布升级工作基本完成了。周一这天，黄历上写着"诸事不宜",果然到了周一上午的8:00开始，服务器的CPU资源开始非常紧张,UNIX系统平均负载达到11左右,CPU占用基本在100%左右运行,而升级前,UNIX平均负载在0.3 以下,CPU占用率在20%左右.出现问题以后，公司也远程提出了一些解决方案，但毕竟是因为程序升级，导致的问题，加上医院是5月份采购的新机器,用户对此意见比较大,对处理的情况也不是很满意。在公司分析的情况来看,问题应该是出在注册函数上,逻辑读很高.导致了大量的热块冲突。

从发过来的awr来看，性能确实到了很糟糕的地步：

1. 逻辑读次数到了近百W/S,而升级之前全都在30W/S以下。

Load Profile

2.Top Event来看，典型的热块冲突导致的性能下降：

Top 5 Timed Events

3. CPU资源，确实非常紧张，由于没有采集到OS数据，只能用AWR中的信息来计算CPU资源的利用率：

CPU%=BUSY_TIME/(BUSY_TIME+IDLE_TIME)*100%

我们这里的利用率为： 2,411,841 /(2,411,841 + 469,791)*100%=83.70%,cpu平均占用确实到了很高的地步，如果业务进一步增加，系统down机只是时间问题。

4. 注册验证程序相关的SQL的Buffer Gets很高，平均达到几十万的水平，这对于一个简单的注册码验证的简单功能来说，太高了。

乾纲独断的会议

周一下午，经过远程的一些处理情况无明显好转，于是组织了几位当事人当面沟通，确定解决方案;与以往不同的是老大参加了这次的会议。讨论接近尾声，大家似乎未就解决方案达成一致，这时候HT的眼神游离到了我的身上，"老贺，还是你去一趟吧？"。

会议结束已经是下午5点了，幸运的定到了最后一个班航班的最后一张机票。在与公司小罗一起去机场的路上，聊到几年前的一次江湖救急，凌晨两点去客户现场的经历，历史总是惊人的相似,所不同的只是地域的差异；而想到即将面对的工作，与几年前的情形并无二致，回忆多了，就感觉自己的年华慢慢的逝去了。。。。

深夜的争论

晚上9:30左右出了大连机场，给老婆发了个短信报平安。医院离机场比较近，不一会儿就到了医院。到达办公室，看到老吴、老陈等同事，似乎都比较疲惫，大家有气无力的寒暄了几句，就进入正题。晚上由于系统比较闲，可以做一些维护，必须快速确定实施的方案。与M主任和老孙商量解决方案,我提出直接从RBO转到CBO下来运行，具体方案如下:

利用晚上的时间收集数据库对象的统计信息 早上6:00左右改成CBO运行,如果能在登录高峰期8:30以前不出现CPU 100%的情况,就可以坚持使用CBO,出现的性能问题,通过调整应用的SQL来解决. 如果不能撑过8:30,改成RBO运行,并删除统计信息,并收集注册函数相关的统计信息;这步需要的时间很短,可以快速恢复到RBO下. 如果上面方案都不能起效果,就采用修改的注册函数,取消产品的注册验证,绕过有问题的SQL,这一步是万不得已的选择，这样做会带来后续很多的工作和商务上的工作。

医院是前二周刚刚从9i升级到10g的，在9i中一直使用RBO,升级到10g时，为了与9i的执行计划尽量保持一致，在10g中就继续沿用了rbo。在10g中，一般推荐使用cbo，他们也是我们用户中仅存的运行rbo的较大规模且比较"顽固"的用户。使用rbo不一定是造成此次问题的原因，但由于时间紧迫，无法详细追查产生注册函数大量逻辑读的原因，医院的要求也是快速有效的解决问题；根据以往的经验，在10g的cbo下，应用的大部分SQL是能获得相对较好的执行计划,正是基于这一点，我提出了上述直接转换到CBO运行的方案。

由于医院M主任对我们在公司的处理情况有意见,不太认可我提出的方案,认为应该调整实施顺序,直接使用周韬修改的注册函数,直接上cbo的变化太大.我向其说明了各种利弊,在我们的一再坚持下,并保证根据以往的经验,在cbo不会有太大的问题,M主任最终同意了我们提出的方案；但M主任同时提醒，周二的业务量比周一还要大，如果转换不成功，代价将会更大，同时周二李兴华会带一个目标客户过来参观;这样我的压力就更大了。这个时候，我们知道任何技术都是有风险的，做技术要求胆大心细，这时候"胆大"的成份占了上风，我认为这个时候，一定的冒险精神是必须的。

意料之外的错误

写好了收集统计信息后的脚本后,为了加快收集速度,开了8个并发进程进行收集，对历史数据采样10%，在线数据采样20%；用unix下的nohup放到操作系统后台来跑，处理完脚本这时已经是晚上11:30了。为了保证第二天有足够的精力处理问题,就准备回宾馆休息,老孙家离医院很远，我建议他与我一起到医院附近的宾馆去住，明天早上一起过来，这样能多睡会儿,看得出来老孙这几天在医院受到的煎熬,脸上挂满了疲惫。睡觉前感觉特别饿，突然想起今天晚上除了吃了点飞机餐，还没吃晚饭呢，老孙和我不约而同的抱怨到做技术所承担的压力、微薄的收宜、身体的伤害。。。甚至谈到了转行的话题。都是些技术人员抱怨的老三篇,但还是不得不把手机的闹钟设置到早上6:00，不一会儿就入睡了。。。

东北的太阳起来的早，不到6:00 左右太阳就射进了窗户,闹钟也响了，我们极不情愿的从床上爬了起来。早上6:30左右到了医院,要开脚本输出的日志，看到昨天的脚本有一个失败,在收集历史数据表出错了,出错的原因是这部分因为数据很大,排序时temp表空间不够引起的.这下麻烦了,很多应用是连接历史表进行查询的,这部分统计信息不可或缺,经过商量后,我们决定对历史数据的表执行5%的采样,收集统计信息,如果能在7:40前收集完,就继续实施cbo方案,否则就只能回退到rbo方案。同时打开邮箱,发现同事修改的注册函数新脚本已经发过来了,实在不行就只能换函数运行.老孙这边立即着手新函数的简单测试,我这边接着跑采样收集的脚本.所幸的是在7:35左右跑完了脚本,采样5%能否得到相对好的执行计划?我心里打起了鼓….

仅凭感觉的调整

切换到CBO还需要调整几个参数，接下来就是切换到cbo,修改几个参数,切换到cbo:

optimizer_mode=all_rows

optimizer_features_enable='9.2.0.8'

设置optimizer_features_enable='9.2.0.8',可以禁用一些10g cbo的一些新特性,保证执行计划与9i尽量一致,这也是一个经验值,很多HIS的sql在10g下,由于物理设计的原因执行计划比较奇怪，比如复合索引采用的较少，很多sql分别走两个单列索引再连接的情况。这样做的另一个原因是大部分SQL原来在9I的时候，运行的情况都比较好。修改完参数,医院M主任和小T等人就到了,一看时间还不到7:50,看来M主任他们对我们的方案还是比较担心,这也是可以理解的，RBO换CBO这件事，我们跟医院提过多次了，时间上也拖好几年了，提一次被否决一次，这次调整能够成功吗？况且rbo到cbo也是比较大的调整了。

峰回路转

接下来的就是等待业务高峰的来临,办公室这时的气氛突然凝重了许多,医院上班时间在8:00，这个时间是集中登录的时间，如果能够撑过这个时间，就证明换CBO的方案基本可行。我在ssh的unix终端上,打开HP-UX的glance开始监控系统状态;看着系统负载一点上来了,连接的用户数也越来越多,一直持续到8:20左右,process达到最高值800左右,这时cpu占用率在40-60左右波动,看来cpu能够撑过业务的最高峰了.大家都松了一口气,气氛开始变得轻松起来,可我还是比较担心后面的应用问题，感觉不可能这么顺利,虽然今天黄历上只写着"忌：嫁娶.安床.探病.作灶",我们的做的事情似乎不是今天忌讳的范围。。。

这个时候最怕的是电话响,担心的事情还是发生了,电话不断的打进来,HIS中的几个常用功能,比以前慢.一些窗口开始出现了排队现象.主要集中在几个常用的功能上:

收费界面直接切换到挂号界面 挂号安排修改 医嘱发送为费用 LIS中的条码生成 体检中的模块登录

…..

这个时候,用awr、ash或sql_trace手段提取出问题的sql，发现这些sql在rbo方式下都执行得非常好，这时老孙说"老贺，要不我们还是退回rbo吧？"，最不想看到的情况还是来了，环视一周，办公室所有人几乎都同意老孙的意见，这时只有我自己支持自己了。。。

我把影响sql执行计划几个因素梳理了一篇：

系统统计信息，如cpu时间，多块读时间，单块读时间等;通过dbms_stats.gather_system_stats收集 数据库对象的统计信息，这部分我们已经做了 优化器相关的初始化参数

一般情况下，跑我们的应用,系统统计信息不收集也问题不大，我查询sys.aux_stats$视图，发现cpu速度和io 相关的指标都没有收集，用脚本收集了这部分的统计信息后，发现几个功能的sql执行计划已经正常。但有2个功能的sql还是不正常,这时能影响执行计划的就只有调整初始化参数了，因为那边不可能快速修改应用，是指望不上的；但调整初始化参数的影响比较大，可能会影响部分正常的sql语句，最后经过在session级反复测试，确定以下值：

optimizer_index_caching =50

optimizer_index_cost_adj =21

在这样的设置下，几个重要功能的sql 执行计划终于都走正确了，尝试这对参数设置的时间，反复试了十几种不同的组合，老孙在旁边看着说，"老贺，你真是能折腾！"。

处理完些事情后，已经到了10:30了，业务高峰期已经过了，看来今天cbo的切换初步大功告成，这时候李兴华带过来参观的用户也来了，他们到办公室的时候，我申出头打了个招呼，感觉我们的调整，似乎没有影响到潜在客户对软件的映象,呵呵。。。

下午的时候，我让老孙不断的取awr和ash,把top sql取出来，不停的分析，又处理了些执行计划不正常的sql;不知不觉，到了下午的6:00了。今天的调整总体来说，还算成功！我们都长舒了一口气。

最后的虚惊

周二的处理还算成功，不过Ｍ主任还是要求周三上午再观察一下，才能让我走，我答应了M主任的要求。晚上与老吴、老陈等人一起找了好久，也没找到一家正宗的东北菜馆，吃了顿感觉更象鲁菜的东北菜，可能是与山东隔渤海相望，确实大连的饮食习惯更象山东。吃完了饭，我们又去了临近的星海公园逛逛，看见了一对对年轻的情侣,生活真美好呀。。。

周三早上8:00左右，就被老吴的电话吵醒了，说医院的体检出了严重的系统性能问题；我一下懵了，不会这么残忍吧。。。。

等我到医院时，老陈已经处理好体检的sql了，刚才的问题就是因为一个sql执行计划不正确，导致系统整体下降明显;原来是虚惊一场。系统顺利度过了业务最繁忙的时间，cpu占用率在15-25%之间波动，unix 平均负载全都在0.3以下，基本上与升级前的情况相同；10:00左右，向M主任汇报了处理的情况,同意我打道回府。 回顾这次处理情况，都是些比较“粗糙”的技术，由于事发突然，根本没时间让你仔细分析和测试，这个时候就只有靠直觉去解决问题。

回家！

定了下午13:55的机票 ,飞回了重庆。出了重庆机场，感叹到今年重庆的气候真好，难倒三峡工程对气候的影响变好了?按照我们家的"小传统"，一人出差回来，另一人必然准备好丰盛的家宴迎接。。。。回家真好！！

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。