Oracle RAC如何执行集群健康检查？运行cluvfy脚本验证

cluvfy.sh 能检查什么，不能检查什么

首先需要明确：cluvfy.sh 是 Oracle 官方提供的集群验证工具，但其本质是一个“静态环境”检查器，而非实时监控系统。它的核心价值在于，在执行关键操作（如 Oracle RAC 安装、升级、添加节点）之前，对系统环境进行一次全面的“合规性快照”。这份快照能够验证 OCR、表决磁盘的配置路径是否正确，网络设置（包括私网、公网、SCAN）是否符合规范，以及时间同步、用户权限、内核参数等基础配置是否满足当前 Oracle 版本的官方要求。

然而，该工具也存在明确的局限性。对于集群运行时的动态状态，cluvfy.sh 无能为力。例如，它无法检测 crsd 进程是否已僵死但未崩溃，无法验证 ASM 磁盘组在高负载下的实际可写性，也无法发现因网络瞬时中断导致的节点“静默”脱离（这类问题需依赖 crsctl check cluster -all 或 olsnodes -n 等实时命令进行判断）。

一个常见的误解是将其作为日常“健康检查”工具反复运行。实际上，它最适合在打补丁前、升级前或扩容节点后等“关键变更前”执行一次。请重点关注输出结果中的 Verification Summary 部分，其中的 PASS、FAIL 和 WARNING 状态是决策的核心依据。

运行 cluvfy.sh 的最小必要参数组合

直接运行 ./cluvfy.sh 通常会报错或仅显示帮助文档。要使其正常工作，必须携带合适的参数。以下几组命令组合，基本覆盖了最核心的检查场景：

• ./cluvfy.sh comp nodecon -n all -verbose：这是验证所有节点间网络连通性的“全集”检查，涵盖私网、公网、SCAN 名称解析及 UDP 端口连通性。
• ./cluvfy.sh stage -pre crsinst -n all -verbose：模拟安装集群就绪服务（CRS）前的全量预检查，从磁盘空间、用户权限到操作系统配置，进行彻底验证。
• ./cluvfy.sh comp peer -refnode rac01 -n “rac01 rac02” -verbose：此命令非常实用，它以 rac01 节点为参考基准，比对 rac01 和 rac02 节点的环境一致性，如内核参数、ulimit 设置、grid 用户目录权限等，确保集群环境标准化。

重要提示：使用 -n all 参数时，要求集群所有节点均在线且已配置 SSH 互信免密登录。若某个节点宕机，cluvfy 将跳过对该节点的检查并报告 Node is not reachable 信息——这并非脚本执行失败，而是符合预期的正常行为，其余检查仍会继续。

常见 FAIL 和 WARNING 的真实含义与处理

cluvfy 的输出中常出现大量 WARNING，但无需过度紧张，许多警告并不阻碍安装进程。例如：

• WARNING: NTP time synchronization is not configured：此警告表示未检测到标准 NTP 服务配置。但若你已使用 chronyd 或通过 ntpd -q 完成时间同步，且所有节点间时间差在可接受范围内（通常要求小于1秒），则可安全忽略。
• FAIL: Package ‘cvuqdisk’ is missing：此项失败为“硬性阻碍”，必须解决。缺少 cvuqdisk 包将导致 OCR 无法正常读写。在 RHEL 或 CentOS 系统上，运行 yum install cvuqdisk-*.rpm 安装即可，该 RPM 包位于 Grid 安装介质的 /rpm 目录下。
• FAIL: User “grid” is not a member of group “asmadmin”：这表明 grid 用户的组权限不完整。需执行 usermod -a -G asmadmin,asmdba,asmoper grid 命令将其加入必要的管理组。

真正需要高度警惕并立即处理的，是涉及核心组件的 FAIL 项。例如：OCR 或表决磁盘的配置路径无法访问、ASM 磁盘的兼容性属性不一致（如一个磁盘设为 COMPATIBLE.ASM=‘12.1.0’，另一个为 ‘19.0.0’），或私网网卡的 MTU 值不统一导致集群心跳 UDP 包被丢弃。此类问题若不解决，后续的安装或运行必然会出现严重故障。

高效查看 cluvfy 输出日志的技巧

默认情况下，cluvfy 的结果会滚动输出至终端，但最详尽的信息隐藏在其自动生成的 HTML 报告中。每次运行后，注意查看当前目录下生成的 cvu_*.html 文件（例如 cvu_2024-04-15_10-22-33.html）。用浏览器打开该文件，并逐一点击每个检查项旁的 Details 链接，即可查看背后具体执行的命令及其返回值。

对于追求效率的运维人员，更高效的方法是：通过 -o 参数将文本日志重定向至文件，再利用 grep 快速提取关键信息。

./cluvfy.sh stage -pre crsinst -n all -verbose -o /tmp/cluvfy.log
grep -E “(FAIL|WARNING|Verification Summary)” /tmp/cluvfy.log

请记住，无需逐行阅读数千行的完整日志——cluvfy 的设计初衷是帮助运维快速定位标红（FAIL）和标黄（WARNING）的问题项，而非理解每条检查背后复杂的 Shell 命令逻辑。

最后，必须再次强调：cluvfy.sh 检查全部通过，仅代表“在检查时刻，系统环境满足了 Oracle 官方认可的安装最低要求”，并不等同于集群未来高枕无忧、永远稳定。真实生产环境中的许多故障，源于资源突发争用、存储后端延迟骤增，或心跳包因交换机 ACL 策略被意外限速——这些动态的、深层次的隐患，恰恰是 cluvfy.sh 无法探测的盲区。