goldengate抽取进程延迟90小时

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 -ltrtotal 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的官方文档：