暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / MySQL udump导数问题剖析

MySQL udump导数问题剖析

IT那活儿 2023-09-08
701

点击上方“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那活儿”公众号

导数sql修改字段长度mysql
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论