环境:
远端字符集:utf8
分发中心字符集:utf8
目标端字符集:al32utf8
varchar2类型没有问题,但char有问题
mview同步第一种方式:
源端到分发中心:
create MATERIALIZED view tab_linuxidc Build IMMEDIATE Refresh force On demand With primary key As Select * fromtab_linuxidc@"www.linuxidc.com";
这一步没有问题
分发中心到目标端:
create MATERIALIZED view tab_linuxidc Build IMMEDIATE Refresh force On demand With primary key As Select * fromtab_linuxidc@"www.linuxidc.com";
这一步就有问题了,因为utf8(al24utf8)占3个字节,而al32utf8占4个字节,而如果源端的char(10),在目标端也占10个字节。当遇到怪癖字时,在源端可以存储,在目标端就存储不成功,导致源端和目标端不一致。
mview同步第二种方式
源端到分发中心:
create MATERIALIZED view tab_linuxidc Build IMMEDIATE Refresh force On demand With primary key As Select * fromtab_linuxidc@"www.linuxidc.com";
分发中心到目标端:
CREATE MATERIALIZED VIEW tab_linuxidc REFRESH FORCE ON DEMAND WITH PRIMARY KEY AS SELECT (SUBSTR(NAME, 1, 4)) as NAME FROMtab_linuxidc@www.linuxidc.com;
这里name字段在源端是char(4),但只存储‘1’,因为是char的原因,所以1后面带了3个空格,这样通过上面sql创建数据类型变为varchar2(16),而且数据里还带有三个空格(1后面带了3个空格);因为oracle对char后的空格,在运算时是自动删除的,oracle认为那是系统自身添加的,不是真实的数据,但是转化成varchar2后,因为varchar2是动态存储的,没有自动补齐一说。所有当有空格时,oracle就是认为这空格是真实的数据。这样用同样的sql就无法查到数据了。
解决方法
1.改变源端数据类型为varhcar2,这个对应用影响较大。
2.想办法把从分发中心到目标端同步多余的空格给截取到,可以通过(rtrim,cast),建议用cast函数。例子如下:
CREATE MATERIALIZED VIEW tab_linuxidc REFRESH FORCE ON DEMAND WITH PRIMARY KEY AS SELECT CAST(NAME as char(8)) FROMtab_linuxidc@www.linuxidc.com;
这样字段的数据类型就都一样了,而且也重新定义了目标端的字段的长度。
--------end-----------