?

?????? 在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 上的高人

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

Blog： http://blog.csdn.net/tianlesoftware

網上資源： 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表空間和數據文件的關系，否則拒絕申請

?

?

轉載于:https://www.cnblogs.com/tianlesoftware/archive/2010/11/28/3609888.html

總結

以上是生活随笔為你收集整理的AIX 修 炼 之 路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。