oracle 11g逻辑备库不支持表级过滤，因其设计目标是全库逻辑一致性，依赖logminer按事务顺序重放所有未被dba_logstdby_unsupported排除的表；dbms_logstdby.skip仅支持跳过dml/ddl等操作类型，不能直接按表名过滤，且skip规则不持久化，重启后需重执行。
oracle 11g 的逻辑备库（logical standby）本身不支持表级过滤——dbms_logstdby 没有提供类似 skip 或 include 表列表的内置参数，也不能在 sql apply 阶段动态跳过某些表的 dml 解析与执行。
为什么逻辑备库不能直接做表级过滤？
逻辑备库依赖 LogMiner 解析重做日志生成 SQL，并按事务顺序重放。它的设计目标是“全库逻辑一致性”，不是“选择性同步”。所有被主库归档且未被 dba_logstdby_unsupported 排除的表，都会参与 SQL Apply 流程。
-
DBMS_LOGSTDBY.SKIP和DBMS_LOGSTDBY.SKIP_PROCEDURE只能跳过特定对象类型（如包、过程、序列），不能按表名或 schema 过滤 DML - 即使你在主库对某张表做了
NOLOGGING，只要它没进dba_logstdby_unsupported列表，逻辑备库仍会尝试解析其变更（失败后报错并暂停应用） - 修改
LOG_ARCHIVE_DEST_n参数或归档路径，只影响日志传输位置，不影响 SQL Apply 的对象范围
绕过限制的可行方案：用 SKIP 规则 + 不支持对象标记
真正能落地的“表级过滤”，本质是让目标表**不进入 SQL Apply 流程**。只有两种路径可靠：
- 把要过滤的表加入
dba_logstdby_unsupported——但前提是该表含逻辑备库明确不支持的数据类型（如BFILE、VARRAY、XMLType等）。强行加字段会破坏主库业务，不可取 - 用
DBMS_LOGSTDBY.SKIP显式跳过该表的 DML：需在逻辑备库处于MOUNT状态、SQL Apply 未启动前执行
示例（跳过 SCOTT.EMP）：
EXEC DBMS_LOGSTDBY.SKIP( stmt => 'DML', schema => 'SCOTT', name => 'EMP', use_like => FALSE );
注意：use_like => FALSE 表示精确匹配表名；若设为 TRUE，name 支持通配符（如 'EMP%'），但易误伤
SKIP 后必须验证的三个关键点
跳过表后，逻辑备库不会报错退出，但容易埋下隐患：
- 跳过的表在逻辑备库上**仍存在结构（DDL 已同步）**，但数据永远停滞——后续主库对该表的任何 DML 都被忽略，不会写入 alert 日志，也不会中断 SQL Apply
- 如果该表被其他表通过外键引用，而你又没跳过关联表，SQL Apply 可能因约束冲突失败（如主库插入子表记录，父表被跳过导致找不到主键）
-
DBA_LOGSTDBY_SKIP视图可查当前所有 SKIP 规则，但规则**不持久化到控制文件**：重启逻辑备库后需重新执行SKIP（建议写入启动脚本）
比 SKIP 更稳妥的替代思路：用物理备库 + 备库侧 LogMiner 解析
如果你的真实需求是“只同步部分表给下游系统”，逻辑备库不是最优解。更健壮的做法是：
- 保持物理备库正常运行（保障 RPO/RTO）
- 另起一个独立进程（如 CloudCanal、OGG 或自研工具），连接到物理备库，基于其归档日志 + LogMiner 字典做增量解析
- 在解析层做表过滤（例如只订阅
SCOTT.DEPT和HR.EMPLOYEES），再投递到目标端
这样既不干扰 DataGuard 主备链路，又能灵活控制同步粒度，还避免了逻辑备库对主键/唯一约束的强依赖问题。
真正的难点不在怎么写 SKIP 命令，而在于跳过一张表后，整个逻辑备库的事务一致性边界就变了——它不再是主库的逻辑镜像，而是一个定制视图。这种偏离必须被明确记录、持续监控，否则一次主库 DDL 变更就可能让备库 SQL Apply 卡死数小时。
