GoldenGate更新丟失問題

GoldenGate更新丟失問題

最近，在GoldenGate(11.2.1.0.1 for 10g)的目標庫上發現一個很有趣但又很擾人的問題。事情是這樣的，有使用者反映說在目標庫上的一張表上有兩個欄位(DZFAILFLAG,REMARK)的值與源庫的不一致。

檢查了一下源庫與目標庫的GoldenGate進程，兩邊都啟動並執行很好，也沒有報任何錯誤。查看了一下源庫和目標庫上那張表的記錄數，兩邊的記錄數是一樣的，但確實有些記錄的值是不一致的！而且當源庫的記錄數增加時，目標庫的記錄數也跟著相應增加：

源庫：
11:17:37 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
COUNT(*)
----------
980489
11:18:07 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
COUNT(*)
----------
980490
11:18:43 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
COUNT(*)
----------
980493
11:19:44 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
COUNT(*)
----------
980498
目標庫：
11:17:43 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
COUNT(*)
----------
980490
11:18:53 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
COUNT(*)
----------
980493
11:19:38 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
COUNT(*)
----------
980498

也就是說複製進程是在工作的，而且工作的很正常！嘗試對源庫上的某條記錄的DZFAILFLAG,REMARK進行更新，結果很讓人失望，在目標庫的這兩個欄位的值死活都不更新！考慮到這張表的記錄還不算多，於是就對這張表重新進行了初始化。經過一番折騰，表終於重新初始化完成了，滿懷著希望重新嘗試對源庫上的欄位進行更新，結果讓人抓狂，還是不更新！沒辦法，只能去分析一下trail檔案，看看到底發生了什麼事，用logdump開啟相應的trail檔案，定位到相應的位置：

2013/08/20 12:50:55.000.000 FieldComp Len 48 RBA 17500895
Name: LISDATA.LDCONTINVOICEMAP
After Image: Partition 4 G s
0000 0010 0000 000c 3330 3030 3030 3030 3130 3335 | ........300000001035
0001 0005 0000 0001 3100 0200 0f00 0000 0b38 3330 | ........1........830
3130 3030 3030 3032 | 10000002
Column 0 (x0000), Len 16 (x0010)
Column 1 (x0001), Len 5 (x0005)
Column 2 (x0002), Len 15 (x000f)

從trail的記錄裡可以看到，EXTRACT只抓取到了主鍵列(列0，1，2是這張表的主鍵)，而要更新的那兩列沒有抓取到！試著重啟了一下EXTRACT進程，結果更新就一切正常了！

瞭解到欄位DZFAILFLAG,REMARK是前兩天剛剛新增加的，而更新丟失恰恰就發生在這兩個新增欄位上。也就是說當對錶增加新欄位，如果不重啟EXTRACT進程，就無法抓取到新的欄位資訊！這樣的話，那如果使用GoldenGate的DDL複製功能，即使DDL複製工作正常，是不是應該也會碰到這樣的問題？那GoldenGate的DDL的複製功能豈不成了擺設？已經開了SR給Oracle，不知道是不是GoldenGate的BUG。在這之前，各位在做DDL前，還是先把EXTRACT先停掉。