Oracle Data Guard 为每个分片单独提供物理容灾，不支持集群级统一配置；需为各主分片独立部署DG，配合Active Data Guard提升只读负载能力，并通过外部机制实现与GSM的故障联动。
oracle data guard 本身不直接管理分片（sharding）拓扑，但它可以无缝集成到分片架构中，为每个独立分片提供物理级容灾能力——也就是说，分片是逻辑/数据分布单元，data guard 是单分片的高可用与灾备单元。你不能对整个分片集群“一键开启 dg”，但可以且必须为每个主分片单独配置对应的物理备用分片。
每个分片需独立部署一套 Data Guard 配置
Oracle 分片（Sharding）将数据水平切分到多个独立数据库实例（即分片），每个分片是功能完整、可单独启停的 Oracle 数据库。因此：
-
Data Guard的保护范围仅限于单个数据库实例，所以每个主分片（primary shard）都必须配对一个或多个STANDBY实例，形成独立的 DG 配置 - 分片目录（Shard Catalog）和分片引导器（GSM）本身不参与 DG 复制；它们需单独备份（如用
RMAN或控制文件快照），因为它们不存储用户表数据 - 跨云部署时（如主分片在 OCI，备用分片在 AWS），只要网络可达、
tnsnames.ora和监听器配置正确，LOG_ARCHIVE_DEST_n仍可指向远端，但需注意加密与防火墙放行1521或自定义端口
物理备库 + Active Data Guard 是分片场景的推荐组合
分片系统通常承载读写混合负载，单纯只读备库利用率低；而启用 Active Data Guard 后，备用分片可同时承担只读查询（如报表、BI），这对分片架构很关键：
- 执行
ALTER DATABASE OPEN READ ONLY后，再运行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT，即可启动实时应用归档日志 - 注意：
ADG要求主备数据库版本、补丁集（Patch Set Update）完全一致，否则ORA-16664或ORA-1092错误会中断同步 - 如果主分片启用了透明数据加密（TDE），必须确保备分片使用相同的
keystore文件和密码，否则RECOVER会卡在加密数据块上
分片故障转移 ≠ Data Guard 故障切换
这是最容易混淆的点：Data Guard 的 SWITCHOVER 或 FAILOVER 只影响单个分片实例；而整个分片集群的可用性由 Shard Director（或 GSM）协调：
- 当某个主分片宕机，DG 自动完成该分片的故障切换后，GSM 不会自动重路由连接——你必须手动或通过脚本触发
SHARD RELOCATE或更新shardmap - 若未提前配置
GSM的健康检查（如gsmctl check gsm+ 自定义 ping 脚本），客户端可能持续尝试连接已失效的旧分片地址 - 逻辑备用（Logical Standby）在分片中极少使用，因为 DDL 变更（如
SHARDING KEY调整）容易导致 SQL Apply 中断，且无法支持全部 Oracle 数据类型
备份策略必须分层设计：RMAN + DG 归档双保险
仅靠 DG 同步不能替代备份。分片环境下的 RMAN 策略要明确区分角色：
- 主分片：每天全备 + 每小时增量 + 归档日志实时备份到共享存储或对象存储（如 OCI Object Storage），保留策略设为
RECOVERY WINDOW OF 7 DAYS - 备分片：不建议直接从备库发起
BACKUP DATABASE（可能因ARCHIVE LOG CURRENT报ORA-01156）；应通过CONNECT TARGET指向主库，或改用BACKUP AS COPY从备库拷贝数据文件（需先RECOVER至一致点） - 归档日志传输延迟监控不能只看
V$ARCHIVE_DEST_STATUS的APPLIED_TIME，还要比对主库V$ARCHIVED_LOG.FIRST_TIME和备库V$ARCHIVED_LOG.NEXT_TIME，避免因网络抖动造成“假同步”
真正难的不是配置 DG，而是让 DG 的状态变化能被分片管理层感知并联动响应——比如 DG 切换后，如何让 GSM 自动刷新分片路由表、如何避免客户端连接池缓存过期的 VIP 地址。这些不在 ALTER DATABASE 命令里，得靠外部脚本+事件触发器+DNS TTL 控制来补全。
