1 某业务系统OGG的抽取进程有延迟，最严重时有88小时的延迟，以下为延迟截图

2  goldengate的抽取进程延迟，一般有如下原因。

2.1 查看系统的cpu负载是否过高

2.2 查看系统的内存负载是否过高

2.3 查看系统的io负载是否过高

2.4 验证存储的io压力是否过高

2.5 查看OGG的参数文件，是否有设置不合理的

2.6 查看OGG的日志及报告，是否有报错

2.7 生成trace文件，查看trace文件是否有明显的ORA错误或其他问题

2.8 生成pstack文件，查看是否有明显的报错

2.9 查看oracle官方文档，查看是否有有用的信息。

3  经过验证，CPU，内存，参数文件已经进行排除，认为没有任何问题。

4  查看抽取进程的日志状态，发现读取日志时等待的比较多，如下

5 对goldengate的抽取进程做trace,发现时间都发生在读取redo日志上。

对抽取进程进行trace

send EXTXX,trace ./dirtmp/EXTXX_20211104.trc

GGSCI (xxxtdb3) 3> send EXTXX,trace ./dirtmp/EXTXX_20211104.trc              

Sending trace request to EXTRACT EXTXX ...

Trace file /goldengate/dirtmp/EXTXX_20211104.trc opened.

等待10分钟后，关闭trace

send EXTXX,trace off

GGSCI (xxxtdb3) 4> send EXTXX,trace off

Sending trace request to EXTRACT EXTXX ...

Closing all trace files..

查看生成报告的汇总，发现抽取进程延迟耗费的时间主要在读取redo日志，即表示读取日志慢，导致OGG抽取进程延迟：

09:29:30.193 (5913587390) IPC_read from xxxtdb3:30720

SUMMARY STATISTICS

General statistics:

 0.00% Checking messages (includes checkpointing)

      0.00% Checking periodic tasks

 0.00% Waiting for more data

 0.00% Converting ASCII header to internal

 0.00% Converting ASCII data to internal

 0.01% Reading input records

 0.00% Writing output records (replicate_io)

      0.00% Mapping columns

      0.00% Outputting data records

      0.00% Performing SQL statements

 0.00% Performing BATCHSQL statements

 0.00% Performing actual DB op

 0.00% Preparing SQL statements

 0.00% Performing transaction commits

 0.00% Checkpointing

Redo log statistics:

 0.00% Opening redo log file

 0.00% Positioning into redo log file

100.00% Reading record from redo log file

 0.00% Extracting subrecord from redo record

      0.00% Extracting start subrecord

      0.00% Extracting undo subrecord header

      0.00% Extracting undo subrecord

      0.00% Extracting redo subrecord header

      0.00% Extracting undo subrecord

      0.00% Extracting rollback subrecord

      0.00% Extracting commit subrecord

 0.00% Processing start subrecord

 0.00% Processing data subrecord

 0.00% Processing rollback subrecord

 0.00% Processing commit subrecord

 0.00% Retrieving and processing transaction items

      0.00% Retrieving transaction item

      0.00% Formatting output record

            0.00% Formatting output record header

            0.00% Validating update key data

            0.00% Formatting output record data

                  0.00% Converting Oracle data to ASCII

 0.00% Close redo log

6  查看生成的trail的数量，发现抽取的数据不多。

[oracle@xxxtdb3 cj2]$ ls -ltr

total 652448

-rw-rw-rw- 1 oracle oinstall 199999350 Nov  4 09:17 cj041005

-rw-rw-rw- 1 oracle oinstall 199999457 Nov  4 09:46 cj041006

-rw-rw-rw- 1 oracle oinstall 171558015 Nov  4 09:59 cj041007

7   查看数据库日志的情况，发现每日的日志两最低在3T，最多达到8T。在业务高峰，几天的日志量有几十T，数据量特别大。

redo日志的大小2G

8 经查，发现在另外一个节点又部署了17个OGG抽取进程

9  原因分析

   由于此系统业务繁忙，每日归档量在3T到8T之间。总共又21个抽取进程，在业务最繁忙的时间，每日归档量达到8T，21*8=168T的数据，21个OGG抽取进程相互争用，导致OGG的抽取进程的时间都花费在读取归档日志上，最终导致抽取进程延迟大。幸亏此系统使用的为海天的分布式存储，IO性能极好，要不然OGG的延迟就不是88小时，有可能达到1000小时以上。故再次说明系统硬件极好的情况下，如果架构有问题，也会极大的降级系统的性能，还需要专业的人员进行根本原因分析。此问题有代表性，全国的这个行业都是这个架构，需要进行优化。

10 解决方法

     将所有的抽取进程合并成一个，解决IO争用问题。此问题的解决文档，在下一篇文档中解决。

以下为合理的OGG架构模式，即一个抽取进程，多个投递进程。来源于Oracle的官方文档：