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系列，這樣我或許還能有逃出來的一線生機……