OGG经典抽取模式读取redo慢的检查步骤，可以采用以下几个步骤来排查。
步骤一，确认是否抽取进程的写入有问题
1. 在原有抽取进程上，执行如下命令，统计抽取进程的效率
GGSCI> stats extract <extract_name>, totalsonly *, reportrate sec
GGSCI> stats extract <extract_name>, totalsonly *, reportrate min
2. 拷贝该进程的参数为另一个参数文件，如etest.prm
3. 修改etest.prm中的相关信息
4. 添加如下2行到etest参数文件中
TESTMAPPINGSPEED
REPORTCOUNT EVERY 5000 RECORDS
5. 添加etest进程
GGSCI> add extract etest, tranlog, begin now
修改进程从慢的位置开始读取，比如从读取慢的某个归档开始
GGSCI>alter extract etest, extseqno <arch_seq_no>, extrba 0
6. 启动etest进程
GGSCI>start etest
7. 等几分钟后，再做一次抽取效率统计
GGSCI> stats extract etest, totalsonly *, reportrate sec
GGSCI> stats extract etest, totalsonly *, reportrate min
如果统计结果与前面的结果有明显差异，说明抽取进程写入队列文件很慢，需要检查写入磁盘的IO。
如果抽取效率变化不大，则继续排查。
步骤二，确认是否使用了fetch造成读取DB慢
8. 修改etest进程，注释掉所有表的抽取，只保留或添加一张变化量很小的测试表；
如果性能有明显提升，则说明问题是在日志处理上。OGG解析日志有两部分工作，一个是直接解析日志，另一个是从DB中获取(fetch)需要的数据。
为了确认是否从DB获取造成性能下降，修改etest为如下:
--TESTMAPPINGSPEED
TRACE ./dirtmp/ext.trc
TRACE2 ./dirtmp/ext.trc2
使用alter etest，使其仍然从前面测试的开始点去读取，运行一段时间后，检查ext.trc, ext.trc2，查看里面是否有select语句，这些select语句是否执行时间很长，如果是，则表明从DB获取数据消耗太多时间，需要由DBA来检查DB是否需要优化。
另外，如果在DB日志中有提示undo空间超时或snapshot错误，则在抽取进程中添加FETCHOPTIONS NOUSESNAPSHOT,要求ogg extract从DB获取数据，而不是snapshot。
步骤三，系统硬件排查
9. 如果只保留一张表，性能仍然没有提升，在CPU、内存没有问题的情况，极有可能是因为DB日志对应的磁盘IO不行。可以使用dd命令来测试一下磁盘的读写性能。