高水位线导致OGG延迟过长

1 OGG 进程状态：   REPLICAT    RUNNING     REPSC    00:00:00      39:40:22   GGSCI (host_A) 11> ! info REPSC   REPLICAT   REPSC  Last Started 2022-08-27 00:23   Status RUNNING Checkpoint Lag       00:00:00 (updated 39:39:57 ago) Log Read Checkpoint  File ./dirdat/sc012709                       2022-08-25 09:02:17.000868  RBA 157764828   2 查看 OGG 进程执行的 SQL     3 查看执行计划，发现走的是全表扫描，这有可能是有问题的，执行时间为1秒。   根据如下信息，可以确定每次执行耗费的逻辑读为 862173,   4 查看真实的执行时间，为2秒   5 查看表中的数据，发现为0.这明显是有问题的，既然表中的数据为0行，按理执行的SQL应该在2毫秒以下，但实际执行为2秒以上，相差了1000倍。   于是查看表占用的空间大小，为 6757M，如下图： select OWNER,SEGMENT_NAME,SEGMENT_TYPE,trunc(sum(BYTES)/1024/1024) from dba_segments  where owner='USER_A' and SEGMENT_NAME in ('TABLE_A') group by OWNER,SEGMENT_NAME,SEGMENT_TYPE order by SEGMENT_TYPE,trunc(sum(BYTES)/1024/1024) ;            这明显是由于表的高水位线太高，导致扫描空数据块导致的。 7  truncate表，降级表的高水位线，验证SQL性能 Truncate表：   表的占用的空间：   查看真实的执行时间，为 0秒   比对相同时间执行的 SQL条数，性能相差了5824倍。 SYS@host_A >select 9581505/1645 from dual;   9581505/1645 ------------     5824.6231 查看执行计划耗费的资源，其中逻辑读为 1   总结：        根据如上信息，当表执行了太多 DML操作，导致数据库里空块太多，且水位线高时，导致数据库扫描了许多空块，从而降级了SQL执行的效率。通过重建表、移动表空间等降级水位线的做法后，有时性能提升能达到几千倍。