优化Extract抽取进程性能，解决OGG抽取日志延迟

最新推荐文章于 2025-01-05 10:42:51 发布

转载最新推荐文章于 2025-01-05 10:42:51 发布 · 7.3k 阅读

goldengate 专栏收录该内容

21 篇文章

订阅专栏

一般来说OGG Goldengate 抽取进程对CPU的压力非常小，而对于I/O 、network的吞吐量有轻量级的要求。

用低配置AIX测试结果如下。

抽取进程支持DB Log生成峰值速度 = 4 * 2.1 = 8.4 MB/秒，或30GB/小时，或726 GB/天。
抽取进程平均CPU占用1.9% 。

投递进程支持DB Log生成平均速度 = 2,096,854 * 2.1 = 4.5 MB/秒，或16 GB/小时，或380 GB/天。
投递进程平均CPU占用7% 。

对于Extract抽取日志缓慢导致延迟的问题，优先采用如下方法诊断具体慢在抽取还是写trail上：

1. 收集原始慢的Extract的性能信息

GGSCI> stats extract <extract_name>, totalsonly *, reportrate sec
GGSCI> stats extract <extract_name>, totalsonly *, reportrate min

2. 创建一个新的extract 参数文件

cp <extract_name>.prm ETEST.prm

3. 修改上述 etest params file中的extract名字和 trail 位置

4. 加入TESTMAPPINGSPEED 参数到 etest的params files

TESTMAPPINGSPEED参数的作用是不让extract 去写trail 文件而仅仅抽取日志，若加入该参数后抽取速度大幅提升则说明性能瓶颈在 write trail上

TESTMAPPINGSPEED
REPORTCOUNT EVERY 5000 RECORDS

5. 增加etest这个extract

GGSCI> add extract etest, tranlog, begin now

GGSCI> add exttrail ./dirdat/ma , extract etest , megabytes 200

6. 为etest指定原始extract 存在抽取速度问题的archivelog 的sequence

GGSCI> alter extract etest, extseqno <arch_seq_no>, extrba 0

7. 启动etest 这个extract

GGSCI> start extract etest

等待5分钟并检查

GGSCI> stats extract etest, totalsonly *, reportrate sec
GGSCI> stats extract etest, totalsonly *, reportrate min

对比原始慢的extract 与新加入的etest的 stats reportrate 报告中的性能指标，若 TESTMAPPINGSPEED 后性能明显提升则说明问题出在写trail (extract 写到本地的情况) 或者网络传出慢( 直接写到目标机上)。

如果TESTMAPPINGSPEED 后性能也无明显变化则继续。

8. 将所有extract 的表都注释掉，而仅仅extract 一张很少变化记录的表，若这样后性能明显提升则说明瓶颈不在读archivelog 上而在日志记录的处理上 log record processing 。

一般来说redo日志的解析分成2部分：

A. Record parsing in Extract
B. Record fetching if needed

9.为了进一步确认问题将TESTMAPPINGSPEED 注释掉，并加入 TRACE/TRACE2 参数以便确认 Extract是否慢在fetch上

–TESTMAPPINGSPEED http://www.askmaclean.com
TRACE ./dirtmp/ext.trc
TRACE2 ./dirtmp/ext.trc2

10 检查生成的trace 文件若其中显示大量的时间耗费在一些SELECT语句上，则需要DBA介入来调优这些SELECT SQL

11. 若看到一些与undo/rollback 相关的错误例如ORA-1555则确保UNDO 表空间可用空间足够，也可以加入 FETCHOPTIONS NOUSESNAPSHOT 让 Extract fetch column 数据是尽可能不要走UNDO CR READ

12. 如果将大部分表都去掉，只剩下一个不太用的表且仍无明显的性能增长，且CPU 也不忙，一般来说这可能是IO瓶颈造成的

13. 建议dd测一下archivelog 的读取速度

