GoldenGate資料遷移的問題總結(一)

今天對GoldenGate的資料同步進一步做了測試，發現在一些模擬真實的場景中，需要考慮的因素要更多更為複雜。簡單同步幾條，幾百條資料的測試同步做驗證測試可以，但是很難測試出來一些潛在的問題，今天碰到了一些問題，基本都得到了解決。

首先要測試的這個環境資料要多一些。匯出了一個測試環境的資料進行OGG的複製演練。

test@TESTDB> select table_type from cat group by table_type
TABLE_TYPE
-----------
TABLE
VIEW
SYNONYM
SEQUENCE
test@TESTDB> select count(*)from cat;
  COUNT(*)
----------
       259

我覺得資料遷移裡面增量資料的遷移實在是太複雜了，一旦某個地方出錯，回滾的餘地都會很小。這個使用者下有不少的表，所以測試起來就會更加謹慎小心。為了不影響其它使用者，我先做了源端和目標端的配置。源端基於Solaris,10gR2,目標端基於Linux 64,11gR2

配置抽取程式

dblogin userid ogg_source,password oracle
add trandata test.*

edit params ext_test
 EXTRACT ext_test
 USERID ogg_source, PASSWORD oracle
 EXTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl
 TABLE test.*;

ADD EXTRACT ext_test, TRANLOG, BEGIN NOW
ADD EXTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl, EXTRACT ext_test
start ext_test
info ext_test

配置投遞程式

edit params dp_test
 EXTRACT dp_test
 PASSTHRU
 RMTHOST 10.127.133.125, MGRPORT 1530
 RMTTRAIL  /export/home/oracle/ogg/ogg_10g/dirdat/tl
 TABLE test.*;

ADD EXTRACT dp_test,EXTTRAILSOURCE /export/home/oracle/ogg/ogg_10g/dirdat/tl
ADD RMTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl, EXTRACT dp_test

start dp_test
info dp_tes配置應用程式

dblogin userid ogg_target,password oracle

edit params rep_test
 REPLICAT REP_test
 USERID ogg_target, PASSWORD oracle
 ASSUMETARGETDEFS
 HANDLECOLLISIONS
 MAP test.*,TARGET test.*;

ADD REPLICAT rep_test, EXTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl,CHECKPOINTTABLE ogg_target.CHKPTAB
start rep_test為了簡單測試一下資料量大的情況下的同步情況，我選取了下面的幾個表資料,摘自impdp的日誌

. . imported "test"."SWD_DRAWCN"                         839.7 MB 11174310 rows
. . imported "test"."SWD_QDRAWCHECK"                     187.7 MB 9052277 rows
. . imported "test"."TL_SERVER_LOG"                      13.92 MB   61341 rows
. . imported "test"."SWD_DRAWCARD"                       8.129 MB  185044 rows

首先測試了delete的情況，看看源端，目標端的同步速率，整個過程持續了近40分鐘，其中大部分的時間都在源端，可見硬體老化還是很嚴重的，在目標端同樣的操作就快了不是一點半點。

問題1：抽取程式失敗

然後再次使用impdp在源端匯入資料，這個過程源端的抽取程式很可能會失敗，原因之一就是因為impdp需要建立一個臨時表，而我們在配置裡指定測試使用者下的表都要對映 。

2016-11-16 16:21:04  ERROR   OGG-00901  Failed to lookup object ID for table test.SYS_IMPORT_TABLE_01

.這個過程很容易，在Impdp完成後重啟抽取程式即可。

問題2：支援TRUNCATE

我對測試環境中的物件進行了檢查，發現有一個地方很可能出現問題，因為線上上庫中存在一個JOB,會先清空一箇中繼表資料，然後補入一部分資料，清空的操作是truncate,所以資料同步還是需要支援truncate操作，對於其它的DDL暫時先不動。

要實現識別truncate的操作，OGG已經做好了，需要在抽取程式和應用程式的引數配置，加入一個引數GETTRUNCATES即可。這樣就可以輕鬆同步資料了，使用truncate都可以自動同步，擺平了一個潛在的隱患。

問題3：投遞程式失敗

下午在大批次資料的測試場景中，發現投遞程式竟然自動停了。

2016-11-16 17:22:36  ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, dp_test.prm:  PROCESS ABENDING.
2016-11-16 17:22:53  INFO    OGG-01026  Oracle GoldenGate Capture for Oracle, ext_test.prm:  Rolling over remote file /export/home/o
racle/ogg/ogg_10g/dirdat/tl000059.登入到目標端，發現資料庫直接hang住了。

[oracle@newtest ~]$ sqlplus n1/n1
^C ERROR:
ORA-02002: error while writing to audit trail
ORA-00604: error occurred at recursive SQL level 1
ORA-01013: user requested cancel of current operation

而問題的原因就是歸檔空間滿了。簡單清理後繼續測試。

問題4：trail檔案的清理

而後續繼續測試，發現另外一個問題擺上了日程，那就是對trail檔案的清理，其中一個方式就是在mgr中配置引數，設定一個範圍來刪除。

edit param mgr
PURGEOLDEXTRACTS /export/home/oracle/ogg/ogg_10g/dirdat/tl*, USECHECKPOINTS, MINKEEPDAYS 2

問題5：無法停止replicat程式

如果在資料同步的過程中，停止replicat程式失敗，會直接影響資料同步的情況

GGSCI (newtest.oracle.com) 10> stop rep_test
Sending STOP request to REPLICAT REP_test ...
STOP request pending end-of-transaction (6158834 records so far)..

可以使用kill的方式終止

GGSCI (newtest.oracle.com) 9> info all
Program     Status      Group       Lag at Chkpt  Time Since Chkpt
MANAGER     STOPPED                                           
REPLICAT    STOPPED     REP_1       00:00:00      00:00:34    
REPLICAT    RUNNING     REP_test    00:31:32      01:01:07  

GGSCI (newtest.oracle.com) 14> start mgr
Manager started.

GGSCI (newtest.oracle.com) 17> kill replicat rep_test
Sending KILL request to MANAGER ...
Killed process (84166) for REPLICAT REP_test

小技巧：

在資料複製的過程中，如果想檢視源端目標端的同步情況，使用info得到的資訊是很籠統的，我們可以使用send的方式得到一個狀態資訊，這個資料是相對準確的。

GGSCI (newtest.oracle.com) 2> send rep_test, status
Sending STATUS request to REPLICAT REP_test ...
  Current status: At EOF
  Sequence #: 48
  RBA: 99999876
  6158834 records in current transaction
PENDING
  STOP request pending end-of-transaction (6158834 records so far)