【原創】一對雙引號引發的goldengate血案

一對雙引號引發的goldengate血案：

源是sql2005 ，目的是linux x64 下的db2 v9.7

因為是測試環境，所以只同步了一個sql2005的表（注意，此時我並沒有意識到sql2005是區分大小寫的）

源端和目的端配置完畢後，分別啟動兩端的mgr程式，狀態是running。ok！
extract 程式的狀態是running
datpump 程式的狀態是running
replicat程式的狀態是running

ok!

在源端插入一條記錄（此表已經被配置extract）,
馬上就看到了源端trail檔案的修改時間變了。
馬上就看到了目的端trail檔案的修改時間也變了。
然後replicat程式的狀態是running
然後去目的庫檢視此條記錄是否存在，結果是不存在。

分析過程：

● If the system or database is case-sensitive, Oracle GoldenGate supports the case
sensitivity of database names, owner and schema names, object names, column names,
and user names.
● If the system or database is case-insensitive (or is configured for case-insensitivity),
Oracle GoldenGate converts all names to upper case.


1.使用logdump工具，分析目的端的trail檔案，確實能看到到在此trail檔案中包含了此條insert into 語句

2.經過詢問oracle 技術支援，發現是目的端replicat引數檔案中的寫法有問題。
MAP "dbo.bkb", TARGET 引數中，源端的表名 "dbo.bkb"一定要被雙引號引起來。因為源端的sql2005資料庫的排序規則是Chinese_PRC_BIN，此種排序規則是區分大小寫的。

加與不加雙引號，goldengate在 解釋MAP 引數時會發生差異：
不加的話，MAP dbo.bkb 會被解釋為MAP DBO.BKB
加的話，MAP "dbo.bkb" 會被解釋為MAP dbo.bkb

由於源端sql2005區分大小寫，所以，傳到目的端的trail檔案中，涉及到table名的部分，肯定是dbo.bkb（而不是DBO.BKB）

而若是replicat引數檔案中不加雙引號，MAP dbo.bkb 會被解釋為MAP DBO.BKB

這樣的話，map 的是DBO.BKB，傳到目的端的trail檔案只有dbo.bkb，不匹配。所以，目的端的replicat程式running，但是沒有複製任何東西。






[@more@]