GoldenGate常見異常處理

在維護GoldenGate過程中，由於各種意外情況，難免還是會遇到各種各樣的問題。掌握一些常見的GoldenGate故障診斷和錯誤分析的方法是非常有必要的，而且掌握這些錯誤分析工具也進一步加深對GoldenGate產品的認識與對GoldenGate原理的理解。

GoldenGate執行起來後，隨著時間的推移可能會碰到各種各樣的問題，下面就來介紹常見的異常現象以及常見的異常處理方法。

1.1  異常處理的一般步驟

首先確定是GoldenGate的哪類程式有故障（是抽取，投遞還是複製程式有問題），解決故障的一般思路如下。

（1）透過GGSCI>view report命令查詢ERROR字樣，確定錯誤原因並根據其資訊進行排除。

（2）透過GGSCI>view ggsevt檢視告警日誌資訊。

（3）檢查兩端資料庫是否正常執行，網路是否連通。

（4）透過logdump工具對佇列檔案進行分析。

1.2  RAC單節點失敗

在RAC環境下，GoldenGate軟體安裝在共享目錄下，可以透過任一個節點連線到共享目錄，啟動GoldenGate執行介面。如果其中一個節點失敗，導致GoldenGate程式中止，可直接切換到另外一個節點繼續執行。

操作步驟如下。

（1）以Oracle使用者登入源系統（使用另外一個正常的節點）。

（2）確認將GoldenGate安裝的所在檔案系統裝載到另一節點相同目錄。

（3）確認GoldenGate安裝目錄屬於Oracle使用者及其所在組。

（4）確認Oracle使用者及其所在組對GoldenGate安裝目錄擁有讀寫許可權。

（5）進入GoldenGate安裝目錄。

（6）執行。/ggsci進入命令列介面。

（7）執行start mgr啟動MGR。

（8）執行start er *啟動所有程式。

檢查各程式是否正常啟動，即可進入正常複製。

1.3  Extract常見異常

以下為列舉的一些常見錯誤資訊作參考用。

Extract程式包括抽取與投遞程式，投遞程式報錯大部分原因是由於網路故障。對於源資料庫，抽取程式ext**如果變為abended，則可以透過在GGSCI中使用view report命令檢視報告，可以透過搜尋ERROR快速定位錯誤。

一般情況下，抽取異常的原因是因為其無法找到對應的歸檔日誌，可以透過到歸檔日誌目錄命令列下執行

示例1：

ls –lt arch_x_xxxx.arc

檢視該日誌是否存在，如不存在則可能的原因如下。

日誌已經被壓縮。

GoldenGate無法自動解壓縮，需要人工解壓縮後才能讀取。

日誌已經被刪除。

如果日誌已經被刪除，需要進行恢復才能繼續複製。

一般需要定期備份歸檔日誌，並清除舊的歸檔日誌。需要保證歸檔日誌在歸檔目錄中保留足夠長時間之後，才能被備份和清除。即定期備份清除若干小時之前的歸檔，而不是全部歸檔。保留時間計算如下。

某歸檔檔案保留時間抽取程式處理完該檔案中所有日誌所需的時間。

可以透過命令列或者GoldenGate Director Web介面，執行info extxx showch命令檢視抓取程式ext處理到哪條日誌序列號。在此序列號之前的歸檔，都可以被安全的清除。

抽取程式在抽取不支援的資料物件時也會abend，report檔案會有詳細的報錯資訊，根據report檔案來定位錯誤資訊然後再排錯即可。

下面再單獨列出更多的幾個故障。

（1）Extract: Application failded to initialize（Win）。

錯誤資訊：run GGSCI command but the Alert window report "Application failded to initialize（0xc000026e）"。

GoldenGate在Windows平臺上需要安裝Microsoft Visual C ++ 2005 SP1 Redistributable Package。如果是Microsoft Itanium平臺，需要安裝vcredist_IA64.exe。

