11. Golden Gate 簡易除錯

當 OGG 的 Group 發生問題造成 Abend 的狀態時，首先必須要檢視此 Group 相對應的 log ，這邊講的 log 就是 OGG 的 report file ，預設位在 OGG Home 底下的 dirrpt 目錄，雖然 OGG Home 底下的 ggserr.log 也會有相關資訊，但不及於 dirrpt 底下的 rpt file 來的詳細，建議有問題的時候都直接檢視 rpt file 。

OGG 有幾個常見的問題整理如下 :

• ggsci 啟動問題

在 OGG軟體安裝完成後，要進入 ggsci 時產生錯誤如下 :

./ggsci: error while loading shared libraries: libnnz11.so: cannot open shared object file: No such file or directory

這個訊息表示 ggsci 找不到相對應的 library ，大部分都是 LD_LIBRIARY_PATH 的環境變數沒有設定，只要設定環境變數 LD_LIBRIARY_PATH 為 $ORACLE_HOME/lib 就可以了，在 AIX 的環境下則是設定 LIBPATH ， OGG 19c 之後的版本在安裝完之後 OGG Home 目錄下就會有必要的 library ，所以要再多設定 GG_HOME 這個環境變數為 OGG 的軟體安裝目錄。

• Extract 無法啟動問題

設定完一個新的 Extract Group 但是無法啟動，檢視 rpt file 發現錯誤如下 :

log 顯示 Group 的名稱與參數檔裡面的設定不相同，更正後就可以啟動。

• Extract Abend 問題之一 :

Extract 發生 Abend ，檢視 rpt file 錯誤如下 :

log 顯示 Extract 因為權限問題無法存取 Redo / Archive Log ，這個問題常常發生在 OGG 的作業系統使用者與 Oracle 軟體的使用者不同，由於 archive log 產生出來的權限為 -rw-r----- ，這個是無法更改的，若是 OGG 使用者與 Oracle 不同，那麼就會產生此問題，這個時候必須要使用 Integrated Extract 才可以避免此問題， Classic Extract 使用的是 api 解析 Redo / Archive ，無法解決權限存取上的問題。

• Extract Abend 問題之二 :

ERROR OGG-00446  Could not find archived log for sequence 301894 thread 1 under default destinations

因為缺少 archive log 所以 Extract Abend 了，這個問題容易發生在資料庫備份的時候，當 archive log 備份完成後就予以刪除，此時刪除到 Extract 還沒讀到的 archive log 就會產生 Abend ，解決方法是改用 Integrated Extract 就可以完全避免此問題，在 Integrated Extract 的狀態下，只要是 archive log 還沒有被讀到，除非使用 force 指令否則 archive log 是不能刪除的。

• Pump Abend 問題之一 :

OGG-01223  Oracle GoldenGate Capture for Oracle, dp1.prm:  TCP/IP error 111 (Connection refused)

Pump 產生了 TCP Error 大部分都是防火牆的問題，必須檢查防火牆有無開通，以及 MGR 的 Dynamic Port 設定是否正確。

• Pump Abend 問題之二 :

OGG-01201  Error reported by MGR : Access denied

這個是 OGG 12.2 之後新的安全性設定，只要 Trail File 不是放在預設路徑 ./dirdat 底下，就必須於 MGR 設定 access rule ，例如 :

ACCESSRULE, PROG *, IPADDR 192.168.49.20, ALLOW

• Replicate ORA-01403 Error :

ORA-01403: no data found 算是 Replicate 很常出現的一個錯誤，這個訊息表示要同步的資料在 Target 找不到，經常發生在 Delete 或 Update 的語法上，看到這個訊息首先檢查 Discard File (dirrpt 底下的 .dsc 檔案) :

.dsc 要看的是 Trail File 裡面是否缺少 Key Column 的數值，上述例子就是缺少 CUST_CODE 這個 Key Column 的數值，如果是這個情況表示 Source 端沒有為這個 Table 添加 supplemental log ，這個時候要回 Source 端 add trandata ，然後重新 exp 、 imp 同步這個 Table 。如果 .dsc 顯示的 Key Column 沒有缺少數值，那麼就可能不是 trandata 的問題，這個時候就是 Table 本身資料面或資料錯誤的問題，就必須要再進一步比對資料才能找出問題所在。

• Replicate 同步效能問題

Replicate 在同步的過程中 apply 的速度很慢，造成 Trail 產生的速度大於 apply 的速度，怎麼都追不完。

這個問題常常發生在 Table 沒有 Primary Key 或是 Unique Index 的情況，此時 OGG 會使用 Table 的全部欄位當 Key 來同步，如果此時 Table 沒有 Index ，那麼 Full Table Scan 的情況下， Replicate Apply 的速度自然就慢了，由於 Replicate 使用的是 row by row 逐筆的 apply ，也就是 Source 使用了一個 update 語法一次 update 100 筆資料，而 Target 在 row by row 的情況下必須做 100 次，在 Table 沒有 Index 的情況下自然就會產生 Apply 很慢的情況。

解決方法就是幫 Target 端的 Table 建立 Index 來加快 apply 的速度，最理想的情況下就是建立全部欄位的 Index ，但有時候 Table 欄位過多無法這樣建，那麼就挑 Distinct Value 最大的那幾個欄位來建 Index 吧。

OGG 除錯只要掌握一個原則，就是檢視 Report File 的錯誤訊息，針對這個錯誤訊息找出相對應的解決方案。