ITPub博客

首页 > 数据库 > Oracle > goldengate抽取进程延迟90小时

goldengate抽取进程延迟90小时

原创 Oracle 作者:xueshancheng 时间:2021-11-19 16:57:34 0 删除 编辑

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69996316/viewspace-2843171/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
本人目前就职于北京海天起点技术服务有限股份公司,从事Oracle数据库有十几年了,对Oracle及goldengate比较精通。

注册时间:2021-03-11

  • 博文量
    44
  • 访问量
    13123