如何利用Oracle 19c RAC的Sharding功能实现水平扩展-Oracle-PHP中文网

Oracle 19c RAC本身不支持Sharding，二者是正交互斥架构：RAC为共享存储多实例，Sharding为shared-nothing水平拆分，官方要求每个shard必须是独立单实例库，非RAC。

Oracle 19c RAC **本身不支持 Sharding**。这是最关键的前提，必须先厘清——RAC 和 Sharding 是 Oracle 提供的两种**正交、互斥**的分布式架构方案，不能混用。 RAC 是共享存储（Shared Storage）下的多实例高可用架构，所有节点访问同一份数据；而 Sharding 是共享**nothing**架构，数据按分片规则物理隔离在不同数据库实例中。Oracle 官方明确要求：**Sharding 必须部署在独立的、非 RAC 的单实例数据库上（即每个 Shard 是一个 standalone Oracle DB）**。所以，如果你的目标是“水平扩展”，需要放弃“在 RAC 上启用 Sharding”的想法，转为构建 **Oracle Sharding 架构（Shard Catalog + Shard Directors + Multiple Standalone Databases）**。下面直奔实操要点：

为什么不能在 RAC 实例上部署 Shard？

oracle sharding 的元数据管理、分片路由、数据重分布等核心能力依赖 shard director（基于 oracle connection manager 或 gds）与 shard catalog 数据库协同工作。而 rac 的缓存融合（cache fusion）机制会干扰分片间的数据一致性模型——比如跨节点的块传输可能绕过 shard boundary 检查，导致分片键约束失效或全局索引错乱。

官方文档（Oracle Database 19c Sharding Guide）明确列出限制：sharded database must be a single-instance Oracle database。尝试在 RAC 上运行 CREATE SHARDED DATABASE 会直接报错 ORA-40582: Sharding is not supported in RAC environment。

如何正确搭建 Oracle 19c Sharding 架构？

典型三组件拓扑（必须分离部署）：

shard catalog：单实例库（建议 19c EE），存放全局元数据（分片拓扑、分片映射、GSM 配置）；不存业务数据
shard databases：多个独立的单实例 19c 数据库（可跨主机/云区域），每个是一个 SHARD，承载部分业务数据；绝对不可是 RAC
shard director（GSM / CDB-based）：负责 SQL 路由，将请求精准转发到目标 shard；需单独部署并注册到 catalog

关键命令示例（在 catalog 库中执行）：

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

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';

常见误操作与排障点

新手最容易踩的坑集中在网络和权限层面：

所有 shard 实例必须能通过 TNSNAMES.ora 或 EZCONNECT 方式被 shard catalog 和 GSM 反向解析和连接；TNSPING 测试必须通，且不能依赖 localhost 或 127.0.0.1
shard catalog 用户需有 SHARD_CATALOG_ADMIN 角色，shard 用户需有 SHARD_ADMIN 角色；角色必须显式授予，不能靠 DBA 继承
若使用 GSM（Global Service Manager），其监听端口（默认 1522）必须开放防火墙，且 gsmctl 注册时提示 ORA-12541: No listener 往往是 GSM 进程未启动，而非数据库监听问题
分片表创建后插入数据报 ORA-01400: cannot insert NULL into "SYS"."SHPARTITION$"，说明分片键（SHARD KEY）列未指定或值为 NULL——Sharding 要求每张分片表必须定义非空、不可更新的分片键列

性能与运维现实约束

Sharding 带来水平扩展能力的同时，也引入了新复杂度：

跨分片查询（如 SELECT COUNT(*) FROM orders）由 catalog 下推执行，但无法利用并行查询加速，响应时间取决于最慢 shard；建议用物化视图或应用层聚合替代
添加新 shard 后，MOVE SHARD 会触发在线数据迁移，期间该 shard 只读；迁移速度受限于网络带宽和源/目标库 I/O 能力，不是“秒级弹性”
备份必须分别对 catalog 和每个 shard 执行，无法用 RMAN 单命令统一备份整个逻辑库；恢复时需严格按 catalog → shards 顺序

真正容易被忽略的是分片键设计——它一旦选定就极难变更。选用户 ID？那跨国业务中 GDPR 删除请求会变成全分片扫描。选时间戳？冷热数据倾斜会导致负载不均。这不是部署问题，而是数据架构决策，得在建模阶段就定死。