ocrconfig -check 命令不存在，正确校验命令是 ocrcheck；需在各节点执行 ocrcheck 比对 id 是否一致，并检查日志确认 ocr 完整性与同步状态。
ocr内容不一致时，ocrconfig -check 不是验证手段，它根本不存在 —— 这个命令会报错，且无法用于完整性校验。
执行 ocrconfig -check 报错：命令未识别
Oracle 11g RAC 中没有 ocrconfig -check 这个子命令。实际可用的 OCR 校验命令只有 ocrcheck，任何尝试运行 ocrconfig -check 的操作都会返回类似以下错误：
PROT-1: Failed to initialize ocrconfig PROT-2: Cannot find OCR configuration file or ocrconfig: invalid option -- 'c'
这是最常被误记的“伪命令”之一，源于把 ocrcheck 和 ocrconfig 混用。记住：ocrconfig 只管配置变更（备份、恢复、添加/删除 OCR 设备），ocrcheck 才负责健康检查。
真正有效的 OCR 完整性验证：用 ocrcheck + 日志交叉比对
ocrcheck 是唯一内置的 OCR 一致性校验工具，但它默认只检查本地节点缓存与 OCR 设备的物理读写通路，不主动比对多节点间 OCR 内容是否一致。要确认“不一致”，需结合以下操作：
- 在每个节点分别执行
ocrcheck，观察输出中的ID字段是否完全相同 —— ID 不同即表明 OCR 内容已分裂 - 检查各节点日志中
ocrcheck_*.log时间戳和校验结果是否同步（路径如$ORA_CRS_HOME/log/<hostname>/client/ocrcheck_*.log</hostname>） - 若某节点显示
Device/File integrity check failed或Cluster registry integrity check failed，说明该节点无法正确解析 OCR 结构，极可能已与其他节点不同步 - 强制刷新本地 OCR 缓存后重试：
crsctl stop crs && crsctl start crs（仅限维护窗口），再跑ocrcheck—— 若重启后 ID 仍不一致，基本可判定 OCR 物理损坏或镜像不同步
OCR 内容不一致的典型诱因和修复前提
OCR 不一致往往不是孤立事件，而是其他操作引发的连锁反应。修复前必须确认以下几点：
- 所有节点的集群服务必须完全停止（
crsctl stop cluster -all），否则ocrconfig -restore或-import会触发ORA-29702错误并导致更严重的状态撕裂 - 确认你有**可用的、时间点正确的 OCR 自动备份**（位于
$ORA_CRS_HOME/cdata/<cluster_name></cluster_name>）；手动导出的ocrdump文件不能用于物理恢复，仅作诊断参考 - 裸设备环境下，各节点
/etc/oracle/ocr.loc中的ocrconfig_loc路径必须指向同一块共享存储设备（例如都为/dev/raw/raw1），设备名不一致会导致节点各自读写不同物理位置 - ASM 存储 OCR 时，确保 ASM 磁盘组处于
MOUNTED状态且无DISK_REPAIR_TIME超时导致的磁盘离线 —— 否则 OCR 镜像可能长期未同步
OCR 不一致的本质是集群失去了单一事实来源。它不像数据库表能靠日志回滚，一旦多个节点长期运行在不同 OCR 快照下，资源注册、VIP 分配、实例启动顺序都会错乱。所以验证阶段发现 ID 差异，就该立刻停机，别试图“在线修复”。
