首页 > 数据库 >Oracle RAC数据库实例无法拉起？检查OCR与Voting Disk健康

Oracle RAC数据库实例无法拉起？检查OCR与Voting Disk健康

来源：互联网 2026-04-28 22:46:07

OCR与Voting Disk故障排查：当集群的“心脏”与“大脑”停摆时 OCR磁盘组无法挂载会导致CRS启动失败，表现为CRS-4535错误；常见原因包括ASM未启动、磁盘组未识别、路径权限异常或OCR文件头损坏，应优先检查ASM状态、磁盘发现结果及手动挂载尝试，并从备份恢复OCR而非直接dd清零

OCR与Voting Disk故障排查：当集群的“心脏”与“大脑”停摆时

OCR磁盘组无法挂载会导致CRS启动失败，表现为CRS-4535错误；常见原因包括ASM未启动、磁盘组未识别、路径权限异常或OCR文件头损坏，应优先检查ASM状态、磁盘发现结果及手动挂载尝试，并从备份恢复OCR而非直接dd清零。

OCR磁盘组无法挂载导致CRS无法启动

如果把RAC集群比作一个生命体，那么OCR（Oracle Cluster Registry）就是它的“大脑”和“配置中心”。一旦存放OCR的ASM磁盘组无法挂载，crsd.bin进程就会直接罢工退出。这时候，你运行crsctl check crs，通常会看到一种“割裂”的状态：底层服务在线（CRS-4638: Oracle High A vailability Services is online），但集群就绪服务却失联了（CRS-4535: Cannot communicate with Cluster Ready Services）。

问题根源往往集中在几个方面：ASM实例没起来、OCR所在的磁盘组ASM认不到、磁盘路径权限不对，或者最麻烦的——磁盘组里的OCR文件头本身损坏了。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

第一步，确认ASM是否在运行：执行ps -ef | grep asm_pmon看看有没有进程。如果没有，别慌，先尝试手动启动：srvctl start asm -n 。
第二步，检查ASM的“视野”：用asmcmd lsdsk -k命令，看看OCR磁盘（比如/dev/oracleasm/disks/OCR_VOTE）的状态。关键是要显示为PROVISIONED（已配置），而不是UNKNOWN（未知）。
第三步，尝试手动挂载：如果磁盘能看见，但磁盘组就是挂不上，可以登录sqlplus / as sysasm，执行ALTER DISKGROUP OCR_VOTE MOUNT。这时要特别留意是否报ORA-15032或ORA-15017错误，这通常指向磁盘路径不可达或者UDEV规则失效了。
最重要的一点：切忌病急乱投医：千万别一看到OCR可能损坏就直接用dd命令清零磁盘，这是毁灭性的操作。正确的姿势是优先从备份恢复：先用ocrconfig -showbackup找到备份文件，然后用ocrconfig -restore 进行恢复。

Voting Disk离线引发节点驱逐（Node Eviction）

Voting Disk可不是什么“可选组件”，它是RAC集群心跳仲裁的“心脏”。规则很简单：只要集群中任何一个节点无法访问多数（Quorum）的Voting Disk，这个节点就会在60秒内被强制重启，以避免“脑裂”。日志里通常会留下这样的证据：cssd(9819)ERROR: clssnmvDRLUpdate: Aborting local node to a void split-brain.。

这里有个关键认知：Voting Disk可以放在ASM磁盘组里（这也是官方推荐的做法），也可以放在裸设备或NFS上。但无论放在哪里，都必须确保所有节点对同一份Voting Disk有一致、低延迟且无中断的读写能力。

查看状态：运行crsctl query css votedisk，重点看输出结果中的STATE列，必须全部是ONLINE才行。
诊断离线：如果状态显示OFFLINEls -l 看文件是否存在，再用dd if= of=/dev/null bs=4k count=1简单测试一下I/O通路是否畅通。
注意ASM依赖：如果Voting Disk存放在ASM中，那么它的在线状态完全依赖于底层ASM磁盘组的挂载情况。如果执行crsctl query css votedisk报错CLSU-00100: Operating System function: ioctl() failed with error data: 25，十有八九是ASM没能加载到那块磁盘，或者udev绑定出了错。
操作规范：添加或替换Voting Disk，必须使用crsctl replace votedisk 这个专用命令。千万不要手动去底层复制或修改文件内容，因为Voting Disk的内容是由CSS守护进程独占管理的。

OCR/Voting Disk共存于同一ASM磁盘组的风险

Oracle确实允许把OCR和Voting Disk放在同一个ASM磁盘组里（比如常见的+OCR_VOTE）。但这就像把鸡蛋放在同一个篮子里，是一把双刃剑：部署是简化了，但也把集群的“大脑”（配置）和“心脏”（仲裁）这两个最关键的路径耦合在了一起。一旦这个唯一的磁盘组因为磁盘故障、路径抖动或者ASM本身的Bug而无法挂载，整个集群会在瞬间同时失去配置管理和节点仲裁能力，后果是灾难性的。

所以，对于生产环境，强烈建议将两者分离：OCR单独放一个磁盘组（如+OCR），Voting Disk放在另一个磁盘组（如+VOTE）。更理想的情况是，这两个磁盘组后端的物理磁盘，不要共享同一个存储控制器或光纤链路，实现真正的物理隔离。

检查是否共存：对比ocrcheck -detail命令输出中的Location，和crsctl query css votedisk命令输出的路径，看看它们是否属于同一个ASM磁盘组名。
分离操作步骤：这是一个需要停集群的操作：crsctl stop crs -f → 在各个节点分别执行ocrconfig -repair -add +VOTE（添加新位置）→ crsctl replace votedisk +VOTE（替换投票盘）→ 清理旧路径 → 最后重启集群。
特别注意：ocrconfig -repair命令仅仅修复的是OCR在集群注册表中的位置信息，它不会移动物理文件。真正的物理文件迁移，需要结合dd命令或者asmcmd cp命令（使用后者要求目标磁盘组已经存在且可写）来完成。

诊断时最容易忽略的底层细节

很多DBA排查时会卡在一个尴尬的境地：磁盘路径存在、权限也对、ASM也能识别到磁盘，但实例就是拉不起来。这时候，问题往往藏在更底层：不是配置错了，而是通路“断”了。

多路径映射陷阱：在多路径（multipath）环境下，ocrconfig -showbackup显示的路径可能是/dev/mapper/mpathb，而crsctl query css votedisk输出的却是/dev/oracleasm/disks/VOTE1。如果这两者之间没有通过udev规则正确映射，CSS进程根本就找不到真正的Voting Disk。
检查udev规则：务必确认/etc/udev/rules.d/99-oracle-asmdevices.rules这个文件里包含了对应WWID（全球唯一标识符）的绑定规则。并且在执行start_udev重新加载规则后，通过ls -l /dev/oracleasm/disks/能看到持久化的设备链接。
私网的间接影响：集群私网（Cluster Interconnect）不通，也会间接影响OCR的同步。CSS守护进程依赖UDP多播来维持集群节点视图。如果使用ping -I 测试发现丢包，或者延迟持续大于20ms，可能会触发节点的误驱逐，进而破坏OCR的一致性。
时间同步的蝴蝶效应：时间不同步虽然不会直接导致实例拉不起来，但它会让OCR备份的时间戳陷入混乱。你可能会在ocrconfig -showbackup的输出中，看到未来时间的备份文件，这会在恢复时严重误导你的判断。