AIX 修 炼 之 路

 

       在AIXChina 论坛上看到了一个高人写的AIX 成长过程，看了挺有感触的。 出处现在无发查询, 全文如下：

 

修 炼 之 路

 

最近在朋友的推荐下看了热播剧集《prison break》，确实精彩，片中无处不在的细节让人不得不佩服男主人公的schedule实在是做得完美。感慨之余想起到相关论坛上看看大家的评论，这才发现很多我捕捉到的细节和心领神会的method居然没几个人看懂了。不由得让我凭空多了一层念想，是自己也能够适应fox river那样的牢狱生活，还是多年来AIX service的工作经历让我已与往日不同。嘿嘿，我情愿相信是后者。

 

hacmp.棍子.灵异现象

     hacmp是IBM在P系列服务器上使用的群集管理软件，安装配置很方便，在实际使用中可处理常见的系统单点故障，从而提高整套系统的可用性。但是使用hacmp的环境常常出现一些奇怪的现象，从而让维护的技术人员头疼不已,我们称之为“灵异现象”……

     2002年的夏天，湖南长沙，XX医院，hacmp互备。

     这个医院的财务系统用的是IBM H85的双机，hacmp互备模式，DB2数据库，2台机器分管住院部和门诊部的财务系统。不知道从哪一天开始，这套系统也碰上了让人头疼的“灵异”。医院的系统管理员说他们在正常使用中发现住院部的财务系统运行突然变慢了，经检查才发现住院部那台机器已经宕机，住院部业务已经由门诊部那台顺利接管，只不过看起来由于系统资源紧张，所以才让窗口的业务人员发现速度有异。接下来，系管重新开机，重新启动hacmp，一套流程走下来，住院部主机重新担负起了自己的任务，业务窗口速度也恢复了正常。

看上去一切都挺好，系统环境又恢复了正常，只不过……

三天以后，住院部主机又挂了。再来一次恢复流程，住院部主机起死回生……

三天以后，“挂”就一个字……

如此反复，这家医院的系管已经可以掐指算出住院部主机即将到来的“死亡时间”，误差不超过3小时。在这家医院信息部领导精神全面崩溃之前，他们找到了我所在的公司。

老板给我交代任务的时候，附带告诉我在此之前已经有资深的软硬件工程师到现场全面检查过了，每个人都是拍拍胸脯告诉可怜的系管自己这一块绝对没问题然后以尽可能快的速度离开了现场，留下系管一人绝望的面对即将到来的宕机时间……死亡无法避免。

说实话，这附带信息对当时只有一年AIX经验的我来说不是什么很有用的消息，除了凭空多出许多压力之外。

到了现场，我一直在想一个问题——系管的头发是一直这么少，还是这段时间才发生了变化。问题没有答案，我只希望自己能够帮到这个可怜的同行，看上去他虽然很热情，但是和遍访名医的重症病人家属一样，眼神中已经失去了“求生”的信念。

排除杂念，对着住院部的主机我砍出三板斧——df，errpt，diag。无效。一切看上去都很正常。细想想，这也正常，这三斧头是个人就会砍。想必在我之前来的那些资深已经都砍过三十几斧头了。再看看hacmp.out文件，顿时有了点不敢相信自己眼睛的感觉——已经生成了近50MB的文本文件。原本想从里面找点信息的想法一瞬间也去了大洋对岸。难怪资深们都闪人了，我似乎有点明白了。

口中默念着高中班主任留给我的名人名言——“人啊！不能在一棵树上吊死，让我们一起来换棵树吧！”——我杀向门诊部主机。

系管有些惊讶，但还是尽量委婉的告诉我：“严工，这台机器是好的”。

“知道”，回应：“我看看”

同样无效的三斧头过后，总算hacmp.out给了我一线希望，这台机器的hacmp.out相比较而言还算正常，虽然也过分的达到了11MB的大小。

在“尽量”仔细的阅读hacmp.out之后，我开始深刻理解资深们的难处了。巨量的事件脚本记录给“阅读”带来了麻烦，2个小时的仔细阅读之后，除了感觉眼睛有点疼，我暂时没有别的新见解。

无奈中，我开始快速翻屏，现在回想起来，当时这么做可能是潜意识中的什么元素起了作用。如《骇客帝国》中飞快滚动的黑底绿字由下至上的掠过屏幕，除了更加不可阅读之外，似乎没有别的什么好处了。

等等……这是什么……

