问题的出现：
服务器是2台Sun F280R，磁盘阵列是3310，VCS。3310有5块磁盘，1个做hot spare，另外4个两两mirror做成2个LUN。2个LUN在系统中分别生成2个vmdisk。2个DG，dbdg和appdg。每个DG只有一个vmdisk。
一次故障的发生，VCS无法使dbdg正常切换，检查发现是dbdg无法import。
server2# vxdisk -o alldgs list
DEVICE TYPE DISK GROUP STATUS
c1t0d0s2 sliced rootdisk rootdg online
c3t1d0s2 sliced - (dbdg) online
c3t1d1s2 sliced appdg01 appdg online
server2# vxdg import dbdg
vxvm:vxdg: ERROR: Disk group dbdg: import failed: Disk group has no valid configuration copies
server2#
dbdg上的数据无法访问了。
解决问题的思路：
经过查看资料得知，这种错误是由于DG的配置信息被破坏所造成的。DG的configuration信息是存放在磁盘的Private Region中的，在Solaris中该分区通常是s3分区。
用命令prtvtoc可以看到，Tag＝15的分区就是vmdisk的Private Region，通常就1个柱面，但其中存放了DG的所有信息，包括组成该DG的设备vmdisk，还有plex、subdisk以及volume等的划分。如果DG中有2个以上的vmdisk，则DG的配置信息会有多个
备份在其他盘上。
现在，dbdg中只有1个vmdisk，该配置信息没有备份，只有想办法修复Private Region中受到损坏的数据，才有可能恢复Public Region的数据。
另一个促使我想修复Private Region的原因是因为dbdg中只有一个volume，而这一个volume就是一个文件系统，故相对来说dbdg中关于vmdisk、plex、subdisk和volume的配置信息应该简单些。否则就只有重新做dbdg了，因为事前咨询过专家，这种Disk group has no valid configuration copies的错误基本是没有希望修复了。
解决的办法：
先看看Private Region能否访问。
server2# /etc/vx/diag.d/vxprivutil scan /dev/rdsk/c3t1d0s3
diskid: 1061270136.1186.server1
group: name=dbdg id=1061270137.1189.server1
flags: private noautoimport
hostid:
version: 2.2
iosize: 512
public: slice=4 offset=0 len=70596608
private: slice=3 offset=1 len=3839
update: time: 1066899655 seqno: 0.308
headers: 0 248
configs: count=1 len=2808
logs: count=1 len=425
这里列出了该vmdisk的部分信息，说明其Private Region没有完全被破坏。
再用list选项看看该Private Region的信息。
server2# /etc/vx/diag.d/vxprivutil list /dev/rdsk/c3t1d0s3
diskid: 1061270136.1186.server1
group: name=dbdg id=1061270137.1189.server1
flags: private noautoimport
hostid:
version: 2.2
iosize: 512
public: slice=4 offset=0 len=70596608
private: slice=3 offset=1 len=3839
update: time: 1066899655 seqno: 0.308
headers: 0 248
configs: count=1 len=2808
logs: count=1 len=425
tocblks: 0
tocs: 2/3837
Defined regions:
config priv 000017-000247[000231]: copy=01 offset=000000 enabled
config priv 000249-002825[002577]: copy=01 offset=000231 enabled
log priv 002826-003250[000425]: copy=01 offset=000000 enabled
将Private Region的配置信息dump出来。
server2# /etc/vx/diag.d/vxprivutil dumpconfig /dev/rdsk/c3t1d0s3 > /disk1.out
vxvm:vxconfigdump: ERROR: Error (File block 3): Format error in configuration copy
这里出现错误提示是正常的，因为这个命令是对好的Private Region做dump，现在的Private Region有问题，该命令访问这个坏的Private Region时，肯定会发现格式不对了。
文件disk1.out的内容：
#Config copy 01
#Header nblocks=11232 blksize=128 hdrsize=512
#flags=0x400 (CHANGE)
#version: 4/9
#dgname: dbdg dgid: 1061270137.1189.server1
#config: tid=0.1235 nrvg=0 nrlink=0 nvol=1 nplex=1 nsd=1 ndm=1 nda=0
#pending: tid=0.1236 nrvg=0 nrlink=0 nvol=1 nplex=1 nsd=1 ndm=1 nda=0
#
#Block 5: flag=0 ref=49 offset=0 frag_size=67
#Block 6: flag=0 ref=55 offset=0 frag_size=64
#Block 8: flag=0 ref=57 offset=0 frag_size=94
#Block 11: flag=0 ref=58 offset=0 frag_size=69
#Block 13: flag=0 ref=55 offset=0 frag_size=112
#
#Record 49: type=0xf015 flags=0 gen_flags=0x4 size=67
#Blocks: 5
dg dbdg
comment="
putil0="
putil1="
putil2="
dgid=1061270137.1181.server1
rid=0.1025
update_tid=0.1027
nconfig=default
nlog=default
base_minor=13000
version=90
#Record 55: type=0x3014 flags=0x1 gen_flags=0x1c size=64
#Blocks: 6
dm dbdg01
comment="
putil0="
putil1="
putil2="
diskid=1061270136.1186.server1
last_da_name=c3t0d0s2
rid=0.1026
removed=off
spare=off
failing=off
update_tid=0.1234
last_da_dev=32/424
#Record 57: type=0x100111 flags=0 gen_flags=0x4 size=94
#Blocks: 8
vol oracle
use_type=fsgen
fstype="
comment="
putil0="
putil1="
putil2="
state="ACTIVE
writeback=on
writecopy=off
specify_writecopy=off
pl_num=1
start_opts="
read_pol=SELECT
minor=13000
user=oracle
group=dba
mode=0600
log_type=REGION
len=70570000
qq=328449803
log_len=0
update_tid=0.1235
rid=0.1050
detach_tid=0.0
active=off
forceminor=off
badlog=off
recover_checkpoint=0
sd_num=0
sdnum=0
kdetach=off
storage=off
layered=off
apprecover=off
recover_seqno=0
recov_id=0
primary_datavol=
guid={aeca2b56-1dd1-11b2-8b12-0003ba3392ca}
#Record 58: type=0x4012 flags=0 gen_flags=0x4 size=69
#Blocks: 11
plex oracle-01
comment="
putil0="
putil1="
putil2="
layout=CONCAT
sd_num=1
state="ACTIVE
log_sd=
update_tid=0.1235
rid=0.1052
vol_rid=0.1050
detach_tid=0.0
log=off
noerror=off
kdetach=off
stale=off
ncolumn=0
raidlog=off
guid={aeca4e4c-15d1-11b2-8312-0003b23392ca}
再用同样的命令对系统中的另外一个vmdisk（属于appdg）dump其Private Region信息。
在进行比较后发现少了以下一段：
#Record 43: type=0x13 flags=0 gen_flags=0x4 size=57
#Blocks: 12
sd appdg01-01
comment="
putil0="
putil1="
putil2="
dm_offset=0
pl_offset=0
len=70572032
update_tid=0.1039
rid=0.1038
plex_rid=0.1036
dm_rid=0.1026
minor=0
detach_tid=0.0
column=0
mkdevice=off
subvolume=off
stale=off
kdetach=off
relocate=off
看来手工增加一段，说不定有希望恢复数据。
仔细研究上面sd这一段，其中的dm_rid、plex_rid都与其相关的dm、plex的rid一致，update_tid总是比rid在最后一位上多1。
由于appdg中，也只有一个volume，再查看appdg的Private Region中dump出来的dg、dm、vol和plex信息段中的rid与sd段中rid的关系，可以尝试确定dbdg中sd段的rid值和update_tid的值。
在disk1.out文件中添加并编辑：
#Record 43: type=0x13 flags=0 gen_flags=0x4 size=57
#Blocks: 12
sd dbdg01-01
comment="
putil0="
putil1="
putil2="
dm_offset=0
pl_offset=0
len=70572032
update_tid=0.1055
rid=0.1054
plex_rid=0.1052
dm_rid=0.1026
minor=0
detach_tid=0.0
column=0
mkdevice=off
subvolume=off
stale=off
kdetach=off
relocate=off
使用命令检查并生成新的文件：
server2# cat disk1.out | vxprint -D - -ht
server2# cat disk1.out | vxprint -D - -mpvsh > config.out
重新初始化磁盘，将磁盘做成vmdisk：
server2# vxdisk -f init c3t1d0
因为c3t1d0原来就是标准的vmdisk格式，即slice 3是Private Region，slice 4是Public Region，该命令只是将c3t1d0重新初始化成vmdisk，slice 4中的数据不会受到影响。
重新生成dbdg，将c3t1d0加入dbdg：
server2# vxdg init dbdg dbdg01=c3t1d0s2
恢复dbdg的配置信息：
server2# vxmake -g dbdg -d config.out
用vxmake生成的volume，需要init：
server2# vxvol -g dbdg init clean oracle oracle-01
<vol> <plex>
有希望了，看看volume能不能启动：
server2# vxvol -g dbdg start oracle
接下来，成败在此一举了：
server2# fsck /dev/vx/rdsk/dbdg/oracle
心跳加速，应该成了：
server2# mount -o logging /dev/vx/dsk/dbdg/oracle /oracle
天啦，数据居然被我恢复了。立马启动VCS，hagrp -switch，再来一次switch，爽啊！我想许多绝境中重生的人都会有这种感觉吧。
[
Last edited by saveas on 2005-4-11 at 17:14 ]
