故障描述：
4.20日早晨，发现日报没有正常发送，登录数据库备机查看原因，查看系统的log命令：
errpt |more
没有发现什么异常，不过发现有如下错误：
F3931284 0410055009 I H ent2 ETHERNET NETWORK RECOVERY MODE
F3931284 0410055009 I H ent0 ETHERNET NETWORK RECOVERY MODE
173C787F 0410053709 I S topsvcs Possible malfunction on local adapter
173C787F 0410053709 I S topsvcs Possible malfunction on local adapter
EC0BCCD4 0410053709 T H ent2 ETHERNET DOWN
EC0BCCD4 0410053709 T H ent0 ETHERNET DOWN
这个时间正好是同事更换以太网交换机的时间
查看数据库同步脚本log：
# sh /home/oracle/sh/rmanres.sh
[YOU HAVE NEW MAIL]
0516-040 lqueryvg: Unable to read the specified physical volume
descriptor area.
0516-932 /usr/sbin/syncvg: Unable to synchronize volume group backvg.
[YOU HAVE NEW MAIL]
restoring datafile 00058 to /u01/oracle/product/9.2.0/oradata/orcl/yy33.dbf
restoring datafile 00059 to /u01/oracle/product/9.2.0/oradata/orcl/yy34.dbf
released channel: ch1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/20/2009 12:06:25
ORA-19501: read error on file "/u03/orabackup/rman/orcl_db_684391660_523_1", blockno 8192001 (blocksize=8192)
ORA-27063: skgfospo: number of bytes read/written is incorrect
IBM AIX RISC System/6000 Error: 12: Not enough space
Additional information: -1
Additional information: 1048576
ORA-19501: read error on file "/u03/orabackup/rman/orcl_db_684391660_523_1", blockno 8191873 (blocksize=8192)
ORA-27063: skgfospo: number of bytes read/written is incorrect
Recovery Manager complete.
[YOU HAVE NEW MAIL]
SQL*Plus: Release 9.2.0.1.0 - Production on Mon Apr 20 12:06:26 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SP2-0640: Not connected
SP2-0640: Not connected
ERROR:
ORA-12500: TNS:listener failed to start a dedicated server process
SP2-0640: Not connected
SP2-0640: Not connected
系统日志：
# ps -ef |more
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Dec 16 - 0:55 /etc/init
root 61572 78170 0 Dec 16 - 359:56 dtgreet
root 69798 1 0 Dec 16 - 0:00 /usr/lib/errdemon
root 73882 1 0 Dec 16 - 71:56 /usr/sbin/syncd 60
root 90242 1 0 Dec 16 - 0:00 /usr/dt/bin/dtlogin -daemon
root 102438 344388 0 13:18:46 pts/7 0:00 -ksh
root 118898 102438 0 13:19:03 pts/7 0:00 ps -ef
root 127086 1 0 Dec 16 - 0:00 /usr/ccs/bin/shlap64
root 143514 106918 0 Dec 16 - 0:00 /usr/sbin/rsct/bin/IBM.ERrmd
root 155816 106918 0 Dec 16 - 2:24 /usr/sbin/rsct/bin/IBM.CSMAgentRMd
root 159976 106918 0 Dec 16 - 3:08 /usr/sbin/rsct/bin/rmcd -a IBM.LPCommands -r
root 164070 352610 0 Dec 16 - 37:11 /usr/sbin/rsct/bin/hats_nim
daemon 168160 106918 0 Dec 16 - 0:00 /usr/sbin/rpc.statd -d 0 -t 50
oracle 180262 1 0 Dec 16 - 0:02 ora_reco_rmandb
root 184400 106918 0 Dec 16 - 1:01 /usr/sbin/gsclvmd
oracle 205000 1 0 11:26:43 - 0:00 ora_pmon_orcl
root 233570 106918 0 Dec 16 - 7:56 /usr/sbin/rsct/bin/IBM.HostRMd
oracle 237696 1 0 12:29:22 - 0:00 oracleorcl (LOCAL=NO)
root 241712 352610 0 Dec 16 - 50:29 /usr/sbin/rsct/bin/hats_rs232_nim
root 245830 106918 0 Dec 16 - 0:00 /usr/sbin/muxatmd
root 278610 352610 0 Dec 16 - 30:31 /usr/sbin/rsct/bin/hats_nim
oracle 307362 1 0 Dec 16 - 0:06 ora_d000_rmandb
root 315394 106918 0 Dec 16 - 0:10 /usr/sbin/aixmibd
root 352384 106918 0 Dec 16 - 0:05 /usr/sbin/snmpmibd
root 372834 1 0 12:13:02 - 0:00 lsvg -o
oracle 389264 1 0 11:26:43 - 0:00 ora_ckpt_orcl
root 393248 1 0 12:11:24 - 0:00 lsvg -o
root 397368 1 0 12:21:43 - 0:00 lsvg -o
root 405556 1 0 12:15:51 - 0:00 lspv
root 417854 450810 0 12:06:28 - 0:00 lqueryvg -g 00c64e4b00004c000000011dbddadf95 -CX
root 426226 1 0 12:47:15 - 0:00 lsvg statvg
oracle 434210 1 0 12:07:13 - 0:00 oracleorcl (LOCAL=NO)
oracle 442388 1 0 11:26:43 - 0:00 ora_lgwr_orcl
oracle 446680 1 0 11:26:43 - 0:00 ora_dbw0_orcl
root 450810 1 0 12:06:28 - 0:00 /usr/bin/ksh /usr/sbin/varyoffvg backvg
root 61802 90242 0 Dec 16 - 8:20 /usr/lpp/X11/bin/X -D /usr/lib/X11//rgb -T -force :0 -auth /var/dt/A:0-ozyiia
root 74076 106918 0 Dec 16 - 1:34 /usr/sbin/snmpd
root 78170 90242 0 Dec 16 - 0:00 dtlogin <:0> -daemon
root 86416 106918 0 Dec 16 - 0:02 /usr/sbin/syslogd
root 94582 106918 0 Dec 16 - 0:00 /usr/sbin/inetd
root 98768 106918 0 Dec 16 - 13:14 /usr/es/sbin/cluster/clcomd -d
root 106918 1 0 Dec 16 - 0:00 /usr/sbin/srcmstr
root 115134 106918 0 Dec 16 - 0:00 /usr/sbin/portmap
root 119210 1 0 Dec 16 - 0:22 /usr/sbin/cron
root 131516 1 0 Dec 16 - 0:00 /usr/sbin/uprintfd
root 139680 1 0 Dec 16 lft0 0:00 /usr/sbin/getty /dev/console
root 143754 102438 0 13:19:03 pts/7 0:00 more
root 151986 106918 0 Dec 16 - 0:00 /usr/sbin/rsct/bin/IBM.ServiceRMd
root 156076 106918 0 Dec 16 - 0:00 /usr/sbin/rsct/bin/IBM.AuditRMd
oracle 168230 1 0 11:26:43 - 0:00 ora_d000_orcl
oracle 172368 1 0 11:26:43 - 0:00 ora_arc0_orcl
oracle 287158 1 0 11:26:43 - 0:00 ora_smon_orcl
oracle 299364 1 0 11:26:43 - 0:00 ora_reco_orcl
root 319924 1 0 11:51:24 - 0:00 lspv hdisk5
root 332234 106918 0 Dec 16 - 5:53 hagsd grpsvcs
oracle 336330 1 0 Dec 16 - 5:07 ora_dbw0_rmandb
root 344388 94582 0 13:18:45 - 0:00 telnetd -a
root 352610 106918 0 Dec 16 - 55:44 /usr/sbin/rsct/bin/hatsd -n 1 -o deadManSwitch
oracle 356856 1 0 Dec 16 - 11:53 ora_ckpt_rmandb
oracle 360852 1 0 Dec 16 - 5:24 ora_smon_rmandb
root 369086 106918 0 Dec 16 - 51:38 /usr/es/sbin/cluster/clstrmgr
root 389556 106918 0 Dec 16 - 11:02 /usr/es/sbin/cluster/clinfo
oracle 393484 1 0 Dec 16 - 4:17 ora_pmon_rmandb
oracle 418112 1 0 Dec 16 - 0:04 /home/oracle/product/9.2.0/bin/tnslsnr LISTENER -inherit
root 422200 106918 0 Dec 16 - 0:08 haemd HACMP 1 Cluster SECNOSUPPORT
root 438682 106918 0 Dec 16 - 0:05 /usr/sbin/qdaemon
root 442776 106918 0 Dec 16 - 0:00 /usr/sbin/rpc.lockd -d 0
root 446934 106918 0 Dec 16 - 0:00 /usr/sbin/writesrv
root 451032 106918 0 Dec 16 - 0:00 /usr/sbin/biod 6
root 471540 106918 0 Dec 16 - 0:21 sendmail: accepting connections
oracle 479602 1 0 Dec 16 - 1:33 ora_lgwr_rmandb
root 491900 106918 0 Dec 16 - 0:05 /usr/sbin/hostmibd
oracle 495908 1 0 11:26:43 - 0:00 ora_arc1_orcl
环境： 两台小机，一个存储阵列， 两台机器是hacmp的
有三个卷组，dbvg, statvg, backvg
主机卷组 dbvg
备机卷组：statvg
backvg两机都可以访问，用于备份的
问题描述： 现在备机只要是执行和卷组，pv相关的命令 就挂在那 ，没有反应
我通过进程信息，可以判断是卷组锁定了backvg，
我执行过的操作，再备机上： chvg -u backvg ， 已经3个小时了， 还是没有结果，挂载那
然后又在备机上执行 exportvg backvg 又很长时间了，一个多小时，还是挂在那，
请问如何解决这个问题，解锁backvg，我在主机varyonvg backvg时 ，提示：
# varyonvg backvg
0516-013 varyonvg: The volume group cannot be varied on because
there are no good copies of the descriptor area.
Command: failed stdout: yes stderr: no
Before command completion, additional instructions may appear below.
0516-024 lqueryvg: Unable to open physical volume.
Either PV was not configured or could not be opened. Run
diagnostics.
0516-024 lqueryvg: Unable to open physical volume.
Either PV was not configured or could not be opened. Run
diagnostics.
0516-1140 importvg: Unable to read the volume group descriptor area
on specified physical volume.
问题产生的原因：因为backvg卷组是共享卷组(不是并发卷组),在每日的04:00-05:40这段时间
是数据库用backvg备份,而在每次使用卷组的时候都要更改卷组的vgda,vgsa中的
时间戳,而在这段时间里同事更换了交换机,导致两个小机的卷组的VGDA不一致
从而会出现这个错误
解决方法：
首要目的:让备机释放掉对pv,卷组的管理进程,以达到我可以从新管理备机的卷组信息
由于一些原因,我强行kill掉相关LVM命令,导致这些进程都被系统接管,根本无法再kill掉,
即使用kill -9,也是不可以
我当时在想有两个方法可以解决此种情况
1.有一些特殊的方法可以kill掉这些进程
2.重新启动机器让其释放所有资源
咨询了很多人,又google半天,也没有找到可以kill那些进程的方法
最后决定重启机器
因为我的环境是两台小机做了hacmp,为了避免出万一,决定23号凌晨去机房维护,出什么问题也好就近解决
主要是担心网卡down了,远程连接不上
当到了机房,就在外边的维护室(机房太冷了!!能不进去就不进去啊),
我的hacmp配置为有优先级的cascading模式，按优先级来接管资源。优先级高的节点恢复后将回拉资源
而我现在打算reboot备机,所以不会影响主机(我咨询过经验丰富的IBM工程师,在此感谢)
操作步骤:
备机:
执行如下命令:
# reboot
然后就等,按经验,也就5分钟左右,结果等啊等啊,等了20几分钟还没有起来,心想幸好来机房了,进机房连上显示器
没有反映,观察硬件也没有什么错误,于是按重启键,等了一会,系统起来了,简单看看了,发现backvg卷组没问题,可以
varyon,lspv,lslv都没什么问题,不过主机不能varyon这个卷组了，我又发现statvg卷组有问题
当执行lsvg -l statvg ,有问号，但是这个卷组varyon后，mount上的文件系统，用着也没有问题，为了避免隐患，我还是
简单修正下，
这个原因一般是因为ODM库中的VGDA和PV上的VGDA不一致，只要简单的exportvg来解决就可以
exportvg statvg
importvg -y statvg hdisk6 或者 smit importvg
执行后问题解决！！
第二个问题就是把backvg卷组让主机也可以访问
在主机上
清空主机上ODM库中的backvg信息
#exportvg backvg
然后执行
在备机
# ls -l /dev/backvg
crw-rw---- 1 root system 53, 0 Nov 24 22:58 /dev/backvg
在主机
#smit importvg
[Entry Fields]
VOLUME GROUP name [backvg]
* PHYSICAL VOLUME name [hdisk6] ---backvg里的任何一个 +
Volume Group MAJOR NUMBER [53] 这个53相当于卷组的唯一标识；要没有他，两边机器就不能保证访问相同的卷组backvg这个 +#
结果ok！！
最后重新启动下hacmp软件
#smit clstart
两边看看errpt看是否有错，都没有，于是对主库做一次全备
这次故障是有惊无险，解决的还是蛮顺利的
其实为这次我准备了好几套备用方案
1.重新启动系统，如可以能识别最好---结果真识别了
2. 如果不能varyon，那就强制varyon
#varyonvg -f backvg
如果可以varyon，那最好，如果不行，那就恢复backvg，既recreatevg
3. 如果recreatevg还不能解决，那只有删除了重新创建backvg，当然里面的数据也就没了
#smit mkvg
#smit mklv
#smit mkjfs
注意
pvid存在三个地方
ODM库中
# lspv
hdisk0 00c64e4bd07d52a8 rootvg active
hdisk1 00c64e4bd0e61501 rootvg active
hdisk2 00c64e4bbdd3e449 dbvg
hdisk3 00c64e4bbdd3e75f dbvg
hdisk4 00c64e4bbdd91029 statvg active
hdisk5 00c64e4bbdd91370 statvg active
hdisk6 00c64e4bbddabdb3 backvg
hdisk7 00c64e4bbddac0e8 backvg
#
存在VGDA中
# lqueryvg -Atp hdisk6
Max LVs: 256
PP Size: 27
Free PPs: 5
LV count: 2
PV count: 2
Total VGDAs: 3
Conc Allowed: 0
MAX PPs per PV 32768
MAX PVs: 1024
Quorum Setting 1
Auto Varyon ?: 0
Conc Autovaryo 0
Varied on Conc 0
Logical: 00c64e4b00004c000000011dbddadf95.1 loglv02 1
00c64e4b00004c000000011dbddadf95.2 fslv07 1
Physical: 00c64e4bbddabdb3 2 0
00c64e4bbddac0e8 1 0
Total PPs: 2206
LTG size: 128
HOT SPARE: 0
AUTO SYNC: 0
VG PERMISSION: 0
SNAPSHOT VG: 0
IS_PRIMARY VG: 0
PSNFSTPP: 7168
VARYON MODE: 0
VG Type: 2
Max PPs: 32768
存在pv头
# lquerypv -H /dev/hdisk6
00c64e4bbddabdb30000000000000000
本文转自glying 51CTO博客，原文链接：http://blog.51cto.com/liying/967668，如需转载请自行联系原作者
