没有无缘无故的爱，也没有无缘无故恨，设备故障的产生也总会伴随着一系列的爱恨情愁。事情的经过是这样的。联通用户为了节流，要将以前不怎么使用的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也启动正常。此时再启动双机程序和相关的应用，一切都恢复了，数据也没有丢。药到病除，那颗悬着的心终于可以落地了。
