oracle 12c rac升级后不一定需重配flex asm，但必须手动验证三项：asmcmd showclustermode是否含direct storage access、私网telnet 1522是否连通、gv$asm_client是否跨节点注册，否则flex架构将退化为传统模式。
Oracle 12c RAC 升级后不一定需要重新配置 Flex ASM，但极大概率要手动验证和调整——因为升级过程本身不自动迁移或重置 Flex ASM 的网络、实例基数、监听器等关键配置，而这些项在升级前后容易出现不一致或失效。
Flex ASM 配置在升级中不会被自动保留
Oracle 升级（如从 12.1 → 12.2 或 12.2 → 19c）只升级软件二进制和 OCR 中的资源定义，ASM 实例的运行模式（Flex / Non-Flex）虽由 OCR 记录，但以下几类配置**不会被自动校验或同步**：
-
oifcfg中的私网接口绑定（如enp0s9/192.168.0.0:cluster_interconnect,asm）可能仍指向旧网卡或子网，升级后若底层网络已变更，Flex ASM 客户端连接会超时 - ASM 基数（
asmca -configureFLEXASM设置的实例数）在升级后仍保留在 OCR，但若集群节点数变化或资源压力不同，原基数可能不再适用 -
ASMNET1LSNR_ASM监听器的endpoints配置可能未适配新 GI 主目录路径，导致远程 ASM 连接失败 - OCR/Voting Disk 所在磁盘组若在升级前未用 Flex ASM 模式挂载（即未启用
COMPATIBLE.ASM >= 12.1），升级后showclustermode可能误报为非 Flex 模式
升级后 Flex ASM 失效的典型现象
不是报错才叫失效；很多问题表现为“看似正常，实则降级运行”：
-
asmcmd showclustermode显示Flex mode enabled，但srvctl status asm -detail显示所有节点都运行 ASM 实例，且每个数据库实例都连本地 ASM —— 这是伪 Flex，本质仍是传统模式 - 手动 kill 一个节点的
asm_pmon_+ASM1后，其他节点未自动拉起新 ASM 实例承接连接，crsctl stat res -t | grep asm中无 failover 日志 - 数据库实例启动时报
ORA-15100: no diskgroups mounted，但 ASM 实例明明 running —— 实际是客户端无法通过 ASM proxy 连到远端 ASM -
lsnrctl status ASMNET1LSNR_ASM显示监听器没注册任何 service，或ENDPOINTS绑定在 127.0.0.1 而非私网 IP
必须执行的三项验证动作
别跳过，每项都对应一个真实故障点：
- 确认 Flex 模式真正生效：
asmcmd showclustermode输出必须含Direct Storage Access，且srvctl config asm中ASM Instance Count不为 0（非 Flex 模式下该值为空或报错） - 检查 ASM 网络可达性：在任一节点执行
telnet <peer-node-private-ip> 1522</peer-node-private-ip>（ASM proxy 默认端口），不通说明oifcfg或防火墙阻断 - 验证客户端路由能力：连上任意数据库实例，查
SELECT inst_id, asm_client_name FROM gv$asm_client;—— 若inst_id和asm_client_name出现在多个不同 ASM 实例下，才是真正的跨节点代理
Flex ASM 的“配置”本身很轻量，但它的行为依赖底层网络、监听器、OCR 元数据三者严格对齐。升级就像给一辆高速行驶的车换引擎——零件装上了，油路、电路、ECU 参数未必自动匹配。最容易被忽略的是私网接口绑定是否还有效，以及监听器是否真在监听集群私网段。这两处一错，整个 Flex 架构就退化成“多个独立 ASM 实例”，故障隔离和负载均衡全部失效。
