ORACHK是Oracle官方推出的自动化健康检查脚本，早期版本叫RACCheck，后来更名为ORACHK。它并不局限于RAC集群，单实例数据库、ASM、Grid Infrastructure、Exadata一体机、甚至主机层面的内核参数和网络配置都可以被纳入检查范围。工具会读取操作系统文件、数据库动态性能视图和集群注册信息，把超过数百个检查项的结果汇总为一份带风险分级的HTML报告。相比靠人手动执行SQL和shell命令巡检，ORACHK能减少遗漏，也便于历史对比。
一、ORACHK的定位与检查范围
ORACHK主要解决一个问题：当数据库集群出现性能抖动、节点驱逐或者配置漂移时，DBA很难在短时间内确认所有相关组件是否都处于健康状态。它把检查项分成系统类、存储类、数据库类、集群类和网络类，例如内核参数shmmax、vm.min_free_kbytes、ASM磁盘组权限、OCR备份状态、数据库DB_FILES参数预估值、RAC服务的漂移策略等。检查完成后，报告会根据严重程度标记为FAIL、WARNING、INFO和PASS。
它的意义不是替代DBA判断，而是把最容易忽略的底层风险先暴露出来。比如某个节点的ntpd服务没有启用，或者集群时钟不同步，在平时可能完全无感，一旦发生脑裂就会放大成严重故障。ORACHK会把这类问题以清单形式列在报告头部，并给出对应MOS文档编号或修复建议。
另外，ORACHK对版本和补丁非常敏感。通过读取opatch lsinventory结果，它能发现某些关键补丁缺失、PSU与GI版本不匹配等问题。相比只关注SQL性能的AWR报告，ORACHK偏向配置与合规性，因此更适合作为季度巡检和变更后的验证工具。
二、运行前准备与权限说明
ORACHK脚本通常随Grid Infrastructure安装，默认路径为$GRID_HOME/suptools/orachk/orachk。如果环境中没有安装GI，也可以从Oracle Support下载独立压缩包解压使用。运行账号建议使用root或拥有oracle、grid权限的用户，因为脚本需要读取/etc/sysctl.conf、/etc/security/limits.conf等OS文件，还要访问OCR和ASM磁盘。只读权限通常足够，但若想让ORACHK自动修复某些项，需要更高权限。
第一次运行前先查看帮助，确认版本和默认输出目录。
$GRID_HOME/suptools/orachk/orachk -h
输出会列出可选profile、执行范围、是否上传结果等参数。许多DBA习惯直接运行不带任何选项的命令，让工具自行识别环境。但生产环境建议显式指定-profile和-outdir，避免报告写进当前目录或由脚本决定复杂目录结构。
如果遇到权限报错，可以先切换到grid用户执行，或者用sudo赋予临时权限。需要注意的是，ORACHK运行时间会随检查项和节点数增加，小型单实例可能几分钟，大型RAC或Exadata可能需要20到40分钟，建议避开业务高峰。
三、常用参数与执行示例
基础巡检命令如下，-outdir用于指定输出目录，-profile可以限定检查类别。如果不确定支持哪些profile，可以执行-profile list查看。
$GRID_HOME/suptools/orachk/orachk -profile all -outdir /tmp/orachk_report
-profile可选值包括preinstall、cluster、database、asm、exadata等，不同版本的名称可能略有差异。对日常巡检来说，all虽然慢但覆盖最全，是首选。若只想检查单实例数据库，可以写成-profile database，脚本会跳过集群项。
在RAC环境中，如果要在某个节点本地执行并收集单个节点信息，可以加-local参数。默认情况下ORACHK会尝试通过SSH连接到集群所有节点进行分布式收集，没有配置SSH互信时经常卡住或漏项，这时-local非常有用。
$GRID_HOME/suptools/orachk/orachk -local -profile database -outdir /tmp/orachk_single
另一个实用参数是-syslog，它会把检查摘要写入系统日志，方便和监控平台联动。还有-diff参数可以比较两次报告之间的变化，如果每周固定产出报告，通过差异比对能快速看到新出现的WARNING或FAIL项。
四、输出报告与结果解读
运行结束后，输出目录会生成HTML报告、文本摘要和压缩包。直接打开index.html或orachk_*.html文件，顶部会显示总体健康状态、总检查项、FAIL数量、WARNING数量和INFO数量。常见做法是先只看FAIL和WARNING，再按类别逐条过滤。
cd /tmp/orachk_report grep -E "FAIL|WARNING" orachk_summary.txt
文本摘要中的每个FAIL项都会附带ID、描述和建议。有些FAIL项其实与业务无关，例如未配置邮件告警、未开启审计等，应根据公司规范判断是否需要处理；而涉及内核参数、磁盘组冗余度、OCR备份过期、数据库闪回空间不足的FAIL，通常需要立即安排整改。
报告最容易被误读的是WARNING级别。WARNING不代表可以忽略，它往往是当前环境仍能运行，但偏离了Oracle推荐值。例如临时表空间自动增长关闭、密码过期策略过严、redo日志大小过低等。建议将WARNING项纳入季度整改清单，持续降低风险。
此外，HTML报告支持点击每个标题展开详情，能看到实际值与期望值的对比。如果怀疑工具误报，可以查看详情中的Actual Value和Recommended Value，并结合MOS文档编号进一步确认。
五、定时巡检与配置基线
手工执行ORACHK只适合按需排查，更难能可贵的是把它做成定时任务。可以用crontab设置每月一次全量检查，输出到固定目录，再通过邮件系统发送报告摘要。
0 2 1 * * /u01/app/11.2.0/grid/suptools/orachk/orachk -profile all -outdir /orachk/$(date +\%Y\%m)
通过-diff参数可以在报告中标记出与上一次基线之间的变化。建立基线时先人工确认所有FAIL和WARNING都有合理解释，然后保存该报告作为基准。后续每次巡检只需要关注新增的FAIL、从INFO变为WARNING的项，以及基线中已整改项是否关闭。
ORACHK还支持自定义检查规则，这对有特殊运维规范的企业非常有价值。工具使用XML格式的规则文件，允许DBA增加主机目录大小、特定服务状态、表空间使用率等检查项。虽然自定义规则有一定学习成本，但一旦配置好，巡检就不再依赖个别老员工的记忆清单，新同事也能快速接手。
总体来看，ORACHK适合作为Oracle环境的常态化健康检查手段。它的价值不仅在于发现问题，更在于把零散的人工经验沉淀成可重复执行的检查基线。生产环境建议从月度全量检查开始，逐步结合-diff和自定义规则形成自己的巡检体系。