oracle 11g与19c的data guard核心机制一致，但配置、默认行为、诊断及功能边界存在显著差异：19c对db_create_file_dest和standby_file_management更严格；dgmgrl校验更严；新增adg dml重定向需显式启用；闪回数据库协同更智能；validate database警告更关键。
Data Guard 的核心机制在 Oracle 11g 和 19c 之间没有颠覆性变化，但配置方式、默认行为、诊断能力和部分功能边界有实质性差异。直接升级或跨版本搭建时，不注意这些区别容易导致同步中断、备库无法接管、或误判故障原因。
db_create_file_dest 等隐式参数在 19c 中更严格
11g 允许 DB_CREATE_FILE_DEST 未设置时，通过显式指定 DATAFILE 路径创建数据文件；19c 在物理备库启用 REDO APPLY 期间，若该参数为空且未配 STANDBY_FILE_MANAGEMENT=AUTO，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 可能静默失败或报 ORA-01274（无法添加数据文件）。
- 11g 下即使漏配，有时靠主库传来的
CREATE DATAFILE语句也能“碰巧”成功 - 19c 默认更保守：必须确保
STANDBY_FILE_MANAGEMENT=AUTO且DB_CREATE_FILE_DEST指向有效 ASM 或文件系统路径 - 检查方法：
SHOW PARAMETER standby_file_management和SHOW PARAMETER db_create_file_dest
DGMGRL 的 BROKER 配置语法基本兼容，但校验逻辑增强
使用 DGMGRL 创建配置时，11g 对 LogXptMode、DelayMins 等属性的拼写容错较高；19c 在 EDIT DATABASE ... SET PROPERTY 阶段会提前校验值域合法性，例如将 LogXptMode='ASYNC' 写成 'ASYN' 会直接拒绝，而 11g 可能接受并后续出错。
- 19c 的
VALIDATE DATABASE命令返回更细粒度的WARNING（如 “Archive destination not configured on standby”），11g 多数只报ERROR或无提示 -
SHOW CONFIGURATION VERBOSE在 19c 中会显示Transport Lag和Apply Lag的实时估算值，11g 仅显示状态和最后更新时间 - 升级后务必运行
VALIDATE DATABASE <code>primary_db和VALIDATE DATABASE <code>standby_db，不能只依赖SHOW CONFIGURATION
备库 DML 自动重定向（19c 新增）不是默认开启，需显式配置
Oracle 19c 引入的 ADG DML redirection 功能，允许在 Active Data Guard 打开读写模式的会话中执行 UPDATE/INSERT，并自动转发到主库——但这不是 ALTER DATABASE OPEN READ ONLY 的默认行为，也**不依赖** LOG_ARCHIVE_DEST_n 的任何新参数。
- 必须在备库侧设置：
ALTER SYSTEM SET DG_BROKER_START=TRUE（Broker 启用前提） +ALTER SYSTEM SET ADG_REDIRECT_DML=TRUE - 该功能仅对通过
DBMS_SERVICE创建的、绑定到备库的服务生效；直连tnsnames.ora中的SERVICE_NAME不触发重定向 - 11g 完全不识别
ADG_REDIRECT_DML参数，设了会报ORA-00900 - 验证是否生效：在备库执行
UPDATE后查V$SESSION_CONNECT_INFO的REDIRECTED_FROM列是否为YES
闪回数据库与 Data Guard 的协同行为差异明显
11g 中主库执行 FLASHBACK DATABASE 后，物理备库不会自动同步到同一 SCN，必须手动重建或使用 REINSTATE；19c 在 Broker 管理下支持 FAILOVER TO SNAPSHOT STANDBY + FLASHBACK 组合，且备库可自动跟上主库闪回点（前提是启用了 REDO TRANSPORT 并且归档日志未被删除）。
- 关键前提：19c 要求主库
DB_FLASHBACK_RETENTION_TARGET≥ 备库最大Apply Lag，否则闪回后备库可能丢失中间日志 - 11g 下若主库闪回，备库
ARCHIVE_LAG_TARGET设置过小，极易出现GAP导致MRP进程挂起 - 19c 的
DGMGRL新增REINSTATE子命令，比 11g 的RECOVER MANAGED STANDBY DATABASE更安全，会自动跳过已应用的归档
真正容易被忽略的是：19c 的 VALIDATE DATABASE 输出里有一类 WARNING 显示 “Redo transport is enabled but no log archive destination is defined”，这在 11g 中往往被当成信息忽略，但在 19c 下它意味着备库无法接收新日志——哪怕你只用 SQL*Plus 手动 ALTER SYSTEM ARCHIVE LOG CURRENT，也可能因缺少 LOG_ARCHIVE_DEST_2 指向备库而失败。
