ORA-29740 表明CSS因连续misscnt次未收到心跳而驱逐节点，misscnt默认30（≈30秒中断容忍），非延迟容忍而是丢包次数；disktimeout控制表决盘I/O超时，默认200ms，与misscnt独立作用。
ORA-29740 是心跳超时的直接信号
只要集群节点被踢出（evicted），日志里大概率出现 ora-29740: cluster member death detected，这基本锁定是心跳链路出了问题。不是磁盘故障，也不是网络分区误判，而是 css（cluster synchronization services）在连续 misscnt 次未收到对端心跳后，主动触发驱逐。这个值不是“容忍延迟”，而是“允许丢包次数”——每次心跳周期（默认 1 秒）算一次机会，丢满 misscnt 次就动手。
-
misscnt默认是 30，对应理论最大容忍中断时长 ≈ 30 秒（但实际远小于此，因为心跳不是严格按秒准时发出） - 调高
misscnt不等于“更稳”，反而会延长故障发现时间，导致脑裂风险上升 - 调低虽能更快响应，但可能把瞬时网络抖动误判为节点死亡，尤其在高负载或共享存储延迟波动时
- 修改需重启 CSSD（
crsctl stop crs && crsctl start crs），不能热生效
DISKTIMEOUT 决定投票盘失效判定时机
disktimeout 控制的是 CSS 读取表决盘（voting disk）的等待上限，单位毫秒。它不参与节点间心跳判断，只影响“我还能不能继续当集群一员”的资格审查。一旦连续多次读表决盘超时（次数由内部逻辑控制，不暴露给用户），CSS 就会认为自己已与集群失联，主动退出。
- 默认值通常是 200ms，适用于低延迟 SAN 或本地 NVMe；若用 NFS 或高延迟 ASM 磁盘，可能频繁触发
CRS-4639: Could not contact Oracle High Availability Services - 该参数和
misscnt没有数学换算关系，二者独立作用：一个管“听不见邻居”，一个管“摸不到票箱” - 调整前必须确认底层存储 I/O 稳定性，否则只是掩盖问题——比如把
disktimeout改成 500ms，却无法解决存储队列积压，最终仍会失败 - 修改方式：通过
crsctl set css disktimeout <ms></ms>，无需重启，但新值仅对后续 I/O 生效
查当前值别只信文档，默认值可能已被覆盖
Oracle 安装或补丁升级后，misscnt 和 disktimeout 可能被隐式重置或继承自 profile。不能假设“没改过就是默认值”。最可靠的方式是现场查：
crsctl get css misscnt crsctl get css disktimeout
- 如果返回
CRS-4678: Unable to retrieve the value，说明该参数从未显式设置过，此时才真正使用文档所写的默认值 - 某些版本（如 11.2.0.4 之后）对
misscnt有硬性下限（如 ≥ 15），设太小会被拒绝 -
disktimeout在 12c RAC 中已逐步被cssd的自适应超时机制弱化，但仍有效，尤其在非 ASM 存储场景
真实故障中两个参数常被同时扰动
网络拥塞、存储卡顿、CSSD 进程 CPU 饱和，往往同时拉长心跳响应时间和表决盘 I/O 延迟。这时候单调一个参数，很容易顾此失彼：比如只加 misscnt，可能让节点在存储已不可用时还强行留在集群里，造成资源争用甚至数据损坏。
- 优先排查硬件层：交换机 buffer、iSCSI timeout 设置、多路径策略（如 ALUA 切换是否静默）、NTP 偏移（> 1s 会导致 CSS 心跳校验失败）
- 抓包看真实心跳间隔：
tcpdump -i bond0 port 12345（CSS 默认 UDP 端口，具体查olsnodes -s -t输出） - 用
cssdagent日志（$GRID_HOME/log/<host>/cssd/ocssd.log</host>）定位是 “missed heartbeat from node X” 还是 “failed to read voting file” - 修改任一参数后，务必做模拟故障测试（如
iptables -A INPUT -s <other-node> -j DROP</other-node>），观察驱逐行为是否符合预期
misscnt 和 disktimeout 很少单独出问题——它们更像是故障的“计数器”，而不是“病因”。调参之前，先确认网络和存储的基线是否干净，比盲目加数字重要得多。
