克隆Oracle服务器后启动不了，绝大多数情况下是网卡MAC地址与udev规则绑定冲突导致系统卡在启动阶段，其次是主机名、UUID或/etc/fstab配置残留问题，按本文顺序排查可恢复启动。
为什么克隆后系统会突然“罢工”
克隆Oracle服务器和物理机迁移不一样，它本质上是把一套完整的系统复制到另一套硬件环境里，你想象一下，原服务器的网卡、磁盘、主机名、唯一标识符全都被刻在系统里，克隆过来的副本里这些“身份信息”还是旧的,新硬件自然不认账。
行业共识认为，克隆后无法启动的故障里，网卡配置冲突占到了多数情况，磁盘UUID异常其次，这不是Oracle数据库本身的问题，而是底层Linux操作系统层面的“水土不服”。
很多DBA第一反应是去查Oracle告警日志，但实际上你根本进不到那个阶段，因为操作系统自己都起不来，搞清楚这一点,排查方向就对了。
克隆后启动卡住的典型故障现象
不同环境下，故障表现不完全一样，先对号入座,看看你属于哪种情况：
- 现象一：开机后卡在类似
Starting udev或Waiting for network configuration的界面，超过几分钟没反应 - 现象二：系统提示
ata: softreset failed或磁盘设备找不到了，然后进入紧急模式 - 现象三：网络服务启动超时，最终进入
emergency mode，提示输入root密码 - 现象四：开机能起来，但Oracle监听起不来，
crsctl status resource显示数据库资源全处于UNKNOWN状态
其中现象一和现象三最为常见，核心元凶基本就是udev规则文件里残留旧网卡信息。
克隆虚拟机后Linux无法启动的排查路径
有人上来就重装系统，那是最粗暴的办法，实际操作中，你只需要在启动时进入救援模式,花几分钟就能定位问题。
通过grub进入救援模式
重启服务器，在grub菜单出现时快速按e键进入编辑界面，找到以linux16或linux开头的那一行,行尾追加：
rd.break enforcing=0
然后按Ctrl+x启动，系统会进入一个switch_root命令行环境,这时执行：
mount -o remount,rw /sysroot chroot /sysroot
你就获得了完整系统的root权限,可以开始定位问题了。
第一步：检查udev网卡规则文件
这是排查的重中之重,执行：
cat /etc/udev/rules.d/70-persistent-net.rules
你会看到类似这样的内容：
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="00:0c:29:ab:cd:ef", ATTR{type}=="1", KERNEL=="eth0", NAME="eth0"
关键问题就在这里，克隆后的新网卡MAC地址通常和旧的不一样，但规则文件里还是旧MAC，udev在启动时拿着新MAC去匹配规则，找不到对应的eth0名称,系统的网络初始化就卡住了。
解决办法有两条思路，一个是在原有规则基础上替换新MAC，另一个是直接删掉这个文件让系统自动重新生成网卡名称，更合理的做法是，先确认你在另一个终端里查到的本机新MAC是从哪来的其实你只要进入这个救援模式，执行ip addr就能看到新网卡的MAC地址,然后直接把规则文件里的旧MAC替换成新的就行。
再说直白一点，如果你用的是eth0这种传统命名方式且只有一个网卡，删除整个70-persistent-net.rules文件然后重启，系统会自动生成一份新的规则，也不会有问题，但如果你有多个网卡或有绑定关系,手动替换MAC更稳妥。
第二步：核对fstab里的UUID
继续在chroot环境下执行：
blkid
查看根分区、数据分区的UUID，然后比对/etc/fstab里的记录是否一致，克隆时如果用了不同的分区大小或文件系统格式，UUID会发生改变，fstab里还写着旧的UUID，启动时系统就挂载不上根分区,直接掉进紧急模式。
不一致的话，用blkid查到的正确UUID更新/etc/fstab，注意数据盘和备份盘也要一并检查,遗漏任何一个都可能让后面的Oracle服务起不来。
第三步：清理网络配置里的旧主机名
Oracle对主机名非常敏感，特别是RAC环境，/etc/hosts里的名字解析错了会出各种怪问题,克隆后需要检查：
/etc/hosts里面的主机名映射/etc/sysconfig/network里的HOSTNAME字段/etc/hostname（不同发行版路径不同）
保证这三处统一，否则Oracle的crsct1或sqlplus在解析本地实例名时会出现延迟或报错。
重启进入系统后的验证动作
修复完上述配置后，正常重启系统，这一步不要急着启动数据库,先确认底层环境干净：
- 确认网络服务状态，
systemctl status network
ip addr能看到正确的IP地址 - 检查
/var/log/messages里没有持续刷新的udev或network错误 - 确认
/etc/fstab里所有分区都已成功挂载，执行df -h核实 - 查看
dmesg | grep -i error，确认没有IO错误
全部通过，再切到oracle用户启动数据库监听和实例。
不同虚拟化平台下的克隆差异
很多人问“为什么我在VMware里克隆没事，换到KVM就卡住了”，这里面的机制确实有区别,对排查思路也有影响。
VMware Workstation的克隆工具会主动调用guest OS customization机制，自动重置网卡配置和机器ID，所以比较省心，但手动复制虚拟机目录或导出OVF再导入的话，绕过了一键部署流程,还是会触发同样的问题。
KVM环境用virt-clone命令克隆时，默认会生成新的MAC地址，但不会主动修改客户机内部的udev规则文件,所以KVM下克隆Oracle服务器后启动不了的情况更常见。
物理机之间做整盘dd或使用备份恢复工具，也会遇到一模一样的现象，原理相通，处理方式也一样，差别只在于物理环境里你可能更难进入救援模式,备好启动光盘或PXE引导更稳妥。
Oracle RAC节点克隆的特殊之处
如果是Oracle RAC的某个节点克隆自另一个节点，启动问题的复杂程度还要再上一个台阶，除了前面提到的Linux系统层面的问题之外,还需要额外注意：
| 检查项 | 原因 | 验证方法 |
|---|---|---|
| ASM磁盘的磁盘组名称 | 克隆节点的ASM盘可能读到旧节点的盘符 | crsctl status res -t确认ASM实例在线 |
| 私有网卡和心跳IP | RAC依赖私网通信，IP冲突或网卡名变化会让集群脑裂 | ifconfig -a对比公私网IP，ping对端节点私网IP |
| ohasd和crsd的配置 | 克隆节点的集群注册信息可能还是旧节点的 | crsctl check crs查看集群状态，报错则crsctl delete node后重新添加 |
这里有个容易忽略的点，集群节点的/etc/oracle/olr.loc文件里记录着本机的node name，如果旧节点名和新节点对不上，crsd进程起不来，数据库资源就一直是OFFLINE状态，表面看像是没启动,实际上是被集群层拦住了。
对于这种情况，单纯的Linux系统修复还不够，需要重跑一次root.sh脚本重新注册集群资源，多数情况下，重跑脚本就万事大吉，复杂环境（比如有第三方集群件）则需要逐层验证。
如何判断Oracle服务是否真的恢复正常
修复完系统启动问题后,按这个顺序验证数据库状态：
- 执行
lsnrctl status确认监听已启动，能看到实例状态 - 执行
crsctl stat res -t查看所有资源是否处于ONLINE状态 - 执行
sqlplus / as sysdba后执行select status from v$instance;确认实例是OPEN状态 - 查看
alert_<sid>.log日志尾部，确认没有ORA-错误在重复出现
多节点RAC环境可以把上面的步骤在所有节点上各执行一遍，部分节点有问题时，单独重启对应节点的高可用服务通常能解决，crsctl stop has和crsctl start has是这套场景里利用率最高的两条命令，先把这两条命令能解决的那一类问题排除,再去看日志定位更深层的异常。
常见问题速答
问：克隆Oracle服务器进入紧急模式，怎么知道是fstab还是udev的问题？
观察启动日志，卡在udev或网络相关的阶段，优先排查udev网卡规则，报错直接指向文件系统或超时挂载，优先查/etc/fstab，进入救援模式后执行journalctl -b -p err查看本次启动的内核错误,能快速定位故障源。
问：克隆后开机网卡名从eth0变成了ens33或eno16777736，数据库起不来？
这是Linux的biosdevname或systemd的可预测命名规则根据新硬件信息重命名了网卡，导致Oracle的监听配置里绑定的IP或网卡失效，把新网卡改回eth0不推荐，更合适的做法是修改/etc/sysconfig/network-scripts/ifcfg-配置，让网卡获取你预期的IP地址，再同步修改Oracle监听文件和/etc/hosts即可。
问：KVM克隆的Oracle节点，网络通了但crsctl检查集群显示offline？
核心思路是把节点从集群里先摘出去再重新加回来，分别执行crsctl stop crs停掉该节点的集群服务，然后清理该节点在ocm文件里的旧注册信息，再执行crsctl start crs，如果集群里本来就没多少已配置的资源，直接把两个节点都重启一次，让crsd重新握手，多数情况下就能恢复ONLINE，最常见的诱因是节点2的/etc/oracle/olr.loc里的nodename写的是节点1的名字,逐行核对这个文件能省去很多弯路。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e4%b8%ba%e4%bb%80%e4%b9%88%e5%85%8b%e9%9a%86oracle%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%90%8e%e5%90%af%e5%8a%a8%e4%b8%8d%e4%ba%86%ef%bc%8c%e6%80%8e%e4%b9%88%e8%a7%a3%e5%86%b3%ef%bc%9f/
