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 initializeWin）。

錯誤資訊：run GGSCI command but the Alert window report "Application failded to initialize0xc000026e）"。

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找不到對應記錄，並且某幾個欄位為空白，則可認定為缺少了附加日誌。

oracle視頻教程請關注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html