oracle 19c rac 默认启用 flex asm，而11g不支持；19c采用跨节点弹性asm服务，实例数可少于节点数，依赖systemd管理集群，scan校验更严格，节点驱逐机制多维精细，且asmcmd lsct可验证flex状态。
Oracle 19c RAC 默认启用 Flex ASM，11g 不支持
11g RAC 的 ASM 实例必须与数据库实例一一绑定在相同节点上，每个节点运行自己的 ASM 实例；19c 默认采用 Flex ASM 模式，ASM 实例可跨节点提供服务，数量可少于节点数（如 4 节点 RAC 只启 2 个 ASM 实例），降低资源开销且提升容错能力。
关键区别在于：FLEX_ASM 初始化参数在 11g 不存在，19c 中默认为 TRUE。若误在 19c 中设为 FALSE，会退化为 11g 风格的固定绑定模式，失去弹性优势。
检查方式：在任意节点执行 asmcmd lsct，若输出中 STATE 列显示 FLEX，说明已启用 Flex ASM；11g 执行该命令会报错或无此功能。
19c RAC 的 Clusterware 启动依赖 systemd，11g 依赖 init.d 或 runlevel 脚本
11g 使用 crsctl start crs 启动集群时，底层由 init.ohasd 和 init.crsd 等 shell 脚本控制；19c（RHEL7+ / OL7+）将 Oracle Clusterware 注册为 systemd 服务，启动入口变为 systemctl start oracle-crshigh 或 systemctl start oracle-ohasd。
这意味着：
- 11g 的
/etc/oracle/ocr.loc配置仍有效，但 19c 更依赖/etc/systemd/system/oracle-*.service中的EnvironmentFile指向 OCR 位置 - 升级后若未运行
roothas.sh或rootcrs.sh重新注册服务，systemd 无法识别集群进程，crsctl check crs会持续返回CRS-4638: Oracle High Availability Services is online但实际资源离线 -
crsctl stat res -t在 19c 中默认显示更细粒度的资源状态（如ora.asm下分ora.asm.acfs、ora.asm.asmnet1.asmnetwork），11g 仅显示顶层资源
19c RAC 的 SCAN Listener 行为更严格，11g 允许部分配置缺陷“侥幸通过”
SCAN（Single Client Access Name）在 11g 和 19c 中都存在，但 19c 对其 DNS 解析、网络可达性、端口监听的校验前置到集群启动阶段。例如：
- 11g 中若 SCAN IP 未全部注册进 DNS，只要有一个能解析，
srvctl start scan可能成功，后续连接偶尔失败 - 19c 要求全部 3 个 SCAN IP 必须同时可解析且对应 SCAN VIP 能被本地节点访问，否则
srvctl start scan直接报CRS-2674: Start of 'ora.scan1.vip' on 'node1' failed - 19c 的
lsnrctl status LISTENER_SCAN1显示的Service "xxxxx" has 1 instance(s)中的实例名格式为db_unique_name_DGMGRL（含 DGMGRL 标识），而 11g 是传统db_unique_name，这对 Data Guard Broker 集成有隐性影响
19c RAC 的节点驱逐（Node Eviction）触发条件更精细，11g 更依赖粗粒度心跳超时
11g 主要依赖 CSS（Cluster Synchronization Services）心跳丢失（默认 misscount=30 秒）直接触发节点重启；19c 引入了多层健康检查：CSS 心跳、OS Watcher 进程存活、I/O 延迟阈值（_css_io_timeout）、甚至网络吞吐骤降都会参与综合判定。
这意味着：
- 19c 中出现短暂网络抖动（如 5 秒丢包）可能不会立即驱逐，但若叠加磁盘 I/O 延迟超过 2 秒（默认值），就可能触发
ORA-29770: Global Enqueue Service Process died并进入驱逐流程 -
crsctl get css misscount在 11g 返回整数，在 19c 可能返回misscount=60, disktimeout=200, reboottime=300—— 三个独立参数，不能只调一个 - 19c 的
ocssd.trc日志中新增eviction_reason字段，明确记录是 “network partition”、“disk hang” 还是 “process death”，而 11g 日志里只有模糊的 “missed heartbeat”
asm_diskgroup.state）可能长时间处于 REBALANCING，容易被误判为卡住。
