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命令來測試一下磁碟的讀寫效能。