MySQL数据库迁移到达梦数据库超出定义长度问题

一、问题背景

一般从MySQL迁移到DM数据库时,由于MySQL字符串的长度是以字符为单位,导致迁移过程中有可能遇到报错:超出定义长度。

在DM8的早期阶段,针对从MySQL迁移至DM的场景,由于当时DM尚未原生支持变长字符类型(如VARCHAR(N CHAR))的数据存储需求,故引入了LENGTH_IN_CHAR参数作为临时解决方案。旨在兼容并处理数据字符串截断的特定情境,确保迁移过程中的数据完整性。

随着项目应用的深入及服务团队的持续反馈,LENGTH_IN_CHAR 参数的启用被发现与多种兼容性问题相关联,核心问题总结如下:

  1. LIKE查询异常
    • 当数据库初始化配置为使用UTF-8字符集且不区分大小写,并激活 LENGTH_IN_CHAR 参数时,用户在执行 SELECT 语句采用 LIKE 模式匹配查询字符串时,曾遇到数据检索不准确的问题。
    • 此问题已在DM8的 8.1.2.135 版本中得到修复。
  2. DBLINK查询字符集转换错误
    • 在相似的配置环境下(UTF-8字符集,不区分大小写,启用 LENGTH_IN_CHAR ),通过数据库链接(DBLINK)执行 SELECT 查询时,该参数导致内部字符集转换过程发生异常,引发了字符集截断错误。
    • 此技术障碍亦已在DM8的 8.1.1.117 版本中获得解决。
  3. 存储差异性问题
    • 若数据库实例配置启用了 LENGTH_IN_CHAR 参数,且字段定义采用 VARCHAR(10),不同字符集的采用将直接影响到实际可存储的数据量。
    • 这进一步凸显了该参数对数据存储一致性可能产生的不利影响,具体表现依字符编码而异。

综上所述,鉴于 LENGTH_IN_CHAR 参数引发的多方面兼容性和一致性问题,结合已有的版本更新修复情况,其停用被视为提升系统稳定性和兼容性的必要举措,并且在 8.1.3.167 版本正式废弃。

本文就是介绍目前新版DM数据库MySQL利用DTS迁移到DM数据库避免超出定义长度问题的方法。

二、DTS迁移MySQL

2.1 设置数据类型映射

  1. 添加映射
  2. 配置:源数据类型名-VARCHAR,目的数据类型名-VARCHAR,强制为字符存储选择-是
  3. 保存

2.2 迁移过程

源端数据库

目的端数据库

迁移选项※

取消单选框,不使用默认数据类型映射关系,便能调用到我们所配置的数据类型映射。

指定模式

指定对象

审阅迁移任务

点击“完成”,进行迁移,即可完成数据类型的映射。

暂无评论

发送评论 编辑评论


|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