Oracle 23c未新增Data Guard保护模式或redo协议，但通过Active Data Guard增强实现可控实时负载分担、PDB级只读开关、max_latency_threshold自动降级、AI驱动的同步异常预测及PL/SQL警告兼容性管控。
Oracle 23c 本身没有为 Data Guard 引入新保护模式或底层复制协议变更；它沿用 19c/21c 的 Data Guard 架构，但通过 Active Data Guard 和配套工具链的增强，显著提升了高可用场景下的可观测性、自动化与 AI 集成能力。
Active Data Guard 在 23c 中的实时负载分担能力更可控
23c 并未修改 Data Guard 的 redo 传输机制，但强化了 ADG（Active Data Guard）备库在只读负载下的资源隔离策略。关键改进点包括：
-
V$DG_BROKER_CONFIG新增STANDBY_LOAD_BALANCE字段，可显式控制是否将只读连接路由至备库实例 - 当启用
ENABLE_PLUGGABLE_DATABASE且备库为多租户时，ALTER PLUGGABLE DATABASE ... OPEN READ ONLY支持按 PDB 级别开关只读访问，避免全库级误启 -
DBMS_DG.BEGIN_TRANSFER在 23c 中支持指定max_latency_threshold参数，超时自动降级为本地查询，防止备库延迟抖动拖垮应用
23c 的 JSON Relational Duality 与 Data Guard 同步兼容性需手动验证
使用 DUALITY 视图的表结构变更（如新增 JSON 列映射关系）会触发隐式 DDL，这类操作在 Data Guard 环境中可能引发同步中断。常见问题包括：
- 主库执行
CREATE DUALITY VIEW后，备库APPLY进程可能卡在waiting for dictionary log，因字典同步依赖 LogMiner 解析，而 Duality 视图定义未被完整捕获 - 若主库开启
ENABLE JSON_SCHEMA_VALIDATION，备库必须提前部署相同 schema 文件，否则INSERT INTO duality_view会在备库报ORA-40478错误 - 建议在 Data Guard 部署中禁用
JSON_RELATIONAL_DUALITY_AUTO_SYNC初始化参数，改用显式DBMS_JSON.SYNC_DUALITY控制同步时机
23c 的 AI 功能对 Data Guard 故障转移流程无直接增强，但改变了监控方式
Oracle Database 23ai（即 23c 的正式命名演进）引入的 AI 能力并未修改 Data Guard 的 FAILOVER 或 SWITCHOVER 内核逻辑，但提供了新的可观测入口：
-
DBMS_AI.DETECT_ANOMALY可接入V$DATAGUARD_STATS流，对apply_lag、transport_lag做趋势预测，提前 5–8 分钟预警潜在同步断裂 -
AI_VECTOR_INDEX不支持在物理备库上创建，但可在逻辑备库（Logical Standby）中用于构建变更分析模型——前提是主库已启用LOG_MINING并保留完整字典归档 - 注意：所有 AI 函数调用均绕过 Data Guard 的 redo 应用路径，因此不会影响 RPO/RTO 指标，但会增加备库 CPU 开销，需在
RESOURCE_MANAGER_PLAN中为AI_CONSUMER_GROUP设置 CPU 限额
真正容易被忽略的是：23c 的 ENABLE_PLSQL_WARNINGS 默认开启，而 Data Guard 备库的 PLSQL_WARNINGS 参数继承自主库。如果主库有大量带警告的包体（如 SEVERE:05001），备库在编译时可能因警告升级为错误导致 APPLY 进程中断——这不是 Data Guard 本身的缺陷，而是 23c 更严格的 PL/SQL 编译策略与高可用链路耦合后暴露的配置盲区。