Windows 2008需以下額外操作：右擊‘cmd’ （DOS），選擇‘run as administrator’，然後在該命令列視窗中啟動MGR和Extract才能夠讀取資料庫日誌。

將OGG安裝為服務時（即執行“install ADDSERVICE”），需要使用管理員許可權，這樣啟動服務後即能訪問日誌。

透過以下方法為執行MGR和Extract的使用者新增讀取日誌檔案的許可權，右鍵單擊檔案->property->security->edit->add。

（2）Extract: Cannot load program./ggsci…

錯誤分析：請首先檢查該OGG Build是否與作業系統和資料庫相符；其次如果是Aix請檢查xLC版本是否符合10.0以上。

另外，檢查環境變數中動態庫路徑是否包含了資料庫動態庫目錄，例如：

示例2：

export LD_LIBRARY_PATH=$ORACLE_HOME/lib

不同平臺下的環境變數不同。

AIX  LIBPATH。

Solaris、Linux等  LD_LIBRARY_PATH。

HP-Unix  SHLIB_PATH。

重設環境變數需重啟Mgr和Ext/Rep程式。

（3）Extract: Block size mismatch （8192/512）…

裸裝置的偏移量各作業系統預設為0，但AIX預設為4096。當建立裸裝置時使用了-TO選項時，Oracle不會跳過4096位元組而是直接從0開始讀寫。 因此在AIX下使用裸裝置時，出現此錯誤需要指定OGG從偏移量0開始讀取。

示例3：

tranlogoptions rawdeviceoffset 0

該引數其在實際環境中使用機率非常高，在以前版本中如果缺少此引數Extract立即終止，但新版本Extract會持續進行嘗試，並不自動終止，需檢查報告檔案。

（4）Extract: ORA-15000 ASM connection error

該錯誤為OCI錯誤，表示Extract是在連線資料庫時出現問題，根據錯誤資訊判斷為許可權問題。

首先在Extract引數中檢查ASM相關引數tranlogoptions asmuser sys@+ASM1，asmpassword oracle，再檢查tnsnames.ora和listener.ora驗證ASM例項配置是否正確，確認ASM使用者具有SYSDBA 許可權；如果使用SYS，需要將ASM例項的init.ora中REMOTE_LOGIN_PASSWORDFILE引數設定為SHARED（多個資料庫可以使用一個password檔案，只有SYS使用者可以遠端登入）。

使用sqlplus驗證：

示例4：

sqlplus sys/oracle@asm1 as sysdba；//可以登入

sqlplus sys/oracle@asm1；          //報告15000錯誤

（5）Extract: Encountered SCN That Is Not Greater Than The Highest SCN Already Processed…

原因分析：在Oracle RAC環境中，Extract會啟動一個coordinator執行緒對各個節點上的操作進行根據SCN進行排序，它在交易提交後會等待THREADOPTIONS MAXCOMMITPROPAGATIONDELAY引數所定義時間來確認空閒節點沒有交易，然後再收集交易資料；寫入該交易後如果空閒節點後來又讀到了一個SCN號要小的交易，則會報告該錯誤。

可能原因：

各節點之間沒有配置時鐘同步。

一個節點比另外一個節點慢（IO問題可能性較大）。

解決辦法：

調整Extract引數：

示例5：

THREADOPTIONS MAXCOMMITPROPAGATIONDELAY <msec> IOLATENCY <msec>

MAXCOMMITPROPAGATIONDELAY有效範圍是0-90000ms，預設為3s（即3000ms）。

GGS Vx多了一個IOLATENCY引數，可以與上面引數一起加大等待時間。IOLATENCY預設為1.5s，最大值為180000。

建議出現該錯誤後可以將此二引數設定為較大值，然後逐步降低獲取最佳設定。

需要補充說明的是，出現此錯誤後，因後面的交易可能已被寫入日誌，重啟Extract可成功啟動，但是可能出現如下問題：Extract會重寫當前佇列覆蓋前面的交易資料，後面的Data Pump程式可能會出現“abend with incompatible record errors”錯誤終止（舊版本可能出現）。

