逻辑备库未同步DDL的主因是SKIP规则缺失或失效、对象结构不兼容（如DBA_LOGSTDBY_UNSUPPORTED中标记的表）、补充日志未启用或GLOBAL_NAMES参数导致LogMiner字典构建失败。
逻辑备库没同步DDL，大概率是没配LOGSTDBY$SKIP或跳过规则失效
逻辑备库（Logical Standby）默认对DDL非常保守，不是所有DDL都能自动重放。主库执行了CREATE TABLE或ALTER INDEX，备库却没反应，常见原因不是同步断了，而是SQL Apply进程压根没尝试执行——它在解析redo时发现该DDL未被显式允许，直接跳过或挂起。
必须检查DBA_LOGSTDBY_SKIP视图是否覆盖了目标对象类型：
-
STATEMENT_OPT = 'DML'只管DML，对DDL无效；要让DDL通过，得有对应STATEMENT_OPT IN ('CREATE', 'ALTER', 'DROP')的记录 - 若用
SCHEMA = 'HR'匹配，但DDL里含双引号标识符（如"My_Table"），可能因大小写/引号不匹配导致规则失效 - 新增的DDL类型（如19c引入的
CREATE ATTRIBUTE DIMENSION）不会被旧版skip规则覆盖，需手动补录
DBA_LOGSTDBY_UNSUPPORTED里有表，但DDL还在跑，结果就是静默失败
逻辑备库对某些数据类型或对象结构根本不支持SQL Apply，比如含XMLTYPE列的表、使用ROWID伪列的视图、或带函数索引的表。这些信息会记入DBA_LOGSTDBY_UNSUPPORTED，但注意：这个视图只反映“建表时”的不兼容性，不拦截后续对该表的ALTER操作。
典型现象是：主库ALTER TABLE t ADD COLUMN x CLOB成功，备库日志里既无报错也无应用痕迹——因为CLOB本身支持，但该表之前已在DBA_LOGSTDBY_UNSUPPORTED中标记为“不可用”，SQL Apply直接忽略整张表的所有变更。
验证方法：
- 查
SELECT owner, table_name FROM dba_logstdby_unsupported WHERE data_type = 'CLOB'，确认是否命中 - 执行
EXEC DBMS_LOGSTDBY.CHECK_UPGRADE('HR', 'EMPLOYEES')，看返回是否含CAPABLE_FLAG = 'N' - 别依赖
DBA_LOGSTDBY_EVENTS——它只记严重错误，这种静默跳过不写事件
主库没开补充日志，UPDATE/DELETE类DDL间接失效
像ALTER TABLE ... MODIFY CONSTRAINT ... ENABLE VALIDATE这类操作，底层会触发全表扫描+行级校验，产生大量UPDATE redo。如果主库没开ALTER DATABASE ADD SUPPLEMENTAL LOG DATA，SQL Apply就无法还原出完整的前镜像（before image），导致校验失败后整个事务被丢弃——看起来像“DDL没同步”，实则是依赖它的DML卡住了。
关键点：
-
V$DATABASE.SUPPLEMENTAL_LOG_DATA_MIN必须为YES，仅靠ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY)不够 - RAC环境要确认所有实例都生效：
SELECT inst_id, supplemental_log_data_min FROM gv$database - 开了补充日志后，
DBMS_LOGSTDBY.BUILD必须重跑一次，否则LogMiner字典仍按旧规则解析
备库GLOBAL_NAMES = TRUE导致LogMiner字典构建失败
19c备库启动SQL Apply前，必须先构建LogMiner字典，而这个过程依赖数据库链接（DB Link）访问主库字典。如果主库GLOBAL_NAMES = FALSE（11g默认值），但19c备库设为TRUE，则DB Link名称必须严格等于全局数据库名（DB_NAME.DB_DOMAIN）。一旦不匹配，DBMS_LOGSTDBY.BUILD在备库侧调用时会静默失败，后续所有DDL解析都缺元数据支撑。
检查与修复：
- 查两边：
SHOW PARAMETER global_names，确保备库也是FALSE - 改完参数后重启备库实例，不能只
ALTER SYSTEM，否则V$DATABASE里仍显示旧值 - 重建字典前先清空
SYSTEM.LOGMNR_UID$和SYSTEM.LOGMNR_SESSION$（需SYS权限），避免残留缓存干扰
逻辑备库的DDL同步不是“开了就能用”，而是每条语句都要过三关：skip规则放行、对象结构兼容、字典元数据就位。最容易被忽略的是GLOBAL_NAMES和LogMiner字典的耦合关系——参数改了，实例没重启，字典还是旧的，问题就藏在那儿不动声色。
