根本原因是权重仅在脑裂（网络分区+voting disk不可达）时参与仲裁，而多数驱逐由心跳超时等单点故障触发，此时权重完全不生效。
节点权重配置后驱逐结果与预期不符，根本原因是什么？
不是权重没生效，而是权重只在脑裂（split-brain）场景下参与仲裁——当所有节点仍能通过 voting disk 达成多数派共识时，权重完全不参与决策。很多误判源于把网络抖动、ocssd卡死等单点故障当成脑裂，强行套用权重逻辑。
常见错误现象：
-
crsctl query css votedisk显示 voting disk 可访问，但日志里仍有node eviction initiated - 手动给 node2 设置高权重，结果 node1 被驱逐，而 node2 实际已因
ocssd.bin进程卡死离线 - 两节点集群中，私网中断后 node2 保留，但其 alert.log 里明确记录
ORA-29740: evicted by instance 1
真实触发条件：
- 必须满足“网络分区 + voting disk 不可达”两个条件，才会进入基于权重的仲裁流程
- 权重值由
srvctl modify nodeapps -n <node> -w <weight></weight></node>设置，但仅对 12.2+ 生效；11g/12.1 及以下版本无视该参数 - 权重影响的是“存活子集群”的选择，不是单个节点保活——若 node1 和 node2 各自成孤岛且都宣称自己是 majority，则权重高的子集群胜出
如何验证当前驱逐是否真的走了权重路径？
查 $GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，真正走权重仲裁的日志特征是连续出现：
Quorum loss detected: no majority vote availableEvaluating node weights for split-brain resolutionSelected node <n> (weight=<w>) as survivor in subcluster</w></n>
如果只看到 Eviction initiated for node X 但没有上述三行，说明是常规心跳超时驱逐，权重未参与。此时调权重毫无意义，应立即检查：
-
iostat -x 1查 voting disk 所在 ASM 磁盘组的%util是否 > 95 -
dmesg -T | grep -i "ocssd\|kill"确认 ocssd 进程是否被 OOM Killer 终止 -
ethtool -S <private_nic> | grep -E "(rx_discards|rx_errors|tx_errors)"</private_nic>看物理层丢包
权重值设多大才算合理？
权重本身无单位，只用于相对比较。但生产环境容易踩两个坑：
- 把权重设成 1000 甚至 10000，导致其他节点权重相形见绌——实际只需拉开 2–3 倍差距即可，例如 node1 设 10，node2 设 25
- 只改一个节点权重，另一节点保持默认（默认为 0），造成仲裁失衡；必须显式设置所有节点权重，未设置的节点按 0 处理
- 权重不能动态覆盖硬件资源瓶颈：若 node2 权重最高但其私网网卡已因中断风暴丢包，CSSD 仍会判定它不可信并驱逐
真正起作用的永远是底层心跳通路是否可信，权重只是脑裂时的“最后一道选择器”。别在 ocssd 卡死或 voting disk IO 饱和时寄希望于调权重——那相当于给刹车失灵的车换方向盘。
