为何 Oracle RAC节点频繁出现Disk Heartbeat Timeout？

根本原因是OCR/Voting Disk所在ASM磁盘组或裸设备的I/O响应延迟超过Oracle默认200ms容忍阈值，导致cssd进程读取heartbeat block超时，进而触发节点驱逐。

Oracle RAC Disk Heartbeat Timeout 的根本原因是什么？

这不是网络或心跳进程本身出了问题，而是 ocr/voting disk 所在的 asm 磁盘组（或裸设备）响应延迟超出了 oracle 的容忍阈值（默认 200ms）。只要 cssd 进程在规定时间内没从 voting disk 读到有效 heartbeat block，就会触发 disk heartbeat timeout，继而可能引发节点驱逐。

常见诱因包括：

• ASM 磁盘组底层存储 I/O 延迟突增（如 SAN 队列堆积、LUN 路径拥塞、存储控制器过载）
• Voting Disk 所在磁盘被其他高 I/O 操作干扰（例如备份、RMAN COPY、大表全扫写入同一 LUN）
• ASM disk path 多路径配置异常（如 ALUA 状态反复切换、路径 failover/failback 频繁）
• disk_repair_time 设置过短（尤其在慢速存储上），导致 transient I/O stall 被误判为磁盘永久故障

如何快速定位是哪个磁盘拖慢了 heartbeat？

别只看 v$asm_disk 的 state 和 mode_status —— 它们往往还是 ONLINE。真正要查的是 CSS 层的实时 I/O 延迟：

• 查看 $GRID_HOME/log/<hostname>/cssd/ocssd.log 中最近的 timeout 记录，注意时间戳和关联的 disk path（如 /dev/oracleasm/disks/VOTE01）
• 在 timeout 时间段内，用 iostat -x 1 观察对应磁盘的 %util 和 await（尤其 await > 200ms 是直接证据）
• 如果是 ASM 磁盘组，运行：

  asmcmd lsdsk -e

  看 path 和 repair_timer；再结合 asmcmd lsattr -G <DG_NAME> 确认 disk_repair_time 当前值

为什么把 Voting Disk 放进普通 ASM 磁盘组反而更危险？

Voting Disk 必须具备确定性低延迟，但普通 ASM 磁盘组（尤其是含多个 failure group 或混合介质）会引入不可控变量：

• ASM 的 extent 分配和 rebalance 可能造成随机 I/O 毛刺
• 若该磁盘组同时承载数据库文件，DBWR 或 ARCH 进程的突发写入会抢占磁盘带宽
• disk_repair_time 对整个磁盘组生效，无法为 Voting Disk 单独调优

正确做法是：

• Voting Disk 必须放在独立、专用、低延迟的磁盘组（推荐 EXTERNAL 冗余 + 3 块物理盘，不与数据混用）
• 使用 crsctl replace votedisk 迁移时，确保目标磁盘路径已通过 dd if=/dev/zero of=<path> bs=4k count=100 预热且无其他 I/O
• 禁用该磁盘组的 auto-rebalance：ALTER DISKGROUP <DG_NAME> DISABLE VOLUME ALL;（虽不直接相关，但减少干扰）

哪些参数或配置改动最容易引发误报？

改这些之前务必做 baseline 测试，否则可能把“偶发延迟”变成“稳定超时”：

• 把 misscount 从默认 60 秒调小（如设为 30）：会缩短驱逐窗口，但不会降低 timeout 触发频率，反而放大误判风险
• 在存储层启用 write-back cache 但未配电池/电容保护：掉电后 cache 数据丢失，导致 ASM 元数据不一致，后续 heartbeat read 返回校验错误而非延迟，也会表现为 timeout
• 启用 ASM_DISKSTRING 过于宽泛（如 /dev/sd*），导致 CSS 尝试探测大量无效路径，累积探测延迟

最稳妥的缓解动作是：

• 临时提升 disk_repair_time 到 300（单位秒），仅针对 Voting Disk 所在磁盘组
• 检查并固化多路径策略：mpathconf --show 确保 queue_if_no_path 为 yes，避免路径丢失时立即返回 I/O error
• 在 ocssd 启动参数中显式指定 heartbeat device（需 patch 支持），绕过 ASM 层抽象

实际环境里，80% 的 Disk Heartbeat Timeout 都藏在存储交付验收没做 I/O 压力测试，或者运维过程中悄悄把 Voting Disk 和归档日志挂到了同一套阵列上。问题不在 Oracle，而在你没把它当“心跳线”来保护。