在Oracle RAC集群的安装过程中，安装界面走到最后一步时会提示用户以root身份执行两个脚本：orainstRoot.sh和root.sh。不少初次接触RAC的DBA会直接照着提示一路执行，一旦中间报错就手足无措，不知道脚本到底做了什么、失败后能不能重跑。理解这两个脚本的内部逻辑，是排障的关键前提。本文将从脚本作用、执行顺序、报错处理三个层面展开说明。
一、orainstRoot.sh脚本做了哪些事情
orainstRoot.sh是在GRID软件安装阶段最先被要求执行的脚本，它的位置在GRID的inventory目录下，通常是/u01/app/oraInventory/orainstRoot.sh。这个脚本的职责相对单一，核心工作就是创建Oracle Inventory（中央清单）目录并调整其属主和权限。
具体来说，脚本会创建/u01/app/oraInventory目录（如果路径由环境变量决定，则创建对应路径），将属主设置为grid用户和oinstall组，权限设置为775。同时它会修改/etc/oraInst.loc文件，该文件记录了inventory位置和inst_group信息，Oracle安装程序后续所有操作都会依赖这个文件定位清单目录。可以理解为，orainstRoot.sh是搭建安装基础设施的一步。
需要特别注意的是，在RAC环境中这个脚本只需要在第一个节点执行，其余节点如果该目录是共享的则不需要重复执行；但实际生产环境里inventory目录通常不共享，所以每个节点都要各自执行一次，这一点在OUI的执行提示里会明确列出所有节点。执行完毕后回车继续，安装程序会校验清单目录是否可用。
二、root.sh脚本的核心职责与执行顺序
root.sh是整个RAC安装流程中最关键也最容易出错的脚本，它在GRID安装阶段的末尾执行，位于$GRID_HOME/root.sh。脚本内容非常庞大，主要完成以下几件事：配置并启动集群件栈（包括ohasd、crsd、cssd、evmd等守护进程）、初始化OCR和Voting Disk、配置集群网络资源（如SCAN、VIP、监听）、创建并注册ASM实例相关服务、修改系统级配置文件（如/etc/inittab或systemd单元，取决于Oracle版本）、设置目录权限等。
执行顺序上有严格要求：必须先执行orainstRoot.sh，再执行root.sh；在多个节点之间，必须先在第一个节点完整执行成功root.sh并确认集群件正常后，才能在第二个节点执行。如果两个节点同时执行root.sh，或者第二个节点抢先执行，会出现OCR锁定冲突，导致其中一个节点配置失败，典型表现就是卡在某一步长时间无响应。
到了DATABASE软件安装阶段，同样会有root.sh提示，位于$ORACLE_HOME/root.sh。这个脚本的工作量比GRID阶段的小得多，主要是设置Oracle可执行文件的属主权限、更新/etc/oratab文件、创建OCM（Oracle Configuration Manager）相关目录等，不会改动集群件配置。它的执行没有严格的节点先后顺序要求，但仍需逐个节点执行。
执行GRID阶段的root.sh时，脚本会实时输出日志，详细日志位于$GRID_HOME/cfgtoollogs/rootout.log以及各组件对应的日志文件中。遇到报错时第一时间查看这些日志，比盯着屏幕输出有用得多。
三、常见报错与排查处理
最常见的报错之一是INS-20802，即Oracle Net Configuration Assistant辅助程序失败，这通常发生在root.sh执行后集群验证阶段。多数情况是SCAN名称解析问题：/etc/hosts中SCAN只配了一个IP，或者DNS解析异常。解决办法是保证hosts中SCAN至少配置三个IP（11g以后推荐DNS轮询或GNS），修正后重新执行root.sh即可。
第二个高频问题是root.sh执行到一半失败需要重跑。正确的做法是先做清理：11g环境可以在root下执行$GRID_HOME/crs/install/rootcrs.pl -deconfig -force回退配置，然后在失败的节点上直接重新执行root.sh。12c以后脚本改为$GRID_HOME/crs/install/rootcrs.sh -deconfig -force或使用roothas.sh（单机重启集群场景）。千万不要不做清理直接重跑，残留的OCR配置会导致第二次执行必然失败。
第三个问题是ohasd启动失败或CRS-4535提示无法通信。这类问题多与系统参数有关，比如配置了无效的内核参数、swap不足、或者grid用户的shell limit没有按照官方文档设置。此外在较新的Linux系统上（如使用systemd的版本），老版本Oracle的root.sh仍会尝试写inittab，可能不会生效，需要手工创建ohasd服务文件。排查时可以先执行crsctl check crs确认各守护进程状态，再结合$GRID_HOME/log/节点名/alert节点名.log中的告警日志定位。
还有一种情况是从单机环境转换为RAC，或者root.sh执行时检测到机器上已有旧集群配置，脚本会提示输入CRS配置信息。如果确认旧环境已废弃，按提示清理后再执行；如果误操作，可能导致原有OCR被覆盖。生产环境执行前务必确认/etc/oracle/目录下的OCR配置指向，必要时做好OCR备份。
四、执行脚本前的检查建议
为了避免脚本执行中途失败，建议在跑root.sh之前完成几项检查：确认所有节点的grid和oracle用户的等价性（ssh互信）配置正确；确认/etc/hosts中公有IP、VIP、SCAN、私网IP的规划没有冲突，SCAN不要与公有IP同名；确认ASM磁盘的udev规则或多路径配置生效，磁盘权限属于grid:asmadmin；确认节点时间和NTP同步正常，时间偏差过大是Voting Disk脑裂的隐患。
另外建议在root.sh执行期间不要中断，即使看起来长时间停在Configure Oracle Grid Infrastructure for a Cluster这一步。正常情况下这一步可能持续十多分钟，期间会启动集群件并做OCR初始化，贸然Ctrl+C中断后再处理会麻烦很多。执行完成后用crsctl stat res -t确认所有资源状态为ONLINE，再进行数据库软件的安装，整个流程才算稳妥。
总结来说，orainstRoot.sh负责清单目录的基础权限配置，root.sh承担集群件的完整搭建，两者职责分明、顺序固定。掌握了脚本背后的逻辑和失败后的清理重跑方法，RAC安装过程中这一环节的问题基本都能自行解决。
Oracle RACorainstRoot.shroot.sh修改时间：2026-09-06 20:28:41