沒有無緣無故的愛，也沒有無緣無故恨，設備故障的產生也總會伴隨著一系列的愛恨情愁。事情的經過是這樣的。聯通用戶為了節流，要將以前不怎么使用的HP小型機(rx3410)搬遷到一個相對重要的位置，做為新系統的數據庫服務器。因為這個重要性僅僅是相對的，所以他們沒有征詢相關技術人員的意見，一群粗人就開始斷電、搬運，場面火暴，干勁實足。
在新的位置，他們將能插的線都插上，將能打開的電源都打開，系統啟動畫面如期而至，似乎大功告成了。但是粗人也有細膩的一面，系統是啟動了，但還是要檢查一下應用是否啟動正常，如：雙機熱備程序，數據庫服務進程是否啟動。他們熟練的敲擊著鍵盤，錯誤的提示隨著回車鍵有力的敲擊應聲閃爍在液晶屏幕上。粗人們終于為他們的魯莽負出了代價。
由于沒有嚴格按照操作規范進行斷電、加電，造成磁盤陣列數據丟失，操作系統無法正確識別磁盤陣列數據，導致磁盤無法加載(mount)，應用也就無法正常啟動了。但是磁盤各項指數均正常，沒有異常的紅燈閃爍。造成故障的原因找到了，但解決問題就沒那么簡單了。就像我們都知道腐敗是體制的問題，但是如何治理腐敗就沒那么簡單了。設備故障沒有腐敗那么復雜，但我們還是要了解這些設備運行的機制是什么，才能找到解決問題的辦法。
首先讓我們了解HP-UX是如何管理硬盤存儲資源的。它主要是采用邏輯卷方式來進行管理。要說清整個機制，先要介紹幾個概念：
- 物理卷Physical Volume，稱為PV：指物理上硬盤，一個硬盤就是一個PV。
- 邏輯卷組 Logical Volume Group，稱為VG：一個VG包含整數個PV，可理解為一個大硬盤。
- 邏輯卷 Logical Volume，稱為LV：相當于對大硬盤進行邏輯分區， 一個VG里可有若干個LV。
- 文件系統 File System：在邏輯卷的基礎上，可建立文件系統，然后 MOUNT到一個目錄下，這樣就可以文件存取的方式來使用這塊硬盤了。
當然，您也可以不建文件系統，而直接把LV當作裸設備(raw device)，以TRUNK方式來存取數據，許多數據庫都是用這種方式存取數據的。
通過以上概念的解釋，我們可以得到一張以上概念的關系圖，關系是很重要的。正所謂：關鍵不是你懂得什么，而是你認識什么人。我再補充一句，把認識的人織成一張網，你就是處理關系的高手了。
有了這個關系圖，這種你中有我，我中有你的關系也就清晰的呈現在我們面前，即物理卷(PV)即表示一個磁盤，多個磁盤可以組成一個卷組(VG)，這個卷組(VG)又可以被劃分為多個邏輯卷(LV)。了解了這種關系，我們解決問題的思路也就確定了，首先從底層開始檢查，首先確定磁盤是正常的，因為磁盤狀態燈均是和諧的綠色，而且通過磁盤管理軟件連接也顯示磁盤工作正常。
確定最底層的硬件沒有問題后，我們懸著的心開始逐漸下浮，因為磁盤沒壞，磁盤中保存的數據還有救。但這也只是理論上存在挽救的可能，所以那顆脆弱的心還不能沉底，就讓它懸在半空吧。接著通過lvdisplay –v 這個命令檢查LV的狀態，顯示結果提示VG無法激活。為了確認以上命令是否正確，可以通過vgdisplay –v看檢查VG的狀態，結果顯示disable，即無法激活。
通過以上關系圖可知，只要保證VG下的所有磁盤正常，VG即可正常啟動。但是我們已經檢查了磁盤的狀態，一切正常。為什么呢?VG被那幫粗人折騰的心情不好，罷工了嗎?當然不是。首先我們檢查一下VG與磁盤的映射關系，通過命令strings /etc/lvmtab即可看到VG與磁盤硬件地址的關系。然后再通過命令ioscan -fnC disk檢查，奇怪的事情發生了，VG下的磁盤硬件地址里有/dev/dsk/c0t3d0和/dev/dsk/c0t4d0，但是通過ioscan命令檢查的結果卻沒有這兩個硬件地址，反而多出來另外兩個硬件地址/dev/dsk/c4t0d4和 /dev/rdsk/c4t0d4。兩種檢查的結果出現了不一致，磁盤數量雖然一樣，但是硬件地址發生了改變。世界上就是因為出現了太多的無法解釋的現象，所以就產生了宗教忽悠那些迷茫的人們。但從小接受的唯物主義教育給了我人定勝天的信念，突破迷霧，繼續前行。
精神的力量是偉大的，回想了從小學到大學所學的思想政治課后，我就像大力水手吃了菠菜一樣，渾身充滿了力量，繼續揭密。通過管理工具(sam)，我發現硬件地址/dev/dsk/c0t3d0和/dev/dsk/c0t4d0居然變成了光卡的硬件地址。而/dev/dsk/c4t0d4和 /dev/rdsk/c4t0d4是新產生的磁盤硬件地址。迷霧逐漸消散，真相即將大白。客氣(在用戶面前要裝孫子)得詢問了那幫搬家的粗人才知道，磁盤柜太重了，搬不動，于是他們把磁盤拆下來搬，但是拆的過程中沒有對磁盤進行編號，插入磁盤柜后，順序發生變化了。磁盤陣列重啟后，當然要重新分配硬件地址了。但為什么在磁盤加載失敗的情況下，操作系統還可以正常啟動呢?這還要感謝那幫粗人沒有把服務器本地的磁盤拆下來搬運，僅僅把磁盤柜中的磁盤拆了下來了，操作系統安裝在本地磁盤，所以操作系統可以正常啟動，但是磁盤柜中的磁盤卻加載失敗。真是不幸中的萬幸啊!否則卷組恢復將不再如此簡單，欲知詳情，且聽下次分解。
真相找到了，解決問題的關鍵所在也就清楚了。重新分配VG與磁盤的關系即可。藥方有了，開始治病吧。其實治病的藥方不是關鍵，關鍵是疹療的過程。老中醫要望聞問切，而現在的醫生大筆一揮，藥方就出來了，全是抗生素，一個病人幾分鐘搞定，悲哀呀!
1、 因為該VG應用到了雙機熱備(Serviceguard)系統，因為首先要去激動該VG。
#vgchange –a n vgsybase
#vgchange –c n vgsybase
2、 備份VG映射關系/etc/lvmtab(備份很重要，以前玩游戲，打老怪前一定要備份一下，死了還可以取檔重來)
#cp /etc/lvmtab /etc/lvmtab.bak
#vgexport –v –p –s –m /tmp/vgsybase.map /dev/vgsybase //將VG映射復制到指定文件
3、 刪除原來的VG信息
# vgreduce -f vgsybase
4、 重建/etc/lvmtab
#vgscan –v
5、 激活VG
#vgchange –a y vgsybase
6、 檢查VG狀態
#vgdisplay –v vgsybase
通過結果顯示VG一切正常，去激活VG后，在另外一臺機器上進行同樣的操作，VG也啟動正常。此時再啟動雙機程序和相關的應用，一切都恢復了，數據也沒有丟。藥到病除，那顆懸著的心終于可以落地了。
作者信息：
姓名：曹志勇
職務：數據庫工程師
職稱：系統工程師
專業領域：數據庫設計、開發、調優及管理
原文鏈接：http://storage.it168.com/a2012/0106/1298/000001298826.shtml
