Oracle 21c Data Guard核心机制不变，重点增强PDB级容灾、ADG统计同步及RAC+DG Broker故障恢复能力。PDB级DG正式GA，要求主备库均为21c且同名同GUID；ADG自动同步统计信息，默认延迟≤5秒；Broker优化健康检查，阈值降至15秒。
Data Guard 在 Oracle 21c 中并未引入颠覆性的新架构或全新组件，其核心机制（Redo 传输、Apply、角色切换）与 19c 保持一致。真正值得关注的是**基于 PDB 粒度的精细化容灾能力落地**，以及若干关键增强在 RAC+DG 场景下的实际表现优化。
基于 PDB 的 ADG（Active Data Guard）正式 GA
Oracle 21c 是首个将 PDB-level Data Guard 从技术预览（TP）转为正式支持（GA）的版本。这意味着你不再必须对整个 CDB 做主备同步，而是可以单独为某个关键业务 PDB 配置独立的 Standby PDB。
- 适用场景：多租户环境中，仅部分 PDB 有高可用/容灾需求（如核心账务 PDB），其余测试或开发 PDB 不需同步，节省网络带宽与备库资源
- 配置前提：主库和备库都必须是 Oracle 21c（或更高），且使用
ENABLE PLUGGABLE DATABASE创建的 CDB；不能跨版本搭建 PDB 级 DG - 关键限制：Standby PDB 必须与主库 PDB 同名、同 GUID（即通过
CREATE PLUGGABLE DATABASE ... FROM ... SERVICE或DUPLICATE TARGET DATABASE FOR STANDBY创建），不支持手动重命名或修改 GUID - 错误现象示例：
ORA-65144: The pluggable database name does not match the source—— 备库 PDB 名称或 GUID 与主库不一致时触发
ADG 实时查询性能与统计信息同步增强
Oracle 21c 改进了 Active Data Guard 在只读打开状态下对全局统计信息（DBA_TAB_STATISTICS）和动态性能视图（如 V$PDBS, V$CONTAINERS）的刷新机制，避免因统计过期导致执行计划劣化。
- 默认启用
_data_guard_sync_stats隐含参数（值为TRUE），使备库在应用 Redo 后自动同步数据字典统计快照（非实时，但延迟控制在秒级） - 若关闭该特性（不推荐），可能在备库执行
SELECT COUNT(*) FROM big_table时因统计陈旧而走全表扫描，而主库已走索引范围扫描 - 验证方式：在备库执行
SELECT last_analyzed FROM dba_tables WHERE table_name = 'BIG_TABLE'，对比主库时间差应 ≤ 5 秒
RAC 环境下 DG Broker 对多节点故障的恢复逻辑优化
在 RAC + Data Guard “2+2” 架构中，Oracle 21c 的 DG Broker（dgmgrl）增强了对“主库 RAC 部分节点宕机 + 网络分区”混合故障的识别与响应能力。
- 以前版本（如 19c）中，若主库双节点只剩一个存活，Broker 可能误判为“主库整体不可用”，触发不必要的 Failover
- 21c 引入更细粒度的
Fast-Start Failover健康检查：默认每 10 秒探测一次所有主库实例的LGWR进程状态，而非仅依赖 CRS 资源状态 - 关键配置项：
FastStartFailoverThreshold默认值从 30 秒降至 15 秒，FastStartFailoverLagLimit支持按 PDB 设置（需配合ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH） - 容易踩的坑：升级到 21c 后未重置 Broker 配置，仍沿用 19c 的阈值，可能导致 Failover 过于激进
不建议依赖的“伪增强”：SQL 集合运算符与 DG 无关
网上常有文章将 Oracle 21c 新增的 EXCEPT ALL、INTERSECT ALL 等 SQL 特性归类为 DG 增强，这是误解。这些语法改进仅影响单库内查询逻辑，Data Guard 的 Redo 生成与应用完全基于 DML/DDL 操作本身，与集合运算符是否带 ALL 无任何关联。
真正影响 DG 的 SQL 行为，仍是那些会触发大量 Redo 的操作，比如未加 NOLOGGING 的大表 INSERT /*+ APPEND */，或频繁 TRUNCATE —— 这些在 21c 中的处理逻辑与 19c 完全一致。
最易被忽略的一点：PDB 级 DG 的日志传输仍依赖主库 CDB 的 LOG_ARCHIVE_DEST_n 配置，而不是 PDB 自身设置；一旦主库 CDB 层面归档目标失效，所有 PDB 的同步都会中断，不存在“某个 PDB 独立走另一条链路”的能力。
