故障描述：
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 incorrectRecovery 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
备机卷组：statvgbackvg两机都可以访问，用于备份的
问题描述： 现在备机只要是执行和卷组，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: noBefore 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，既recreatevg3. 如果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