從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以後的版本就不存在這個問題。
結語
是以遷移虛拟機上的資料庫要注意資料庫的一些特殊的硬碟管理方式，檢查硬碟比對才能啟動資料庫，最好做好資料庫全庫備份到其他檔案伺服器，做好重建資料庫的準備。