今天在做压力测试的时候，不得以在primary上的某个用户表做2000千万条记录的大update操作，等了将近20分钟，不能返回结果，再一看logical standby节点开始出现GAP，real-time apply变得很慢，不用说肯定是这个大的update操作引起的。

观察logstdby上的alert日志发现，从primary上传过来的redolog，解析的时间很长(平时正常时间也就1分钟左右)，超过30分钟。查看dba_logstdby_events里的等待事件也能发现最新的events就是这个表的update操作。

没办法，只好还没commit的情况下就"Ctrl+C"掐断primary上的update操作，再看看logical standby上面的回滚操作的apply也依然很慢，GAP越来越多。Primary上的压力测试还得继续进行下去，为了不影响其他部分的压力实施，只能在standby这边将这个表skip掉。

10gR2的联机文档里找到了关于logical standby上的SKIP TABLE的REF，照着执行，解决了这个大的update操作引起的GAP问题。步骤如下：

第1步，停掉logical standby上的sql apply

ALTER DATABASE STOP LOGICAL STANDBY APPLY;

第2步，SKIP掉制定表的所有DDL、DML操作。这里需要用到DBMS_LOGSTDBY.SKIP包.

EXECUTE DBMS_LOGSTDBY.SKIP('SCHEMA_DDL', 'OWNER','TABLE_NAME');

EXECUTE DBMS_LOGSTDBY.SKIP('DML', 'OWNER','TABLE_NAME');

第3步，重新开始standby上的sql apply(real-time apply)

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;