由于快速翻屏和每个事件纪录长度大致相等的2个重要因素，加上视觉暂留效应，我在屏幕上的特定位置看到了近乎稳定的事件名称fail_standby_adapter和join_standby_adapter。这两个事件记录名称如此显眼的出现在我面前，确实让我精神为之一振。这样的情况下我还能看到这两个事件，只能说明这两个事件出现的次数特别多。详细检查了这两个事件发生的时间点，得到了让我开始感觉兴奋的消息——每秒钟要发生4到5次的fail_standby和join_standby。这说明有块standby的网卡不断的退出和加入到standby状态。顺着思路往下想，如此高频率发生的事件记录除了要写入本机的hacmp.out还要通过网络写入到另外节点的hacmp.out，这样会直接导致另外节点的hacmp.out处于持续打开的状态，同时也会占用相当大空间的file buffer且由于不断的写入而不会释放。物理实存用完之后开始使用paging，加上业务压力，paging用完之后，主机必死无疑。这样一个内存耗尽的过程，三天都算是撑得够长了。

带着激动的心情我检查了不断fail和join的standby网卡的物理位置——门诊部主机的standby网卡，这就可以解释为什么一旦住院部主机宕机，门诊部主机可以接管住院部业务除了速度慢之外而不会再宕机。因为这个接管时间点之后，原门诊部主机standby网卡已经接管了住院部主机的service地址，当然也就不存在fail_standby和join_standby的事件发生了，取而代之的是住院部业务系统的service网卡有丢包——表现出来的现象就是住院部窗口业务运行慢。

因为做过diag没有发现网卡损坏，所以问题发生的原因如果不是网线就是交换机端口。

等我告诉那个心灰意冷的人问题原因就在一根网线上时，你完全可以想象他当时的表情。而我当时脑海里出现的场景则是我父亲当年用一根木棍就修好了我母亲厂里的巨型空调并且赢得了她的芳心，他只是用棍子敲了敲那台不肯工作的机器一切就恢复了正常。多年以后，我父亲每每提起此事，总是得意地告诉我“关键不在用什么棍子，在于你要知道敲哪里”

换过一根网线，我在两台主机的hacmp.out里面没有再发现不断生成的事件记录，此刻对我来说，问题已经解决了。而忐忑不安的系管估计要等到下次“死亡时间”之后才能放下心来了。

回顾整个过程，实际上hacmp的事件记录文件hacmp.out已经清晰而忠实地记录了发生过的点点滴滴，如果你有足够的耐心和方法，你肯定可以从中找到答案，肯定可以从中知道你手中的棍子要敲向哪里。仔细“阅读”记录文件，会使我们的PD过程更加顺利。而且，你千万不要认为看似正常运行的设备一定没有任何问题。

离开现场，带着我的“棍子”，开心……

 

 

微码.警察.跑路

 

     在做AIX service的这段日子里，我有个深刻的体会——“开始因为什么都不会，所以胆小，慢慢的，知道了一些，胆子也变得大了起来，其必然会导致出现一些大家都不想看到的结果，多经历几次这样的事情，胆子会慢慢的再度变小”。下面的故事就发生在我胆子好大的时候！

      2003年的春天，湖北武汉，市公安局，S70双机。

      武汉市公安局信息科，S70双机，一台是运行户政管理业务，一台是公安内部信息平台系统。因为这2台S70买的时间比较早，所以配置相对不高，在业务运行高峰期，常常会让各个运行终端的干警们心生郁闷。

为了更好的迎接第XX次人口普查，市局的领导们特意指示信息科要做好细致的准备工作，不要发生意外拖前线干警的后腿。于是信息科领导将指令转化成了一次S70间的配置调整——即暂停公安系统内部消息平台的运行，将消息平台主机上的内存全部转移到户政管理主机上，以尽可能好的配置来迎接第XX次人口普查的到来。
    任务交到我身上，在我这里则转化成了具体的实施步骤“停机-拆内存-加内存-开机”，看起来是件简单任务。至少，除了会浑身是灰之外，我没想到还有什么麻烦事情会发生。

事实证明，通常胆大的人不一定会有好运气。

确认过业务系统都已经关闭的情况下，我开始停机步骤，shutdown –F之后信息平台主机乖乖的回到了OK状态。但是户政管理平台主机则迟迟没有出现halt complete的字样。虽然觉得有什么地方有点不对劲，但在长达10分钟的等待之后，我还是直接关闭了这台户政管理S70主机的电源。

30分钟后，内存物理更换完成，依照service guide的指引我将新加入的内存放在了他们应该在的位置。

加电，开机，LCD上绿色的小字符开始快乐的跳动起来……

只是，跳到了XXXX代码之后，LCD好像停止了动静，连OK字符都没有出现，LCD就停止了跳动。

