SQL跟踪无法捕获LOGSTDBY跳过事务，因其发生在LSP0应用层而非SQL解析执行阶段；应查V$LOGSTDBY_SKIP（跳过规则）和V$LOGSTDBY_PROGRESS.SKIPPED_SCN（最近跳过SCN）。
SQL 跟踪开启后看不到 LOGSTDBY 跳过事务？检查 V$LOGSTDBY_SKIP 和 V$LOGSTDBY_PROGRESS
逻辑备库跳过的事务默认不会出现在 sql 跟踪（如 dbms_monitor 或 10046）里，因为跳过发生在应用层（lsp0 进程），压根没走到 sql 解析执行阶段。真要确认哪些事务被跳过，得直接查动态性能视图。
实操建议：
-
V$LOGSTDBY_SKIP显示当前配置的跳过规则（比如对某个 schema、PL/SQL 包、DDL 类型的忽略），不是实时跳过记录 -
V$LOGSTDBY_PROGRESS的SKIPPED_SCN字段才是关键——它表示最近一次跳过事务对应的 SCN，结合V$ARCHIVED_LOG可定位到具体归档日志位置 - 如果
SKIPPED_SCN > 0但V$LOGSTDBY_STATS里skipped_transactions为 0，大概率是跳过发生在初始化阶段（如构建备库时的 DDL），之后没再触发新跳过
用 DBMS_LOGSTDBY.SKIP 配置跳过时，为什么有些 DDL 还是报错？注意对象级 vs 语句级匹配
跳过规则不是“模糊匹配 SQL 文本”，而是按 Oracle 内部操作类型 + 对象名称精确匹配。比如你执行了 DBMS_LOGSTDBY.SKIP('DML', 'SCOTT', 'EMP%')，它只跳过对 EMP 开头表的 DML，对 CREATE TABLE EMP_BACKUP 这类 DDL 完全无效。
常见错误现象：备库报 ORA-01430: column being added already exists，但明明配了跳过 ALTER TABLE —— 实际上 SKIP 默认不覆盖 DDL，必须显式指定 'SCHEMA_DDL' 或 'TABLE_DDL' 操作类型。
实操建议：
- DDL 跳过必须用
DBMS_LOGSTDBY.SKIP('SCHEMA_DDL', 'SCOTT', NULL)，第三个参数为NULL表示跳过该 schema 所有 DDL - 跳过 PL/SQL 编译需单独加一条：
DBMS_LOGSTDBY.SKIP('PROCEDURE', 'SCOTT', '%')，否则CREATE OR REPLACE PROCEDURE仍会尝试编译并失败 - 修改跳过规则后，必须执行
DBMS_LOGSTDBY.UNSKIP清除旧规则，再EXEC DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 2)重启应用进程才生效
评估跳过事务影响：别只看 DBMS_LOGSTDBY.INSTANTIATE_TABLE，先确认主备数据一致性
INSTANTIATE_TABLE 是把主库某张表导出再导入备库，用来修复因跳过导致的数据偏差。但它本身不校验跳过是否已造成不一致——如果跳过的是中间状态的 DML（比如未提交的事务被跳过），表数据可能早已错位。
使用场景：你发现备库某张表查询结果和主库不一致，且确认近期有跳过发生。
实操建议：
- 先运行
DBMS_LOGSTDBY.CHECK_APPLY，它会扫描LOGSTDBY$EVENTS并返回最近 10 条跳过事件详情（含 SQL 文本、对象名、时间戳） - 对比主备两库的
SELECT ORA_HASH(COL1||COL2) FROM TBL（选关键列拼接哈希），比全量比对快得多，能快速定位是否真存在偏差 -
INSTANTIATE_TABLE必须在备库STOP APPLY后执行，且目标表不能有正在运行的 DML，否则报ORA-16127
开启 SQL 跟踪辅助诊断：只对 LSP0 进程有效，且需设置 _logstdby_trace_level
普通 ALTER SESSION SET EVENTS '10046 trace name context forever, level 12' 对逻辑备库事务跟踪基本无效，因为应用逻辑不在用户会话里。真正起作用的是 LSP0（Log Apply Services Process）后台进程。
性能与兼容性影响：开启高级别跟踪（level 12）会导致备库应用延迟显著上升，日志文件体积暴增，仅建议在问题复现窗口期内临时启用。
实操建议：
- 连接到备库实例，用
oradebug setospid <lsp0_pid></lsp0_pid>定位并 attach 到LSP0进程（可通过ps -ef | grep lsp0查 PID） - 执行
oradebug event 10046 trace name context forever, level 12，再oradebug tracefile_name查看输出路径 - 更轻量的方式是设置隐含参数：
ALTER SYSTEM SET "_logstdby_trace_level" = 16 SCOPE=BOTH（16 表示记录跳过决策日志，不含 SQL 绑定变量） - 跟踪文件里重点搜
skip transaction和apply skip字样，而不是找常规的PARSING IN CURSOR
跳过事务的评估难点不在工具怎么开，而在于跳过动作本身是异步发生的，且可能跨多个归档日志。最易被忽略的是：跳过规则一旦配置，会持续生效直到显式清除，哪怕主库后续不再发这类语句——没人会去定期 audit V$LOGSTDBY_SKIP 是否还合理。
