oracle 19c rac不是简单加节点即高可用，而是需对齐业务sla、基础设施与运维能力的系统工程；其核心适用场景是要求秒级无感故障转移、实例级负载横向扩展且已具备共享存储的金融类oltp系统，而非所有“不能停机”场景。
Oracle 19c RAC不是“加个节点就高可用”，它是一套需要对齐业务SLA、基础设施约束和运维能力的系统工程。直接上RAC却忽略IO路径瓶颈、私网抖动或OCR单点风险，反而会把单点故障放大成集群级雪崩。
怎么判断你的业务真需要RAC，而不是Data Guard或读写分离？
核心看三点：是否要求秒级无感故障转移、是否承受实例级负载横向扩展、是否已有共享存储基础设施。金融账务类OLTP系统通常符合；报表类或ETL调度类任务，用Data Guard+应用重连更轻量可靠。常见误判是把“不能停机”等同于“必须RAC”——其实很多场景下，应用层配合TAF（Transparent Application Failover）+ Data Guard切换（60秒内）已足够，且备份恢复链路更清晰。
- 如果业务允许分钟级中断，优先验证
srvctl stop instance -i后应用自动重连能力，再决定是否投入RAC复杂度 - RAC无法规避存储阵列故障，若后端是单台NAS或未做多路径的iSCSI，加RAC只是把两个节点一起挂掉
- 检查现有中间件是否支持SCAN连接串；不支持的旧Java应用可能需升级JDBC驱动或改用VIP直连
私网设计为什么比公网配置更容易翻车？
私网不是“通了就行”，它是Cache Fusion的生命线。阿里云ECS默认VPC网络下eth0走虚拟交换机，延迟抖动常超20ms，直接触发cssd进程反复重启。真实生产环境里，73%的RAC不稳定问题根因在私网。
- 必须用独立网段（如
10.10.10.0/24），严禁与公网、管理网混用；避免使用192.168.0.0/16等易冲突地址段 - 云上环境放弃bonding，改用
HAIP（Highly Available IP）——这是Oracle 11gR2起内置的私网冗余机制，无需OS绑定，由ohasd自动漂移 - 强制关闭私网接口的
arp_ignore和arp_announce，否则跨节点ARP请求可能被丢弃 - 用
ping -c 10 -s 8972 <private_ip></private_ip>测巨型帧（MTU=9000）连通性，失败则回退到MTU=1500并检查云平台安全组
OCR和ASM磁盘组规划最容易被跳过的三个硬约束
OCR不是普通文件，它是集群心跳的“脑干”。放错位置或冗余不足，整个RAC会在你执行crsctl start crs时静默失败。
-
OCR必须放在NORMAL冗余ASM磁盘组，且至少3块物理盘（对应3个failure group）；放EXTERNAL冗余组等于裸奔，一块盘坏=集群瘫痪 -
+DATA磁盘组建议用NORMAL冗余，但切勿与OCR共用同一组物理盘——否则I/O争抢会导致crsd超时退出 - 所有ASM磁盘设备名必须通过UDEV或
asmudev固化，云盘场景下/dev/xvdb重启后可能变成/dev/xvdc，导致oracleasm scandisks找不到盘
验证高可用不能只跑crsctl check crs
这个命令只告诉你CRS进程活着，不代表业务能接管。真正要模拟的是“节点硬关机”后的服务连续性。
- 用
srvctl stop nodeapps -n <node></node>模拟节点宕机，观察srvctl status scan中SCAN监听是否30秒内切到另一节点 - 在客户端持续执行
sqlplus /@myrac-scan:1521/orclpdb，同时在服务端执行kill -9 $(pgrep -f 'ora_lms')，确认连接不中断且事务不回滚 - 检查
gv$cluster_interconnects视图，确认私网带宽占用率长期低于60%，否则Cache Fusion会降级为disk-based同步
最常被忽略的是时间同步精度——chrony必须配置makestep 1.0 -1，否则节点间时钟差超500ms，GCS锁管理器就会拒绝同步请求，现象是ORA-29702错误反复出现。
