goldengate的extract进程调优

How To Troubleshoot Oracle Redo Log Reading Extract Slow Performance Issue using TESTMAPPINGSPEED [ID 1273285.1]

如果 extract进程比较缓慢，应该先判断是慢在抽取上还是写 trail文件上，采用如下思路：

1  

先收集当前extract性能信息，创建一个只抽取不写trail的extract，测试是否慢在抽取日志；

2

更改当前extract设置，只读取更新比较小的表，测试是否依旧很慢，如果慢则查看IO性能；

具体操作：

1

收集当前extract性能信息

GGSCI> stats extract , totalsonly *, reportrate sec

GGSCI> stats extract , totalsonly *, reportrate min

创建新的extract

cp .prm ETEST.prm

修改extract/trail内容，并加入testmappingspeed参数，即只抽取日志而不写trail

TESTMAPPINGSPEED

REPORTCOUNT EVERY 5000 RECORDS

启动该进程

GGSCI> add extract etest, tranlog, begin now

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

GGSCI> alter extract etest, extseqno , extrba 0 --指定存在问题的 archivelog

GGSCI> start extract etest

运行5分钟查看性能信息

GGSCI> stats extract etest, totalsonly *, reportrate sec

GGSCI> stats extract etest, totalsonly *, reportrate min

对比两者对比信息，如果性能有明显提升则问题出在写trail或者网络传输上

如果还是很慢则继续下一步

2

将所有extract的表注释，仅保留一张很少变化的表，如果性能提升说明瓶颈不在读archivelog，而在日志处理上

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

A. Record parsing in Extract

B. Record fetching if needed

将testmappingspeed去除，添加trace/trace2

–TESTMAPPINGSPEED

TRACE ./dirtmp/ext.trc

TRACE2 ./dirtmp/ext.trc2

检查生成的trace，如果耗时在select则需要DBA调优，如果undo/rollback相关可加入fetchoptions nousesnapshot尽可能不undo cr read；

如果此时依旧很慢，可能IO瓶颈；

dd测试archivelog读取速度

time dd if= f=/dev/null bs=1M

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

转载于:http://blog.itpub.net/15480802/viewspace-760889/