dimp时报错,字符串截断

现象描述

达梦也有自己的逻辑备份工具(dexp 、dimp )用法和Oracle 类似,详细用法可以参考官方手册dexp&dimp.pdf

博罗ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联建站的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!

但是,我们有时候在进行dimp 时,会碰到字符串截断的问题。

碰到这种问题,我们怎么解决呢?

受限我们一定要非常明确,字符串截断这个报错,一定就只是精度不足,这里只是针对两种可能的情况的,描述下该问题。

只需要考虑两个问题:

Ø   是否表结构不一致,就是dexp 的表,是varchar (500 ),我们导入的表只是varchar (400

这种情况少,因为有时候我们经常是全用户新建导入,表结构也是源端带入过来的。

Ø   Dexp 源端的数据库实例字符集,是否和dimp 目的端数据库实例的字符集一致

这个是我们可能没有注意的问题。

处理方法

处理方法一:核查表结构是否一致

是否表结构不一致,就是dexp 的表,是varchar (500 ),我们导入的表只是varchar (400 )

这个问题好理解,就是字面意思,我们只需要把目的表的精度改成和源端一致,重新清空目的表,再导入即可。

处理方法二:核查数据库实例字符集

我们碰到这个问题的时候,实际上就是我们从UTF-8 的数据库实例上dexp 出来的数据库,往GB18030 的数据库实例上dimp ,才会碰到这个问题。

默认情况下,达梦数据库实例的varchar 字段的精度,表示的含义是字节,而对于汉字而言,在UTF-8 编码下的字节占用,是比GB18030 编码下的字节占用,要大。

所以反过来说,对于dexp&dimp 搬过来的表结构,都是一致的情况下,比如:都是varchar (400 ),可以存放的汉子个数,是不一样的。

备注:

-           对于同一项目内的数据库实例、可能需要互相进行数据传递的实例之间,务必把数据库底层参数(含字符集)规划并切实设置成一致!

-           同一项目内的数据库实例,请务必保持一致、非同一项目内,有数据传递需求,但是相关性不搞,且确实不能保持一致的字符集,可以通过手动放大目的端数据库实例上的varchar 字段精度。为什么可以这样处理,方法二中已经说明。

这是一个把数据库实例中目标表中的所有varchar 字段,精度放大一倍的脚本(当成SQL 执行):通过控制游标查出来的表即可。

declare

begin

for rs in(

select sch.name sch,tab.name tab,col.name   col,COl.length$ len from sysobjects sch,sysobjects tab ,syscolumns col

where sch.id=tab.schid and   sch.name||'.'||tab.name in (

'USER.TABUTKMONITOR',

'USER.TABUTHORIZATIONRISKLOG',

'USER.TABUSTOMER',

'USER.TABARD',

'USER.TABOSSREPORT',

'USER.TABUDGETENTITYCARDS',

'USER.TABRANSACTIONLOG',

'USER.TABCCOUNT',

'USER.TABSTOMERINFO',

'USER.TABRANSACTIONLOG',

'USER.TABUTHORIZATIONRISKLOG'

)

and tab.id=col.id and col.TYPE$ in   ('VARCHAR','VARCHAR2') ) loop

declare

begin

 execute immediate 'alter table   "'||rs.sch||'"."'||rs.tab||'" modify '||rs.col||'   varchar('||rs.len*2||');';

exception when others then

 print(sqlerrm);

end;

end loop;

end;


分享名称:dimp时报错,字符串截断
网页地址:http://pwwzsj.com/article/gghpos.html