从Vmware迁移数据库虚拟机到其他平台，起来后认不到asm盘，不禁傻眼了。

很多时候为了保证虚拟机系统的完整可启动，在做任何变更前，领导都会要求克隆一份镜像保存，或者直接在镜像上操作。这是传统的备份理念。

但如果用在带裸设备的oracle数据库虚拟机，就会发现数据库启动失败。

从oracle11g开始数据库的asm就可以直接管理裸硬盘，但需要通过udev将硬盘名称改为asm盘符，并授权给grid和asmadm

scsi_id无法识别的问题

在udev的规则配置里，会使用scsi_id来识别硬盘，一旦克隆后scsi_id就会改变，所以无法产生asm盘符，也没法改变dev权限，grid的asm服务就会启动失败。

所以克隆后的数据库虚机需要重新查询硬盘的scsi_id，修改
udev/rules.d/99-oracle-asmdevice.rules文件。

KERNEL="sd*",SUBSYSTEM="block",PROGRAM="/sbin/scsi_id --whitelisted --replace-whiespace --device=/dev/$name",RESULT="[scsi_id号]",NAME="asm-disckb",OWNER="grid",GROUP="asmdba",MODE="0660"

然后重启udev使配置生效

rhel6用start_udev

或用udevadm control --reload-rules

裸设备无法识别的问题

早期也有一些数据库是使用raw盘来存储数据，通过把逻辑卷lv或整个硬盘定义为raw文件，再把raw文件通过软连接映射为数据文件，用于存储oracle数据库的各个表空间。当数据库克隆后，有可能raw盘顺序会改变。

通过查询lsblk /dev/datavg/rootlv可以获得MAJ:MIN值

要严格按照MAJ:MIN值对比
/etc/udev/rules.d/60-raw.rules ，确认MAJ:MIN都一致，才能启动数据库。

crs无法启动的问题

Oracle数据库crs无法启动的情况：

可以执行

/bin/dd if=/var/tmp/.oracle/npohasd of=/dev/null bs=1024 count=1

这是早期oracle11g的一个bug，如果是12c以后的版本就不存在这个问题。

结语

所以迁移虚拟机上的数据库要注意数据库的一些特殊的硬盘管理方式，检查硬盘匹配才能启动数据库，最好做好数据库全库备份到其他文件服务器，做好重建数据库的准备。