5分钟之后，状态依然，我开始查service guide，看看这串代码到底是什么含义。结果让人晕厥——service guide上没有这串字母的对应描述，前后的字母串描述都有，唯独少了这一串的解释。

脑袋一片混乱的我开始联想，机器起不来——户政管理业务起不来——全市派出所户籍民警无法工作——全市人民不能上户口，不能结婚，哪怕连死亡消户口都不可以……

说实话，那一瞬间我跑路的心都有了……

定定神，打出场外求助电话，电话打给的是IBM华中区的资深工程师吴炬，简短的交流之后，从他那里我得到了一个意外的答案——他告诉了我sevice guide中对这段字母含义的描述，可是，可是我明明看过service guide了呀！并没有看到这串字母描述啊！在核对过书号和文件大小之后，我得到了当天的第一个重要感受——针对每种机型的service guide经常会有更新，所以会有很多的版本，保持经常下载最新版本的service guide绝对是个好习惯。

回到现场，这串字母的含义是系统微码损坏，需要用软盘重新刷新微码。

接下来的时间是在公司（下微码，做升级软盘）和市局之间飞奔度过的……

刷完系统微码，果然OK字符重现，再世为人了……

系统顺利起来之后我才发现，原来errpt里面已经记录了183天之前微码发生错误的记录，也就是说不管是谁，只要关了机器，那么除非刷新系统微码，否则就是局长来了机器也会无法启动，只不过这次我是在微码损坏后第一个关机的“幸运儿”。这让我得到了当天的第二个重要感受——设备总是有可能出现问题的，哪怕关机之前看上去一切正常，所以在有任何动作之前，仔细检查errpt总归是没有坏处的。如果有可能，关机之后马上启动一次是确保设备处于正常状态的最好办法。

出了市局，我突然发现不用跑路，可以回家的感觉真好……

 

 

Oracle.球.世界杯

四年一次的世界杯在2006年的夏天如约而至，在和平的年代，这几乎就是世界大战的代名词，由于中国队的一贯表现，我不太关注这块没有硝烟的战场。当然，几场枭雄之间的对决还是要亲眼目睹的。那个早晨，带着五星巴西竟然负于法国的疑问我沉沉睡去，一个小时后，我被VIP客户“电醒”……

2006年的夏天，上海，中国XX银行数据中心，P590

在早上6点接到VIP客户的电话通常意味着有地方“失火”了，在没有了解情况之前我只是希望“火”不要烧得太大，但眼看我这次的衷心希望显然没有半分效果……

这家VIP客户的一台满配置P590承载着该行全国法人信贷的业务系统，在这个对于巴西人来说显然比较黑暗的早晨居然宕机了，我一边念叨着“你跟巴西应该没什么关系吧？兄弟！”一边晕乎乎的冲向VIP。

“火”确实烧得有点大——系统重启后，技术人员发现oracle没法启动，经检查发现oracle的code所在的目录没有mount上来，手工mount后系统提示文件系统有问题，需要做fsck。而fsck之后则是一喜接着一惊——喜的是该文件系统可以mount了，惊的是system.dbf和user.dbf消失了。O_Ob

OK，让我们切到备机好了，恢复业务系统online是这个时候第一目标……

二惊——用data guard保持数据同步的备机在头一天已经切断了数据同步状态……

那么，让我们用磁带里的备份来恢复数据吧！该是那个小屋子大小的磁带库发挥作用的时候了……

三惊——该数据库resetlogs在头一天的凌晨已经被重置了，而重置之后没有重新做全备……

我已经开始考虑是不是有人急于下岗而没有足够的勇气提出来，想通过这样的事件来促成自己的心愿。

之后的恢复步骤这里不再赘述，训练有素的X行技术人员启动应急预案，在最短的时间内恢复了这套涉及全国范围的法人信贷系统，只让遍及全国的相关工作人员稍微休息了半天而已。

而我面临的问题则是要搞清楚是什么原因导致这台P590在明显和巴西没什么关系的情况下，会如此激动的通过宕机来表达自己的情绪。

形势似乎对我们不利，系统宕机——文件系统损坏——修复之后重要文件丢失……

当年的三斧头现在已经升级成了snap，PFE，PSDB。挥舞完这三斧头，我得到的信息是这个文件系统在宕机前30小时已经出现了错误的文件控制数据，并且通过errpt提醒用户需要做fsck进行检查，只不过可惜的是无人理会。同时，二线技术支持人员告知我系统宕机的原因是AIX在对此文件系统B+树扫描时，发现此文件系统不一致信息过多，而采取的自动重启，从而在umount的状态下对其进行自动fsck。这一点我也在alog里面得到了验证。

问题已经转变成了文件系统为什么会损坏了？

