Flex Cluster并非用于优化应用节点，其Leaf节点仅支持只读数据库实例，不直接访问共享存储、不运行ASM实例，也不能部署WebLogic等应用中间件；真正优化应用需依赖客户端连接策略（如SCAN、专用服务名、tnsnames.ora配置）及外部容器化或负载均衡方案。
Flex Cluster 不是用来“优化应用节点”的——它根本就不是为应用层设计的，强行套用会出问题。
如果你在 RAC 环境里想把应用服务器（比如 WebLogic、Tomcat）直接塞进 Leaf 节点并指望“自动优化”，那大概率会遇到连接失败、服务不可达、ASM 访问异常等现象。Flex Cluster 的 Leaf 节点是数据库架构层面的概念，不是通用的应用托管容器。
Leaf 节点只能运行只读数据库实例，不能部署应用服务
Leaf 节点在 Flex Cluster 中的定位非常明确：它不直接访问共享存储，不运行 ASM 实例，也不能启动读写型数据库实例。官方只允许在 Leaf 上启动 READ ONLY 的 PDB 实例（且必须有 Hub 节点配合提供 OCR/VD 和 ASM 服务）。这意味着：
- Leaf 上无法创建数据文件、重做日志、控制文件，
CREATE DATABASE或STARTUP MOUNT都会报ORA-01092或ORA-15078 - 你不能在 Leaf 上部署需要写库的应用中间件；哪怕只是连上跑个
INSERT，也会因实例非读写态被拒绝 - Leaf 节点上的监听器（
lsnrctl）默认不注册任何读写服务名，srvctl add service对它无效 - 应用如果直连 Leaf 的 VIP，很可能连上就报
ORA-12514: TNS:listener does not currently know of service requested
真正能“优化应用节点”的是客户端连接策略，不是 Flex Cluster 拓扑
Flex Cluster 本身不参与应用路由或负载分发。你要让应用更高效地使用 RAC，关键在客户端配置和数据库服务管理：
- 用
SCAN地址代替单节点 VIP，由 Oracle Clusterware 自动做连接负载均衡 - 为不同业务类型创建专用服务名，例如：
srvctl add service -d mycdb -s report_svc -r "hub1, hub2" -l PRIMARY -y MANUAL -q TRUE，再让报表应用连report_svc - 在
tnsnames.ora中启用LOAD_BALANCE=on和FAILOVER=on，避免硬编码到某个 Hub 节点 - Leaf 节点唯一合理的“应用侧”用途，是作为轻量级的只读查询终端——比如部署一个 BI 工具，只连
ro_svc服务，并确保该服务只在 Leaf 实例上注册（通过-i指定实例名）
LOCAL TEMP 表空间不是给应用节点用的，是给 Leaf 上的只读实例减压的
你在 Leaf 节点上看到 LOCAL_ON_RIM 类型的临时表空间，别误以为这是给应用进程分配本地磁盘缓存。它的作用非常具体：
- 仅当 Leaf 上运行了
READ ONLY实例，且该实例执行大排序（ORDER BY、GROUP BY、哈希连接）时，才用得上这个本地TEMP - 它避免了多个 Leaf 实例争抢同一个共享
TEMP表空间的全局资源，但前提是这些 Leaf 实例真正在运行——而现实中绝大多数部署根本没启 Leaf 实例 -
CREATE TEMPORARY TABLESPACE ... LOCAL ON RIM在没有只读实例的环境下会直接报ORA-32778，不是配置遗漏，是前提不满足 - 应用进程本身不感知、也不控制用哪个
TEMP；它完全由所在实例的初始化参数temp_tablespace决定
Flex Cluster 的价值在于解耦数据库基础设施的扩展粒度，不是简化应用部署。如果你的应用需要弹性伸缩，该用 Kubernetes 就用 Kubernetes，该用应用负载均衡器就配好健康检查——别指望把 Web 应用塞进 Leaf 节点就能“自动高可用”。真正容易被忽略的一点是：Leaf 节点一旦加入集群，就必须始终由 Hub 节点管理其生命周期；你不能单独重启、补丁或升级它，否则整个集群的 OCR 状态可能异常。
