三分球大赛ogg抽取条数峰值
一般来说OGG Goldengate 抽取进程对CPU的压力非常小， 而对于I/O 、network的吞吐量有轻量级的要求。
用低配置AIX测试结果如下。
抽取进程支持DB Log生成峰值速度 = 4 * 2.1 = .4 /秒，或30GB/小时，或726 GB/天。
抽取进程平均CPU占用1.9% 。
投递进程支持DB Log生成平均速度 = 2,096,54 * 2.1 = 4.5 /秒，或16 GB/小时，或30 GB/天。
如何煮饺子投递进程平均CPU占用7% 。
对于Extract抽取日志缓慢导致延迟的问题，优先采用如下方法诊断具体慢在 抽取 还是 写trail上：
1. 收集原始慢的Extract的性能息
关于童年趣事的作文
GGSCI> stats extract <extract_name>, totalsonly *, reportrate c
雍正儿子GGSCI> stats extract <extract_name>, totalsonly *, reportrate min
2. 创建一个新的extract 参数文件
cp <extract_name>.prm ETEST.prm
3. 修改上述 e params file中的extract名字 和 trail 位置
4. 加入TESTMEED 参数到 e的params files
TESTMEED参数的作用是 不让extract 去写trail 文件 而仅仅抽取日志， 若加入该参数后抽取速度大幅提升则说明性能瓶颈在 write trail上
TESTMEED
REPORTCOUNT EVERY 5000 RECORDS
5. 增加e这个extract
GGSCI> add extract e, tranlog, begin now
GGSCI> add exttrail ./dirdat/ma , extract e , megabytes 200
6. 为e指定 原始extract 存在抽取速度问题的archivelog 的quence
GGSCI> alter extract e, extqno <arch_q_no>, extrba 0
小学六年级数学下册7. 启动e 这个extract
GGSCI> start extract e
等待5分钟并检查
GGSCI> stats extract e, totalsonly *, reportrate c
GGSCI> stats extract e, totalsonly *, reportrate min
对比 原始慢的extract 与 新加入的e的 stats reportrate 报告中的性能指标，若 TESTMEED 后 性能明显提升则说明问题出在 写trail (extract 写到本地的情况) 或者 网络传出慢( 直接写
经典文章到目标机上)。
如果TESTMEED 后性能也无明显变化则继续。
. 将所有extract 的表都注释掉，而仅仅extract 一张很少变化记录的表， 若这样 后性能明显提升则说明 瓶颈不在读archivelog 上而在 日志记录的处理上 log record processing 。
一般来说redo日志的解析分成2部分：
A. Record parsing in Extract
室内消防栓B. Record fetching if needed
9.为了进一步确认问题 将TESTMEED 注释掉， 并 加入 TRACE/TRACE2 参数 以便确认 Extract是否慢在fetch上
TRACE ./
TRACE2 ./2
10 检查生成的trace 文件 若 其中显示 大量的时间耗费在一些SELECT语句上，则需要DBA介入来调优这些SELECT SQL
11. 若看到一些与undo/rollback 相关的错误例如ORA-1555则确保UNDO 表空间可用 空间足够， 也可以加入 FETCHOPTI NOUSESNAPSHOT 让 Extract fetch column 数据是尽可能不要走UNDO CR READ
12. 如果将大部分表都去掉，只剩下一个不太用的表且仍无明显的性能增长， 且CPU 也不忙， 一般来说这可能是IO瓶颈造成的
13. 建议dd测一下archivelog 的读取速度
例如maclean>time dd if=<归档日志> of=/dev/null bs=1M
对比其他磁盘若有明显差异， 则考虑将archivelog 移动到对应磁盘并再次上述测试。
对于cache较小的quence 可以引起在replicat DDL 时频繁执行 ALTER SEQUENCE “SEQ_NAME” CYCLE的DDL语句：
高能所邮箱若该replicat target库上尚有extract则 extract挖掘日志时可能因为处理频繁的DDL操作而变得很慢，”Why GoldenGate replicat issues “alter quence .. cycle|nocycle” in quence replication? [ID .1]” 文档指出了 这种频繁的 是为了在target 上上可赖的同步quence的高水位。
但是这种超频繁的 几乎每2s 一次的ALTER SEQUENCE CYCLE操作确实拖慢了Extract的速度， 可以通过指定参数 DBOPTI _NOAUTOMATICSEQUENCEFLUSH来减少ALTER SEQUENCE CYCLE出现，实际并不能完全避免。 文档指出使用该 DBOPTI _NOAUTOMATICSEQUENCEFLUSH参数可能导致TARGET上的SEQUENCE 不同步。
实际优先考虑增加SOURCE上SEQUENCE的CACHE解决问题， 之后再考虑用 DBOPTI _NOAUTOMATICSEQUENCEFLUSH； 针对该SEQUENCE 在EXTRACT里 排除该索引 没有效果， 例如 DDL EXCLUDE OBJNAME “XX.SEQNAME” 或者 TAEEXCLUDE “XX.SEQUENCE”在实际测试中均没有明显的改善， 但修改DBOPTI _NOAUTOMATICSEQUENCEFLUSH确实可以该少性能。