例如maclean>time dd if=<归档日志> of=/dev/null bs=1M

对比其他磁盘若有明显差异，则考虑将archivelog 移动到对应磁盘并再次上述测试。

对于cache较小的sequence 可以引起在replicat DDL 时频繁执行 ALTER SEQUENCE “SEQ_NAME” CYCLE的DDL语句：

2013-04-22 09:54:06  INFO    OGG-01487  DDL found, operation [ALTER SEQUENCE "TXN_SEQ" CYCLE  (size 31)], start SCN [20181621217], commit SCN [20181621231] instance [C
ULPRODB (1)], DDL seqno [2734821], marker seqno [2736076].

2013-04-22 09:54:06  INFO    OGG-00487  DDL operation included [Include Mapped], optype [ALTER], objtype [SEQUENCE], objowner [OLSUSER], objname [TXN_SEQ].

2013-04-22 09:54:06  INFO    OGG-00497  Writing DDL operation to extract trail file.
Wildcard SEQUENCE resolved (entry olsuser.*):
  Sequence "OLSUSER"."TXN_SEQ";
Resolving source sequence OLSUSER.TXN_SEQ.

2013-04-22 09:54:07  INFO    OGG-01487  DDL found, operation [ALTER SEQUENCE "TXN_SEQ" CYCLE  (size 31)], start SCN [20181621236], commit SCN [20181621248] instance [C
ULPRODB (1)], DDL seqno [2734822], marker seqno [2736077].

2013-04-22 09:54:07  INFO    OGG-00487  DDL operation included [Include Mapped], optype [ALTER], objtype [SEQUENCE], objowner [OLSUSER], objname [TXN_SEQ].

2013-04-22 09:54:07  INFO    OGG-00497  Writing DDL operation to extract trail file.
Wildcard SEQUENCE resolved (entry olsuser.*):
  Sequence "OLSUSER"."TXN_SEQ";
Resolving source sequence OLSUSER.TXN_SEQ.

2013-04-22 09:54:08  INFO    OGG-01487  DDL found, operation [ALTER SEQUENCE "TXN_SEQ" CYCLE  (size 31)], start SCN [20181621251], commit SCN [20181621261] instance [C
ULPRODB (1)], DDL seqno [2734823], marker seqno [2736078].

2013-04-22 09:54:08  INFO    OGG-00487  DDL operation included [Include Mapped], optype [ALTER], objtype [SEQUENCE], objowner [OLSUSER], objname [TXN_SEQ].

2013-04-22 09:54:08  INFO    OGG-00497  Writing DDL operation to extract trail file.
Wildcard SEQUENCE resolved (entry olsuser.*):
  Sequence "OLSUSER"."TXN_SEQ";
Resolving source sequence OLSUSER.TXN_SEQ.

若该replicat target库上尚有extract则 extract挖掘日志时可能因为处理频繁的DDL操作而变得很慢，”Why GoldenGate replicat issues “alter sequence .. cycle|nocycle” in sequence replication? [ID 1535322.1]” 文档指出了这种频繁的是为了在target 上上可信赖的同步sequence的高水位。

但是这种超频繁的几乎每2s 一次的ALTER SEQUENCE CYCLE操作确实拖慢了Extract的速度，可以通过指定参数 DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH来减少ALTER SEQUENCE CYCLE出现，实际并不能完全避免。文档指出使用该 DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH参数可能导致TARGET上的SEQUENCE 不同步。

实际优先考虑增加SOURCE上SEQUENCE的CACHE解决问题，之后再考虑用 DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH；针对该SEQUENCE 在EXTRACT里排除该索引没有效果，例如 DDL EXCLUDE OBJNAME “XX.SEQNAME” 或者 TABLEEXCLUDE “XX.SEQUENCE”在实际测试中均没有明显的改善，但修改DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH确实可以该少性能。

http://www.askmaclean.com/archives/ogg-goldengate-extract-slow.html