点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
晚上进行数据割接操作，但在进行导数的过程中出现报错，导致有一个schema没有导成功。
问题分析
经分析，是因为目标端的一个schema下有一张表的字段长度与源端不同，导致数据导入失败。
报错内容：
ERROR: Data truncation: ***.***.***.****:****/OID_02 | Data too long
for column 'REMARKS' at row 7 Query: * udaldump sql
from ***.***.***.****-paas-crm-dbbackup-002 */ INSERT
INTO `sale_order_handle` (``, `SEPRE_ORDER_IDQ`,
`STAFF_ID`, `CHANNEL_ID`, `COMMON_REGION_ID`,
`STATUS_CD`, `STATUS_DT`, `CREATE_DT`,
`UPDATE_DATE`, `REMARKS`, `STAFF_NAME`)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) Parameters: []
23:09:52.734 [DumpWriter-0]
DEBUG com.ctg.udal.dump.data.pojo.DumpEvent:122 - DumpEvent[1200204911]
需要延时[499]毫秒后处理
23:09:53.256
[DumpWriter-0] WARN
com.ctg.udal.dump.data.writer.db.stragety.UkExceptionStrategy:55 - 1200204911=Found
one batch of Uk Table OID.sale_order_handle update fail.which will retry 2 times!
后面进行进一步分析检查发现是“REMARKS”这个字段的长度有问题，源端是“VARCHAR2(300)”，而目标端是“VARCHAR2(250)”。
问题处理
与业务联系，经过讨论后业务要求将目标端的表字段长度修改到“VARCHAR2(300)”。
修改字段：alter table 表名 modify 字段名 varchar(300);
修改后再次导入数据，正常导入。
总 结：出现这次导数失败的主要原因是字段长度不一至，源端是“VARCHAR2(300)”，目标端是“VARCHAR2(250)”。当源端数据导到目标端时，数据量超过250个字节，就导致数据导不过来，从而形成报错。如何避免：在导数前可以跟业务确认两边字段长度是否一致，或者先去库里检查一下源端和目标端的表字段是否一致。
END
本文作者：易龙超(上海新炬中北团队）
本文来源：“IT那活儿”公众号
