oracle字符集引发mview的血案

亦凉 2022-06-13 04:07 24阅读 0赞

author：skate  
time：2012/03/20

**oracle字符集引发mview的血案**

现象：应用连接源端库可以查到数据，连接目标端查不到数据

环境：

远端字符集：utf8  
分发中心字符集：utf8  
目标端字符集：al32utf8

varchar2类型没有问题，但char有问题

**mview同步第一种方式：**  
源端到分发中心：  
create MATERIALIZED view tab\_skate Build IMMEDIATE Refresh force On demand With primary key As Select \* from[tab\_skate@"www.skate.com][tab_skate_www.skate.com]";  
这一步没有问题

分发中心到目标端：  
create MATERIALIZED view tab\_skate Build IMMEDIATE Refresh force On demand With primary key As Select \* from[tab\_skate@"www.skate.com][tab_skate_www.skate.com]";  
这一步就有问题了，因为utf8(al24utf8)占3个字节，而al32utf8占4个字节，而如果源端的char(10),在目标端也占10个字节。当遇到怪癖字时，在源端可以存储，在目标端就存储不成功，导致源端和目标端不一致。

**mview同步第二种方式**  
源端到分发中心：  
create MATERIALIZED view tab\_skate Build IMMEDIATE Refresh force On demand With primary key As Select \* from[tab\_skate@"www.skate.com][tab_skate_www.skate.com]";

分发中心到目标端：  
CREATE MATERIALIZED VIEW tab\_skate REFRESH FORCE ON DEMAND WITH PRIMARY KEY AS SELECT (SUBSTR(NAME, 1, 4)) as NAME FROM[tab\_skate@www.skate.com][tab_skate_www.skate.com 1];  
这里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\_skate REFRESH FORCE ON DEMAND WITH PRIMARY KEY AS SELECT CAST(NAME as char(8)) FROM[tab\_skate@www.skate.com][tab_skate_www.skate.com 1];

这样字段的数据类型就都一样了，而且也重新定义了目标端的字段的长度。

\--------end-----------

[tab_skate_www.skate.com]: mailto:tab_skate@'%20rel=
[tab_skate_www.skate.com 1]: mailto:tab_skate@www.skate.com