一对双引号引发的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@]