Goldengate性能优化之优化Extract抽取进程性能 解决OGG抽取日志延迟
2014-11-10 11:45
288 查看
一般来说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 移动到对应磁盘并再次上述测试。
本文转自:http://www.it165.net/database/html/201304/3797.html
联系邮箱:qrcg92@foxmail.com
一般来说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 移动到对应磁盘并再次上述测试。
本文转自:http://www.it165.net/database/html/201304/3797.html
联系邮箱:qrcg92@foxmail.com
相关文章推荐
- 【Goldengate性能优化】优化Extract抽取进程性能,解决OGG抽取日志延迟
- 【Goldengate性能优化】优化Extract抽取进程性能,解决OGG抽取日志延迟
- 【Goldengate性能优化】优化Extract抽取进程性能,解决OGG抽取日志延迟
- 优化Extract抽取进程性能,解决OGG抽取日志延迟
- OGG_GoldenGate数据控制进程Manager(案例)
- ogg修改extract进程从当前抽取
- GoldenGate进程 abend,报错为OGG-00868 ORA-02396: Exceeded Maximum Idle Time, Please Connect Again
- Java性能分析及问题解决(二)jvm致命错误导致进程直接挂掉,错误日志分析及解决
- ogg修改extract进程从当前抽取
- GoldenGate 配置extract,replicat进程自启动
- 一次ogg extract抽取进程异常abending问题处理OGG-00446
- goldengate for sqlserver 日志暴涨的解决办法 转
- goldengate for sqlserver 日志暴涨的解决办法
- 数据库复习日志 oracle 10g 数据库性能优化的调整 1
- Linux全攻略--系统性能、进程监控和日志管理
- Goldengate单向大事务复制性能测试
- 构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)―托管资源优化―监测CLR性能
- ASP.NET性能提升秘诀之管道与进程优化
- IIS 网站日志时间延迟及解决方法
- Java 性能优化 - Websphere GC日志分析