goldengate抽取程式延遲90小時

1 某業務系統OGG的抽取程式有延遲，最嚴重時有88小時的延遲，以下為延遲截圖

2  goldengate的抽取程式延遲，一般有如下原因。

2.1 檢視系統的cpu負載是否過高

2.2 檢視系統的記憶體負載是否過高

2.3 檢視系統的io負載是否過高

2.4 驗證儲存的io壓力是否過高

2.5 檢視OGG的引數檔案，是否有設定不合理的

2.6 檢視OGG的日誌及報告，是否有報錯

2.7 生成trace檔案，檢視trace檔案是否有明顯的ORA錯誤或其他問題

2.8 生成pstack檔案，檢視是否有明顯的報錯

2.9 檢視oracle官方文件，檢視是否有有用的資訊。

3  經過驗證，CPU，記憶體，引數檔案已經進行排除，認為沒有任何問題。

4  檢視抽取程式的日誌狀態，發現讀取日誌時等待的比較多，如下

5 對goldengate的抽取程式做trace,發現時間都發生在讀取redo日誌上。

對抽取程式進行trace

send EXTXX,trace ./dirtmp/EXTXX_20211104.trc

GGSCI (xxxtdb3) 3> send EXTXX,trace ./dirtmp/EXTXX_20211104.trc              

Sending trace request to EXTRACT EXTXX ...

Trace file /goldengate/dirtmp/EXTXX_20211104.trc opened.

等待10分鐘後，關閉trace

send EXTXX,trace off

GGSCI (xxxtdb3) 4> send EXTXX,trace off

Sending trace request to EXTRACT EXTXX ...

Closing all trace files..

檢視生成報告的彙總，發現抽取程式延遲耗費的時間主要在讀取redo日誌，即表示讀取日誌慢，導致OGG抽取程式延遲：

09:29:30.193 (5913587390) IPC_read from xxxtdb3:30720

SUMMARY STATISTICS

General statistics:

 0.00% Checking messages (includes checkpointing)

      0.00% Checking periodic tasks

 0.00% Waiting for more data

 0.00% Converting ASCII header to internal

 0.00% Converting ASCII data to internal

 0.01% Reading input records

 0.00% Writing output records (replicate_io)

      0.00% Mapping columns

      0.00% Outputting data records

      0.00% Performing SQL statements

 0.00% Performing BATCHSQL statements

 0.00% Performing actual DB op

 0.00% Preparing SQL statements

 0.00% Performing transaction commits

 0.00% Checkpointing

Redo log statistics:

 0.00% Opening redo log file

 0.00% Positioning into redo log file

100.00% Reading record from redo log file

 0.00% Extracting subrecord from redo record

      0.00% Extracting start subrecord

      0.00% Extracting undo subrecord header

      0.00% Extracting undo subrecord

      0.00% Extracting redo subrecord header

      0.00% Extracting undo subrecord

      0.00% Extracting rollback subrecord

      0.00% Extracting commit subrecord

 0.00% Processing start subrecord

 0.00% Processing data subrecord

 0.00% Processing rollback subrecord

 0.00% Processing commit subrecord

 0.00% Retrieving and processing transaction items

      0.00% Retrieving transaction item

      0.00% Formatting output record

            0.00% Formatting output record header

            0.00% Validating update key data

            0.00% Formatting output record data

                  0.00% Converting Oracle data to ASCII

 0.00% Close redo log

6  檢視生成的trail的數量，發現抽取的資料不多。

[oracle@xxxtdb3 cj2]$ ls -ltr

total 652448

-rw-rw-rw- 1 oracle oinstall 199999350 Nov  4 09:17 cj041005

-rw-rw-rw- 1 oracle oinstall 199999457 Nov  4 09:46 cj041006

-rw-rw-rw- 1 oracle oinstall 171558015 Nov  4 09:59 cj041007

7   檢視資料庫日誌的情況，發現每日的日誌兩最低在3T，最多達到8T。在業務高峰，幾天的日誌量有幾十T，資料量特別大。

redo日誌的大小2G

8 經查，發現在另外一個節點又部署了17個OGG抽取程式

9  原因分析

   由於此係統業務繁忙，每日歸檔量在3T到8T之間。總共又21個抽取程式，在業務最繁忙的時間，每日歸檔量達到8T，21*8=168T的資料，21個OGG抽取程式相互爭用，導致OGG的抽取程式的時間都花費在讀取歸檔日誌上，最終導致抽取程式延遲大。幸虧此係統使用的為海天的分散式儲存，IO效能極好，要不然OGG的延遲就不是88小時，有可能達到1000小時以上。故再次說明系統硬體極好的情況下，如果架構有問題，也會極大的降級系統的效能，還需要專業的人員進行根本原因分析。此問題有代表性，全國的這個行業都是這個架構，需要進行優化。

10 解決方法

     將所有的抽取程式合併成一個，解決IO爭用問題。此問題的解決文件，在下一篇文件中解決。

以下為合理的OGG架構模式，即一個抽取程式，多個投遞程式。來源於Oracle的官方文件：