在Oracle RAC的安装流程中，最耗费时间的往往不是执行安装命令本身，而是失败后反复排查环境问题。cluvfy工具提供的stage检查模式，正好可以把这些隐患前置到安装动作之前。它不修改任何系统参数，只对节点、存储、网络、操作系统配置做只读验证，输出带PASS、FAIL或WARNING的检查报告。把cluvfy stage跑完整，等于为RAC集群的后续安装铺平了道路。
一、cluvfy stage的阶段划分与检查时机
cluvfy全称Cluster Verification Utility，通常位于Grid安装介质根目录下，通过./runcluvfy.sh调用。stage参数的作用是把集群部署过程拆成多个检查阶段，每个阶段对应一个即将执行的安装动作。比如在配置共享存储之前，可以跑-pre cfs；装完操作系统之后跑-post hwos；安装Grid Infrastructure之前跑-pre crsinst。这种阶段化设计让工程师不必手工拼凑一堆检查命令，而是按安装顺序逐层验证，避免遗漏。
要查看当前Grid版本支持的stage列表，可以先进入解压后的Grid目录执行：
cd /u01/app/oracle/product/grid ./runcluvfy.sh stage -list
列表中会给出类似-post hwos、-pre crsinst、-post crsinst、-pre dbinst、-pre acfs这样的阶段名称。每个阶段都有明确的检查目标：-post hwos用于验证操作系统和硬件是否满足RAC基本要求；-pre crsinst用于检查安装Grid Infrastructure之前的所有前置条件；-post crsinst用于确认集群件安装后的状态；-pre dbinst用于创建数据库前验证集群和ASM环境；-pre acfs则针对ACFS文件系统的安装前提。实际安装前，建议至少把前三个和数据库相关的阶段都跑一遍。
二、安装前关键stage检查项解析与命令示例
以最常用的-pre crsinst为例，该阶段会验证集群节点之间的用户等价性、共享存储可访问性、OCR和Voting Disk的权限与大小、网络接口一致性、NTP或chrony配置等。如果其中任一环节不达标，安装程序很可能在后续root.sh或Grid Setup阶段中断，排查起来反而更麻烦。实际执行时建议加上-verbose参数，以便定位具体失败条目。
下面是针对两个节点执行安装前集群检查的完整命令：
./runcluvfy.sh stage -pre crsinst -n racnode1,racnode2 -verbose
其中-n后面跟的是主机名列表，多个节点用英文逗号分隔，不需要空格。如果环境已经准备好响应文件，也可以通过-r指定，但前期手工执行更容易观察每一步输出。硬件操作系统阶段-post hwos则重点关注内核参数、已安装rpm包、swap与共享内存、透明大页等。命令与上面类似，只是阶段名称不同：
./runcluvfy.sh stage -post hwos -n racnode1,racnode2 -verbose
输出报告会逐项列出检查项目，例如内核参数kernel.semmsl、kernel.semmnb、net.ipv4.ip_local_port_range等，每一行后紧跟PASS或FAIL结果。这套检查项比手工执行sysctl -p或rpm -qa可靠得多，因为它会结合Oracle官方对当前版本的最低要求做判断。
三、输出报告解读与常见失败修复
cluvfy stage执行结束后，会在终端打印汇总和详细检查列表。每一行以Check开头，结果可能是PASS、FAIL或WARNING。PASS代表该项满足当前阶段要求；WARNING表示建议修复但不阻止安装；FAIL则是硬性条件，必须处理。为了便于回溯，可以把输出重定向到日志文件：./runcluvfy.sh stage -pre crsinst -n racnode1,racnode2 -verbose > /tmp/cluvfy_precrs.log，之后用grep FAIL /tmp/cluvfy_precrs.log快速定位失败项。
典型失败包括时间同步配置不一致、内核参数semmni过小、缺少cvuqdisk包、OCR磁盘权限为root等。例如出现PRVE-0032 : Path /dev/mapper/ocr1 does not have correct permissions时，需要重新设置udev规则或修改磁盘属主为grid:asmadmin。如果FAIL涉及时间同步，需配置NTP或chrony，并确保两个节点时间偏差不超过官方允许范围。处理完失败项后重新运行同一stage，直到所有硬性检查全部PASS为止。
不建议直接跳过FAIL继续安装，因为有些问题会在root.sh执行时变成难以定位的错误。cluvfy报告本身也会给出修复提示，初学者可以按照报告中的Expected和Actual值逐项比对。对于WARNING项，建议在条件允许的情况下一并修复，避免后续升级或扩容时暴露问题。
四、把多个stage串成自动化预检脚本
在真实项目中，安装前检查往往需要反复执行，手工敲命令既慢又容易遗漏。可以在一个bash脚本中按顺序运行多个stage，并把每次输出归档到带日期的日志文件。脚本大致逻辑如下：
#!/bin/bash GRID_HOME=/u01/app/oracle/product/grid NODES="racnode1,racnode2" LOG_DIR=/tmp/cluvfy_logs mkdir -p $LOG_DIR $GRID_HOME/runcluvfy.sh stage -post hwos -n $NODES -verbose > $LOG_DIR/post_hwos_$(date +%m%d_%H%M%S).log $GRID_HOME/runcluvfy.sh stage -pre crsinst -n $NODES -verbose > $LOG_DIR/pre_crsinst_$(date +%m%d_%H%M%S).log $GRID_HOME/runcluvfy.sh stage -pre dbinst -n $NODES -verbose > $LOG_DIR/pre_dbinst_$(date +%m%d_%H%M%S).log echo "所有检查完成，日志位于 $LOG_DIR"
这种脚本方式适合在用户验收测试或正式安装前作为标准交付物。还可以在脚本末尾增加简单判断，如果grep到FAIL则返回非零退出码，方便接入CI或运维平台。不过要注意cluvfy不同版本对stage名称支持略有差异，建议先跑-list确认可用阶段，再写入脚本。
cluvfy stage不是万能，它只能检查当前环境是否满足Oracle官方的最低要求，无法替代架构设计和性能测试。但把这一步骤纳入RAC安装规范后，至少可以避免因为低级配置错误导致的安装反复。真正的安装前准备，应当是从硬件规划、操作系统基线、网络配置、共享存储多路径一直到cluvfy stage全部通过，再开始动手装Grid Infrastructure。
Oracle RACcluvfy stage安装前检查修改时间：2026-09-27 03:35:52