root.sh不是重启命令，而是仅用于全新安装、deconfig后重建、OCR损坏恢复或跨版本升级重配的首次配置脚本；重复执行会触发CRS-4402等冲突，真正重启须用crsctl stop crs -f与crsctl start crs分步操作。
root.sh 不是重启命令，而是首次配置或重配脚本
很多人误以为 root.sh 是用来“重启集群”的，其实它只在安装、升级、或彻底重配 crs 时运行。一旦集群已正常运行，再执行 root.sh 不仅不会重启，反而大概率触发冲突（比如报 crs-4402 或 crs-2674），因为脚本会尝试重新初始化 ocr、启动 cssd、覆盖 init 脚本等——这些操作在已有活跃集群时是危险且不兼容的。
真正用于重启的，是 crsctl 命令族，配合节点状态判断和资源依赖顺序。
-
root.sh只应在以下情况运行：全新安装、deconfig后重建、OCR 损坏后手动恢复、或跨版本升级后强制重配 - 日常运维中重复运行
root.sh，等同于强行“拔电源再插电”，不是重启，是破坏性重装 - 11.2.0.4 及以后版本虽支持 checkpoint 续跑（如
ckptgridha_${nodename}.xml），但那仅限于安装中断后的恢复，不适用于运行中的集群
优雅重启必须分步停启，不能直接 reboot 或 kill -9
Oracle RAC 集群不是单体服务，CSSD、CRSD、EVM、GIPCD 之间有强依赖。粗暴停止（如 kill -9 所有 d.bin 进程）会导致 OCR 锁残留、ASM 磁盘挂起、甚至节点驱逐（eviction）。正确做法是让 CRS 自己按依赖链有序关闭。
- 先确认当前状态：
crsctl check crs和crsctl stat res -t - 逐节点停 CRS：
crsctl stop crs -f（-f是必须的，否则可能卡在等待资源释放） - 停完所有节点后，再逐节点启 CRS：
crsctl start crs（不要加-f） - 启动后检查：
crsctl stat res -t看所有ora.*资源是否 ONLINE，特别是ora.cssd、ora.diskmon、ora.asm
注意：crsctl stop crs -f 会终止所有集群资源，包括数据库实例（如果用 srvctl 管理），所以务必提前通知应用停业务，或确保数据库已用 srvctl stop database 手动停掉。
重启前必须验证磁盘与网络连通性
很多重启失败不是命令问题，而是底层支撑条件已失效。尤其是 OCR/Voting Disk 所在 ASM 磁盘组无法 mount，或 GIPCD 无法建立私网通信，会导致 ora.cssd 死循环重试、ora.crsd 启动超时。
- 检查 ASM 磁盘可见性：
$GRID_HOME/bin/kfod disks=asm st=true ds=true cluster=true - 确认 Voting Disk 状态：
crsctl query css votedisk输出应显示 ACTIVE 状态磁盘路径 - 验证私网连通（尤其多网卡环境）：
ping -I <private_if><other_node_private_ip></other_node_private_ip></private_if>，避免走错路由 - 检查 OCR 完整性：
ocrcheck返回状态必须是successful；若失败，先用ocrconfig -restore恢复最近备份
这些检查项漏掉任意一个，crsctl start crs 就可能卡在 ora.cssdmonitor 或反复报 CRS-2679 清理失败。
11.2.0.4 下特别注意 systemd 兼容问题
Red Hat 7.4+ 默认用 systemd，但 Oracle 11.2.0.4 的 root.sh 仍按 SysV init 方式写入 /etc/inittab 和 /etc/init.d/ohasd，这会导致 crsctl start crs 实际调用失败，表现为 ora.cssd 启动后立即退出、日志里反复出现 OHASD failed to start。
- 必须手动补 systemd service 文件：
/usr/lib/systemd/system/ohas.service，内容需包含Type=simple和正确ExecStart - 启用并启动：
systemctl daemon-reload && systemctl enable ohas.service && systemctl start ohas.service - 验证：
systemctl status ohas.service应为 active (running)，且ps -ef | grep ohasd能看到进程 - 之后再运行
crsctl start crs，CRS 才能真正接管资源
这个点非常隐蔽：看起来 crsctl 命令都执行成功了，但后台 ohasd 根本没起来，整个集群实际处于“假启动”状态——所有资源都是 offline，且无法手工拉起。
