学无止境
分类: Oracle
2013-08-29 11:15:50
某客户在OGG的配置中,通过设置某个字段的映射关系为:
MODIFY_DATE=@GETENV ("GGHEADER", "COMMITTIMESTAMP")
将该字段作为事务的提交时间来判断事务在source上提交的先后顺序。
客户发现根据MODIFY_DATE的时间排列出来的先后顺序,并不是在source上提交的真实先后顺序,客户怀疑OGG的复制并不是按照source的事务先后顺序提交的。
实际上OGG在target上执行事务的顺序和source端是相同的,不仅仅在事务内部的顺序相同,在事务间的顺序也是相同的。
该问题的原因在于默认配置环境下,@GETENV ("GGHEADER", "COMMITTIMESTAMP")并不能真实反映出事务在source端的提交时间。
使用@GETENV ("GGHEADER", "COMMITTIMESTAMP") 这个OGG的环境值,就需要了解TCPSOURCETIMER/NOTCPSOURCETIMER参数。
这2个参数的设置是用于当系统时间不一致时,调整记录的时间戳传输到不同的系统上,目的是更好的解释同步延迟。
默认情况下为TCPSOURCETIMER:当发送到其他系统时会调整数据记录的时间戳。这时@GETENV ("GGHEADER", "COMMITTIMESTAMP")的时间戳既不真实反应出在source端的提交时间,也不是在target端的提交时间。
另一个设置为NOTCPSOURCETIMER:保留原始的时间戳值发送。当引用@GETENV ("GGHEADER", "COMMITTIMESTAMP")时,才能更为真实的反映出事务在source端的提交时间,但是该时间戳的精度只到秒。
经过测试,在默认使用TCPSOURCETIMER的情况下,使用@GETENV ("GGHEADER", "COMMITTIMESTAMP")记录事务提交时间,同时还在target端的表上使用序列记录一个主键,在测试环境中的确出现了主键更大的记录比主键更小的记录的时间早的情况。
MAP ......
SQLEXEC (ID lookup, query "select ldy.seq1.nextval idparam from dual",noparams, ERROR RAISE),
......
COLMAP(
......
id=lookup.idparam,
MODIFY_DATE=@GETENV ("GGHEADER", "COMMITTIMESTAMP"),
......
);
ID MODIFY_DATE
---------- ------------------------------------
138 28-8月 -13 01.13.37.591769 下午
170 28-8月 -13 01.13.37.591791 下午
154 28-8月 -13 01.13.37.591797 下午
186 28-8月 -13 01.13.37.591798 下午
202 28-8月 -13 01.13.37.591803 下午
418 28-8月 -13 01.14.21.591470 下午
452 28-8月 -13 01.14.21.591770 下午
304 28-8月 -13 01.14.21.591791 下午
370 28-8月 -13 01.14.21.591803 下午
330 28-8月 -13 01.14.21.591899 下午
364 28-8月 -13 01.14.21.599787 下午
如果在source的PUMP或EXTRACT上设置了NOTCPSOURCETIMER,那么该时间就较为准确的反映事务在source端提交的时间,但是精度只有到秒。
ID NEXT MODIFY_DATE
---------- ---------- -----------------------------------
6010 6012 28-8月 -13 02.45.32.000000 下午
6012 6014 28-8月 -13 02.45.32.000000 下午
6014 6016 28-8月 -13 02.45.32.000000 下午
6016 6018 28-8月 -13 02.45.32.000000 下午
6018 6020 28-8月 -13 02.45.32.000000 下午
6020 6022 28-8月 -13 02.45.32.000000 下午
6022 6024 28-8月 -13 02.46.11.000000 下午
6024 6026 28-8月 -13 02.46.11.000000 下午