询问过X行相关技术人员之后，我得到了重要的信息——宕机前32小时，此应用系统由于undo扩展过快，所以DBA打开了undo的autoextend参数。而undo文件正好就放在和system.dbf、user.dbf同一个目录中。参数修改了1个多小时之后，oracle突然crash了，oracle工程师到现场进行了恢复动作，在修复之后出于某种原因的考虑断开了data guard的数据同步链。

带着这些重要信息，我在三方会议（X行，我们，oracle）召开的头一天夜里潜入“敌营”——metalink，一边翻腾一边庆幸自己还拥有metalink的账号……

会议正式开始之前，我已是胸中有伏兵了，虽不敢有完胜的奢望，但已然不是之前的心中暗自理亏的状态。在和team中的成员share了“敌营”中的收获之后，我特意的询问了leader关于这些杀手锏的使用时机问题。他告诉我的原则简单明了——“看看oracle的态度再说。”

会议开始，oracle代表慢条斯理的扔出了一句话“oracle认为，既然是操作系统发生文件系统损坏、无故宕机，同时丢失了重要的数据文件，那么问题的责任应该在操作系统这里，如何检查、修复也请操作系统这边着手进行。”

当时我的脑袋里马上回想起了周星星的那句“兄弟！球，不是这样踢滴！”

虽然事实上我并不喜欢踢球，但是更加不喜欢人家把球踢到我们球门口。

“首先，问题的起因在于undo文件被设置成了autoextend，但是并没有设置maxsize,同时自动扩展的步进参数next被设置成1MB。而max_tetention参数还是默认的1080也就是3小时。从修改参数到文件系统被撑满只用了1小时20分，undo文件扩展了22GB。而在9i里面把undo设置成autoextend但并不设置maxsize，undo会一直增长而不重用过期的回滚段，这是个地球人都知道的bug，undo文件所在的目录被撑爆只是个时间问题而已”

我先扔出了在敌营中的第一个发现，立马发现oracle工程师表情明显变得有些呆滞。接着乘胜追击……

“其次，让我们来看看undo文件在这么短的时间内扩展了22GB是否正常？在metalink里，我找到了5个与undo文件在某些特定情况下会产生非正常的巨量增长的相关补丁，由于我metalink账号的权限不够高，有些未公布的补丁我还看不到，所以我并不确定能够修正undo文件产生巨量增长的补丁只有5个。”

已经发现刚才还慢条斯理的那人脸色有些发白，好，我们继续……

“第三，在宕机前30小时，操作系统已经发现这个被撑爆的文件系统出现了错误的文件系统控制数据，同时建议马上做fsck修复。当时因为undo被撑爆，所以oracle crash了。在调整undo的文件位置的过程中，oracle重新成功启动关闭过多次，这个时间点的system.dbf和user.dbf还是完好而且可以访问的，否则oracle当时就无法正常启动instance了。但是很遗憾的是当时在场的oracle工程师没有注意到alert.log中间的提示，所以没做任何处理或者建议。”

不再观察他的表情了，已经不忍心看下去了，直接带球到对方禁区好了……

“最重要的一点是，我们不理解为什么在oracle crash的应急处理完成之后会因故断开data guard的数据同步链，这样直接导致备份系统由于缺少一天的数据，无法立刻online。而且，主系统的resetlogs也被重置，使从磁带恢复丢失的文件也成为了不可能完成的任务”

带球入禁区加上射门，一气呵成……

这场“球赛”已经没有悬念了……

三方会议后，为分析此次“灾情”的原因和提出改进建议方案，我提交了一份五千字的报告，鉴于是属于公司密级的文档，这里就不提供了，不然这“AIX与我”的故事就要破万字了。

回顾整个过程，给我最深的感受是想做好AIX的service，就不能够只熟悉AIX，与其相关的方方面面最好都能有所涉及，一个全面的中场球员需要的是能攻能守，更重要的是全局观。

 

马上就要进入AIX与我的第六个年头了，回顾这段历程，AIX让我学会了耐心、让我体会了关注细节的重要、让我感受到了完美schedule的强大效力。以至于我希望如果有一天真的不幸蒙冤进了fox river这样的牢狱，但愿监狱管理系统用的是IBM P系列，这样我或许还能有逃出来的一线生机……

 

 

 

 

转自AIX China 上的高人

------------------------------------------------------------------------------

QQ:492913789

Email:ahdba@qq.com

Blog: http://www.cndba.cn/dave 

网上资源： http://tianlesoftware.download.csdn.net

相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx

DBA1 群：62697716(满); DBA2 群：62697977(满)

DBA3 群：62697850   DBA 超级群：63306533;    

聊天 群：40132017

--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请