oracle data guard不同步ddl执行逻辑，仅重放物理块变更，导致分区表的全局索引维护、统计信息收集和interval分区元数据等操作在备库静默失效，需手动校验并修复dba_indexes.status、dba_tab_statistics.last_analyzed及dba_tab_partitions.high_value一致性。
分区表本身不触发Data Guard特殊行为，但元数据变更会绕过日志同步
Oracle Data Guard 同步的是物理块变化（redo），不是 DDL 语句。分区表的 ALTER TABLE ... SPLIT PARTITION、EXCHANGE PARTITION 等操作会产生大量物理变更，但关键问题是：某些元数据操作（如全局索引维护、统计信息自动收集触发的隐式 DDL）可能不生成完整 redo，或在备库上因对象状态不一致而静默失败。
GLOBAL INDEX 在主备库上容易出现 INVALID 状态
主库执行 ALTER TABLE ... DROP PARTITION UPDATE GLOBAL INDEXES 后，全局索引在主库上保持 VALID，但备库上的对应索引可能变为 INVALID —— 因为索引重建过程依赖本地临时段和并行度设置，而这些在备库是只读的，MRP 进程无法真正“重建”，只能标记为失效。
- 验证方式：
SELECT INDEX_NAME, STATUS FROM DBA_INDEXES WHERE TABLE_NAME = 'YOUR_PARTITIONED_TABLE' AND INDEX_TYPE = 'NORMAL'; - 根本原因：备库不执行 DDL 的执行计划阶段，只重放物理块变更；索引结构一致性校验由备库本地逻辑完成，但缺少主库当时的上下文（如 TEMP 表空间配额、并行进程数）
- 规避方法：避免在主库使用
UPDATE GLOBAL INDEXES，改用UPDATE INDEXES（仅更新局部索引）或手动分步重建全局索引
DBMS_STATS.AUTO_TASK 默认启用时，备库统计信息会滞后甚至错误
主库开启自动统计信息收集（DBMS_STATS.AUTO_TASK）后，其作业会在主库生成新统计信息并写入数据字典；这些变更通过 redo 传到备库，但备库处于 MOUNT 或 READ ONLY 状态，WRI$_OPTSTAT_TAB_HISTORY 等统计表无法被正常更新，导致 DBA_TAB_STATISTICS 显示陈旧值，甚至出现 STALE 或 NULL 的 LAST_ANALYZED。
- 典型现象：主库执行
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT','SALES')后，备库查DBA_TAB_STATISTICS中SALES表的NUM_ROWS仍为旧值 - 必须关闭备库端自动任务：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL); - 更稳妥做法：主库收集后，用
DBMS_STATS.EXPORT_SCHEMA_STATS+ Data Pump 导出/导入方式同步统计信息到备库
分区扩展（Interval Partitioning）新增分区时，备库可能卡在“applying archived log”
主库插入触发 interval 分区自动创建（如 INSERT INTO sales VALUES (DATE '2026-08-01', ...)），该操作本身可同步，但新增分区的元数据（DBA_TAB_PARTITIONS 新增行）需依赖完整的 dictionary redo 流。若主库归档日志中该事件被截断、或备库 MRP 进程版本较老（如 12.1.0.2 以前），就会停在 APPLYING ARCHIVED LOG 状态，且 V$MANAGED_STANDBY 中 PROCESS 列显示 MRP0 但 STATUS 为 WAIT_FOR_LOG。
- 检查点：
SELECT * FROM V$ARCHIVE_GAP;若有 gap，说明归档传输中断；若无 gap 但 MRP 不动，大概率是 interval 元数据解析失败 - 临时缓解：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;→ 手动注册缺失归档 → 重启 MRP - 长期建议：主库禁用 interval partition，改用显式
ADD PARTITION并在备库提前建好空分区（用DBMS_SCHEDULER定时同步）
分区表在 Data Guard 环境下最危险的盲区，是那些“看起来同步成功了”的元数据变更——它们不会报错，但会让备库在切换后立刻暴露查询性能骤降、索引失效、执行计划错乱等问题。真正要盯的不是 SQL 能不能跑，而是 DBA_INDEXES.STATUS、DBA_TAB_STATISTICS.LAST_ANALYZED、DBA_TAB_PARTITIONS.HIGH_VALUE 这三类字段是否与主库严格一致。
