数据库 Database
Oracle DB2 MySQL
RAC备份软件异机恢复ASM实例无法启动
虚拟机异机恢复RAC环境ASM磁盘uuid变化导致ASM instance 不能启动
备份软件异机恢复RAC节点的虚拟机或者在使用Storage vMotion迁移包含Oracle RAC ASM磁盘的虚拟机后，发现ASM实例无法启动，GI无法找到所有的ASM磁盘。
由于ASM磁盘在操作系统中是通过udev规则将物理磁盘映射为asm磁盘名称的，于是对比scsi_id命令列出的物理磁盘的uuid值与udev规则中为ASM磁盘定义的uuid，发现物理磁盘的uuid全部发生了变化。
由于uuid值发生了变化，udev规则也就失效了，从而无法生成ASM的磁盘名称，最终导致ASM实例无法启动。
如果在Storage vMotion之前在其它机器上存在该虚拟机的克隆备份，于是查看备份中每个虚拟磁盘的vmdk配置文件diskname.vmdk（不是-flat.vmdk），使用ddb.uuid行对应的uuid值更新到新存储上的虚拟磁盘的uuid值，然后关闭再启动虚拟机，磁盘的uuid值得到了恢复，udev规则正常生效，ASM实例也可以正常启动。
cd "/vmfs/volumes/vsanDatastore/vSAN rac1"
vi "vSAN rac1_9.vmdk"
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=36ef308c
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 4194304 VMFS "vSAN rac1_9-flat.vmdk"
# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.deletable = "true"
ddb.geometry.cylinders = "261"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "17045667976304831c2f05d436ef308c"
ddb.toolsInstallType = "4"
ddb.toolsVersion = "10282"
ddb.uuid = "60 00 C2 91 00 30 5d bd-84 ac 06 e2 05 dc 84 d4"
ddb.virtualHWVersion = "11"
为了避免Storage vMotion后uuid发生变化产生不可预知的问题，最好在关闭虚拟机后，更改虚拟机的vmx配置文件 ，加入以下行，让虚拟机保持uuid不变，然后启动虚拟机。
uuid.action = “keep”
同时，在进行Storage vMotion变更操作之前，建议备份好虚拟机的vmx和每个虚拟磁盘的vmx文件内容，在出问题时，可以利用备份来恢复相关信息。
如果没有备份可以用来恢复磁盘的uuid，只能使用相关的应用工具读取物理磁盘的相关信息来确认对应关系，比如在Oracle中，使用kfed来读取ASM磁盘头的信息找出对应的ASM磁盘名称，然后使用新的UUID值重新定义udev规则来映射ASM磁盘名称。
用 kfed工具直接读取 ASM 磁盘头部，来确定 新的磁盘 UUID与 ASM 磁盘组成员的对应关系，这样就能知道哪些物理盘属于哪个 ASM 磁盘组。
[root@rac1 ~]# export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome
[root@rac1 ~]# kfed read /dev/sdb
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 2147483648 ; 0x008: disk=0
…
kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8
…
kfdhdb.compat: 186647040 ; 0x020: 0x0b200200
kfdhdb.dsknum: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: RECO01 ; 0x028: length=6
kfdhdb.grpname: RECO ; 0x048: length=4
kfdhdb.fgname: RECO01 ; 0x068: length=6
执行 kfed read 后，会输出很多字段，最关键的是以下几个：
| 字段 | 含义 |
|---|---|
| kfbh.dskname | ASM 磁盘的名称（例如 DATA_0001） |
| kfbh.grpname | ASM 磁盘所属的磁盘组名（例如 DATA、FRA） |
| kfbh.fgname | Failgroup 名称 |
| kfbh.dsknum | ASM 磁盘在磁盘组中的编号 |
| kfbh.creatid | 磁盘创建时的时间戳/标识 |
| kfdhdb.dskname | 与 kfbh.dskname 类似，也是磁盘头部存的名称 |
| kfdhdb.grpname | 所属 ASM 磁盘组 |
| kfdhdb.ausize | ASM Allocation Unit 大小 |
| kfdhdb.f1b1locn | Failgroup 位置信息 |
| kfdhdb.f1b1tag | Disk header tag（常见为 DATAFILE） |
实际操作步骤
- 以 root 或 grid 用户（要有读权限）对每个设备跑一次：
- /u01/app/19.0.0/grid/bin/kfed read /dev/sdX | egrep "dskname|grpname|dsknum"
- 对比所有盘的输出，整理出一个映射表：
- 根据这个表，就能知道 新磁盘的 OS 设备名（或者新 UUID）对应 ASM 磁盘组的哪一个成员。
示例输出：
kfdhdb.dskname: DATA_0001
kfdhdb.grpname: DATA
kfdhdb.dsknum: 1
/dev/sdb → ASM 磁盘 DATA_0001 → 属于磁盘组 DATA
/dev/sdc → ASM 磁盘 DATA_0002 → 属于磁盘组 DATA
/dev/sdd → ASM 磁盘 FRA_0001 → 属于磁盘组 FRA
...
然后可以用这些 UUID 去更新 udev 规则，恢复正确的 /dev/asm-* 符号链接。
补充：kfed dump 更多字段
如果需要更完整的信息，可以用：
kfed read /dev/sdX | less
其中：
- kfdhdb.hdrsts → MEMBER 表示磁盘在磁盘组中有效
- kfdhdb.chksum → 校验和
- kfdhdb.failg → failgroup 名称
结论
通过 kfed 读取每块盘的头部，就能确定它属于哪个 ASM 磁盘组和哪个成员。整理出对应关系表后，就能根据新的磁盘 UUID，重建正确的 udev 规则，使 GI/ASM 恢复正常识别磁盘。
