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://myzitong.com/article/gghpos.html