此問題的恢復步驟如下。

① 停止所有Data Pump和Replicat，針對所有的Extract記錄其Write Checkpoint的佇列Seqno。

② 對於每個Extract向下滾動一個佇列：

示例6：

ALTER EXTRACT [name], ETROLLOVER

啟動Extract檢視是否滾動到了下一個佇列，記錄其新佇列seqno，應當是舊佇列號+1。

③ 修改Data Pump從新的佇列開始傳輸：

示例7：

ALTER EXTRACT [pump_name], EXTSEQNO ##### EXTRBA 0

重啟Data Pump檢視是否能夠重啟成功並從新的佇列傳輸。

④ 修改Replicat引數檔案，加入或者開啟HANDLECOLLISIONS，如果有GROUPTRANSOPS和MAXTRANSOPS請註釋掉，啟動Replicat，觀察其是否能夠讀取新傳輸過來的佇列如Replicat無法自動滾動到下一個佇列，需要透過如下命令手工滾動：

示例8：

alter replicat [replicat_name], EXTSEQNO ##### EXTRBA 0

等待Replicat處理到結尾沒有延遲時，可以關閉HANDLECOLLISIONS和恢復原來的GROUPTRANSOPS和MAXTRANSOPS引數。

⑤ 重新啟動Replicat即可恢復正常複製。

1.4  網路故障

如果MGR程式引數檔案裡面設定了autorestart引數，GoldenGate可以自動重啟，無需人工干預。

當網路不穩定或者發生中斷時， GoldenGate負責產生遠地佇列的Pump程式會自動停止。 此時，MGR程式會定期根據mgr.prm裡面autorestart設定自動啟動Pump程式以試探網路是否恢復。在網路恢復後，負責產生遠端佇列的Pump程式會被重新啟動，GoldenGate的檢查點機制可以保證程式繼續從上次中止複製的日誌位置繼續複製。

需要注意的是，因為源端的抽取程式（Capture）仍然在不斷地抓取日誌並寫入本地佇列檔案，但是Pump程式不能及時把本地佇列搬動到遠地，所以本地佇列檔案無法被自動清除而堆積下來，需要保證足夠容量的儲存空間來儲存堆積的佇列檔案。計算公式如下。

儲存容量單位時間產生的佇列大小×網路故障恢復時間

MGR定期啟動抓取和複製程式引數配置參考：

示例9：

GGSCI > edit param mgr

port 7809

autorestart er *,waitminutes 3,retries 5,RESETMINUTES 60

每3分鐘重試一次，5次重試失敗以後等待60分鐘，然後重新試三次。

1.5  Replicat程式常見異常

對於目標資料庫，投遞程式repXX如果變為abended，則可以透過在GGSCI中使用view report命令檢視報告，可以透過搜尋ERROR快速定位錯誤。

複製程式的錯誤通常為目標資料庫錯誤，比如：

資料庫臨時停機。

目標表空間儲存空間不夠。

目標表出現不一致。

可以根據報告檢視錯誤原因，排除後重新啟動rep程式即可。

需要注意一點：往往容易忽略UNDO表空間。如果DML語句中包含了大量的UPDATE和DELETE操作，則目標端UNDO的生成速度會很快，有可能填滿UNDO表空間。

典型錯誤（資料複製典型錯誤）如下：

示例10：

- SQL error 1403 mapping  2010-02-25 13:20:08  GGS WARNING     218  Oracle GoldenGate Delivery for Oracle, rep_stnd.prm:  SQL error 1403 mapping HR.MY_EMPLOYEE to HR.MY_EMPLOYEE.

可能原因包括以下幾個方面。

兩端結構不一致（異構環境，列和主鍵不同）。

兩端有不一致記錄。

附加日誌不全。

可以到discard檔案中檢視具體錯誤資訊，如果為UPDATE或者DELETE找不到對應記錄，並且某幾個欄位為空，則可認定為缺少了附加日誌。