在Oracle RAC集群搭建过程中，root.sh脚本的顺利执行往往是安装能否继续的分水岭。该脚本由root用户在Grid Infrastructure安装结束后分别在各节点上运行，负责完成OCR（Oracle Cluster Registry）初始化、Voting Disk配置、集群进程启动等底层操作。很多安装中断都发生在这个阶段，而且由于root.sh内部会调用多个底层命令，报错信息有时并不直观，需要结合日志和系统状态综合判断。理解root.sh的执行逻辑，对于快速定位问题、保证集群后续稳定运行至关重要。
一、root.sh脚本的核心职责与执行时机
root.sh位于Grid Infrastructure安装目录的根目录下，通常路径为/u01/app/19.0.0/grid/root.sh。在Oracle RAC安装流程中，当安装程序完成二进制文件复制和初始配置后，会提示以root用户在集群的每个节点上依次执行该脚本。第一个节点的执行会初始化OCR和Voting Disk，并创建集群ware相关资源；后续节点的执行则主要负责加入现有集群、配置本地集群栈并启动对应服务。因此，执行顺序不能颠倒，必须先在第一个节点完成且成功后再执行其他节点。
从内部逻辑看，root.sh会调用$ORACLE_HOME/crs/install/rootcrs.pl这个Perl脚本来完成大部分工作。该脚本会读取$ORACLE_HOME/crs/install/crsconfig_params文件中的配置参数，然后依次执行环境检查、创建必要的系统用户和组、设置文件权限、初始化OCR、配置Voting Disk、启动高可用服务等步骤。每一步都有对应的日志输出，默认记录在$ORACLE_HOME/cfgtoollogs/crsconfig/目录下，文件名通常为rootcrs_<节点名>_<时间戳>.log。在排查问题时，第一时间查看该日志文件往往能直接定位到失败的具体命令。
还有一个容易忽略的点：root.sh的执行环境需要满足一些前置条件，例如/etc/hosts文件中必须包含所有节点的公私网IP和主机名映射，节点间SSH互信必须配置正确，共享存储设备（如ASM磁盘）在所有节点上具有一致的权限和属主。如果这些条件不满足，root.sh可能在早期检查阶段就报错退出，但错误信息可能只是简单的权限拒绝，需要结合系统日志进一步判断。
二、root.sh执行步骤拆解与常见报错
以Oracle 19c为例，root.sh在第一个节点上的典型执行流程可以概括为：检查CRS_HOME环境变量、运行rootcrs.pl -prepatch类似的准备动作、配置OCR（如果使用ASM则创建磁盘组）、配置Voting Disk、启动ohasd和crsd守护进程、注册集群资源。上述任一步骤出现错误都会导致脚本终止，并输出类似Failed to create keys in OCR, rc=...或CLSRSC-xxx的报错码。下面通过几个典型阶段说明常见问题。
在OCR初始化阶段，如果使用ASM存储，root.sh会尝试在指定的ASM磁盘组上创建OCR。常见的报错是PROT-1: Failed to initialize ocrconfig或者ORA-15018: diskgroup cannot be created。这通常意味着ASM磁盘的权限不正确，例如磁盘设备的属主不是grid:asmadmin，或者/dev/oracleasm/disks/下的磁盘没有在所有节点上正确扫描。解决方法是使用ls -l /dev/oracleasm/disks/检查权限，并用oracleasm scandisks和oracleasm listdisks确认磁盘可见。
# 检查ASM磁盘权限 ls -l /dev/oracleasm/disks/ # 重新扫描ASM磁盘 oracleasm scandisks oracleasm listdisks
在Voting Disk配置阶段，如果磁盘组无法挂载，报错可能是ORA-15032: not all alterations performed或ORA-15040: diskgroup is incomplete。此时需要确认ASM实例是否已在其他节点运行，以及磁盘组的冗余级别是否与实际磁盘数量匹配。此外，网络配置错误也可能导致Voting Disk写入失败，例如私网网卡绑定不正确或/etc/hosts中缺少集群互联地址。
另一个高频错误出现在root.sh执行到Adding daemon to inittab或Start of resource "ora.asm" failed时，系统服务启动失败。这通常是因为systemd或init脚本配置问题，或者共享库路径缺失。查看$ORACLE_HOME/log/和crsd.log可以获取更详细的启动错误。
三、典型故障排查与处理方案
当root.sh执行失败后，不要盲目重新运行，否则可能导致OCR或Voting Disk信息不一致。正确的做法是先根据日志确定失败点，清理掉不完整的配置，再重新执行。例如，如果OCR初始化一半失败，需要以root用户执行$ORACLE_HOME/bin/ocrconfig -local -delete清理，同时如果创建了空的ASM磁盘组，需要先删除该磁盘组。下面列出几类常见故障及其排查思路。
故障一：权限不足导致脚本无法写入OCR设备。排查命令：ls -l /dev/mapper/查看多路径设备权限，对于使用udev绑定的裸设备，需要确保规则文件中OWNER="grid"、GROUP="asmadmin"、MODE="0660"。如果权限正确但仍然报错，尝试用dd命令测试写入是否被阻止。
# 测试写入OCR设备 dd if=/dev/zero of=/dev/mapper/ocrdisk1 bs=1M count=10 # 检查udev规则 cat /etc/udev/rules.d/99-oracle-asmdevices.rules
故障二：节点间SSH互信失效。root.sh在后续节点执行时需要与第一个节点通信，如果互信配置被破坏（如root密码更改、known_hosts问题），可能报Failed to add node to cluster。使用ssh <节点名> date测试所有节点的root和grid用户互信，必要时重新配置SSH等效性。
# 测试节点互信 ssh node2 date ssh node2-priv date
故障三：时钟不同步导致集群服务无法启动。Oracle RAC对节点间时间差异非常敏感，如果NTP或Chrony配置不当，root.sh可能报CTSS resource failed。检查chronyc sources -v或ntpq -p确认时间同步状态，并确保所有节点时间偏差在可接受范围内。
# 检查时间同步 chronyc sources -v # 或 ntpq -p
处理完故障后，可以重新运行root.sh，但需要确保之前的失败残留已经清理，且最好是在干净的状态下执行。如果多次失败，建议查看Oracle官方支持文档或社区，根据具体的CLSRSC-错误码查找对应解决方案。
四、root.sh执行后的验证与后续操作
当所有节点的root.sh都成功执行后，集群ware的基本框架就搭建完成了，但还需要做一系列验证才能确认集群真正可用。首先，以grid用户运行crsctl stat res -t查看所有集群资源的状态，正常情况下应该看到ora.asm、ora.cluster_interconnect.haip、ora.crsd等资源均为ONLINE状态。如果有资源处于OFFLINE或INTERMEDIATE，需要进一步检查对应日志。
# 查看集群资源状态 crsctl stat res -t # 检查集群ware版本 crsctl query crs softwareversion
其次，运行cluvfy comp crs -n all -verbose进行集群健康检查，该工具会验证节点可达性、共享存储一致性、网络配置等多项内容。如果检查发现警告或失败项，应逐项解决后再继续安装数据库软件。此外，还可以使用crsctl check cluster -all快速查看所有节点的集群栈是否运行正常。
# 验证集群完整性 cluvfy comp crs -n all -verbose # 快速检查集群状态 crsctl check cluster -all
最后，在确认集群ware稳定后，可以开始安装Oracle数据库软件并创建RAC数据库。需要注意的是，数据库的ASM磁盘组需要提前创建好，并且要满足OCR和Voting Disk之外的空间需求。如果后续需要添加节点或调整存储，必须重新运行root.sh或使用addNode.sh等工具，同样要遵循严格的顺序和验证流程。
总之，root.sh脚本虽然只是安装过程中的一个环节，但其成功与否直接决定了RAC集群的可用性。通过理解它的执行逻辑、学会阅读日志、掌握常见故障的排查方法，可以大幅减少安装过程中的反复尝试，提高部署效率。
Oracle RACroot.sh集群安装修改时间：2026-09-22 05:54:02