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执行的效率。通过重建表、移动表空间等降级水位线的做法后，有时性能提升能达到几千倍。