oracle 19c rac本身不支持sharding，二者架构互斥：rac为共享存储多实例，sharding要求每个shard是独立单实例的shared-nothing架构，官方明确禁止且执行create sharded database必报ora-40582错误。
oracle 19c rac 本身不支持 sharding，任何试图在 rac 实例上启用分片的方案都会失败——这不是配置问题，而是架构互斥。
ORA-40582：RAC 环境下执行 CREATE SHARDED DATABASE 必报错
你运行 CREATE SHARDED DATABASE 时，Oracle 内核会立刻拦截并抛出 ORA-40582: Sharding is not supported in RAC environment。这不是权限或路径问题，是硬性限制。
原因在于：Sharding 要求每个 shard 是物理隔离、无共享（shared-nothing）的单实例数据库；而 RAC 的核心机制（如 cache fusion、全局队列服务 GES/GCS）恰恰依赖跨节点共享内存与块传输，这会破坏分片边界的数据一致性语义。
- 官方文档明确要求：
sharded database must be a single-instance Oracle database -
Shard Catalog和Shard Director (GSM)均无法注册或路由到 RAC 实例 - 即使绕过语法检查强行部署，后续数据重分布（
MOVE SHARD）、全局索引维护、分片键校验都会出现不可控异常
想水平扩展？必须放弃 RAC + Sharding 混合幻想
如果你的真实目标是“应对持续增长的写吞吐和数据量”，RAC 和 Sharding 是两条不同路径：
-
RAC提供的是**垂直+有限横向扩展**：加节点可提升读写并发，但所有节点争用同一份存储和全局资源，存在理论上限（尤其高争用 OLTP 场景） -
Sharding提供的是**无上限水平扩展**：数据按分片键拆分，业务请求被路由到独立数据库，瓶颈随节点线性摊薄
二者不能叠加，只能选其一。若已用 RAC，又急需水平伸缩能力，需做架构迁移，而非“在 RAC 上加 Sharding”。
正确搭建 Oracle Sharding 架构的关键约束
要真正落地 Sharding，必须严格分离三类组件，且全部避开 RAC：
-
Shard Catalog：单实例库（建议 19c EE），只存元数据，不承载业务表 -
Shard Databases：每个必须是 standalone（非 RAC）的 19c 单实例库，可跨主机/云区域部署 -
Shard Director (GSM)：单独部署的连接管理器，负责 SQL 路由；它通过REGISTER WITH向 catalog 注册，不与 RAC 共享任何进程或内存
典型命令示例（在 catalog 库中执行）：
CREATE SHARDCATALOG CONNECT TO cat_user@catalog_db REGISTER WITH gsm_region='east' USING gsm_host='gsm01' PORT=1522;
ADD SHARD CONNECT TO shard_user@shard1_db REGION 'east' AVAILABILITY 'ONLINE';
注意：@shard1_db 指向的必须是普通监听地址（如 shard1-scan:1521），绝不能是 RAC SCAN 或 VIP 地址。
最容易被忽略的兼容性陷阱
很多团队在测试环境用单实例模拟 shard 成功后，直接把生产 RAC 的副本“降级”为 standalone 来充作 shard，结果上线后出问题：
- ASM 配置残留：RAC 环境常用 Flex ASM，standalone shard 若误启 ASM 实例，会导致
GSM连接超时或路由失败 - 初始化参数冲突：如
cluster_database=TRUE未改为FALSE，实例启动即拒绝加入 shard topology - 网络 ACL 或防火墙规则沿用 RAC 内网策略，导致 GSM 无法访问 shard 的 listener 端口
最稳妥的做法：为每个 shard 新建干净的 standalone 安装，而非复用 RAC 节点降级。否则看似省事，实则埋下路由抖动、元数据同步中断等隐性故障。
