cluvfy.sh 能检查OCR、Vote Disk、网络配置、时间同步、用户权限、内核参数等是否符合Oracle安装/升级前提条件；不能检测crsd进程状态、ASM磁盘组可写性或节点静默脱离集群。
cluvfy.sh 能检查什么，不能检查什么
cluvfy.sh 是 oracle 提供的集群验证工具，不是实时监控程序，它只做快照式静态检查。它能确认 ocr、vote disk、网络配置、时间同步、用户权限、内核参数等是否符合当前 oracle 版本的安装/升级前提条件；但它不会检测正在运行的 crsd 进程是否卡死、asm 磁盘组是否实际可写、或者某个节点是否已静默脱离集群（需靠 crsctl check cluster -all 或 olsnodes -n 辅助判断）。
常见误用是把它当“健康看板”反复执行——其实它更适合在打补丁前、升级前、加节点后这类关键操作前运行一次，输出 Verification Summary 中的 PASS/FAIL/WARNING 才是重点。
运行 cluvfy.sh 的最小必要参数组合
不带参数直接执行 ./cluvfy.sh 会报错或只显示帮助。最常用且覆盖核心项的是：
-
./cluvfy.sh comp nodecon -n all -verbose：验证所有节点间网络连通性（包括私网、公网、扫描名解析、UDP 端口连通） -
./cluvfy.sh stage -pre crsinst -n all -verbose：模拟安装 CRS 前的全量检查（含磁盘、权限、OS 配置） -
./cluvfy.sh comp peer -refnode rac01 -n "rac01 rac02" -verbose：以rac01为基准，比对两个节点的环境一致性（如内核参数、ulimit、grid 用户家目录权限）
注意：-n all 要求所有节点都在线且 SSH 免密通；若某节点宕机，cluvfy 会跳过并报 Node is not reachable，但其余检查仍继续——这不是脚本失败，而是预期行为。
常见 FAIL 和 WARNING 的真实含义
cluvfy 输出里大量 WARNING 并不意味着不能继续安装，比如：
-
WARNING: NTP time synchronization is not configured：如果已用chronyd或手动ntpd -q同步过时间，且date在所有节点误差 -
FAIL: Package 'cvuqdisk' is missing：必须安装，否则 OCR 无法读写；RHEL/CentOS 上运行yum install cvuqdisk-*.rpm（包在 grid 安装介质/rpm目录下） -
FAIL: User "grid" is not a member of group "asmadmin"：说明 grid 用户组权限不完整，需补加：usermod -a -G asmadmin,asmdba,asmoper grid
真正要警惕的是涉及 OCR/Vote Disk 路径不可访问、磁盘 ASM 兼容性不一致（如一个盘是 COMPATIBLE.ASM='12.1.0'，另一个是 '19.0.0'）、或私网 MTU 不一致导致 UDP 包被丢弃这类 FAIL。
cluvfy 输出日志怎么看才不浪费时间
默认输出滚动在终端，但关键信息藏在 HTML 报告里。每次运行后，它会在当前目录生成 cvu_*.html 文件（如 cvu_2024-04-15_10-22-33.html），用浏览器打开后点开每个组件的 Details 才能看到具体命令和返回值。
更高效的方式是加 -o /tmp/cluvfy.log 参数把文本日志定向出来，然后 grep 关键字：
./cluvfy.sh stage -pre crsinst -n all -verbose -o /tmp/cluvfy.log grep -E "(FAIL|WARNING|Verification Summary)" /tmp/cluvfy.log
别试图从头读完几千行日志——cluvfy 的设计就是让运维快速定位红字项，而不是理解每条检查背后的 shell 命令逻辑。
最后提醒一句：cluvfy.sh 检查通过 ≠ 集群当前稳定。它只担保“此刻环境满足 Oracle 认可的安装门槛”，而真实故障往往发生在资源争用、存储延迟突增、或心跳包因交换机 ACL 被限速这些它根本没能力探测的地方。
