# OMS数据迁移之报错万金油解决方法 > 作者/来源: UCloud 运营管理员 > 发布时间: 2023-01-11T05:20:00.000Z > 分类: 解决方案 > 标签: 数据库, Docker > 原文链接: http://117.50.162.249:3000/yun/articles/786 --- # OMS数据迁移之报错万金油解决方法 > 来源: https://www.ucloud.cn/yun/130083.html > 作者: IT那活儿 > 发布日期: 发布于2023-01-11 13:20 OMS数据迁移之报错万金油解决方法 [ 事件背景 ] OceanBase迁移服务（OceanBaseMigration Service，OMS）是蚂蚁OceanBase提供的一种支持同构或异构RDBMS与OceanBase之间进行数据交互的服务，它提供了数据在线迁移和实时增量同步的数据复制能力。 之前给大家分享了OMS迁移过程中踩过的一些坑，有各种的报错、bug导致的问题。虽然这些阿里通过版本迭代予以了解决，但运维的魅力之一就是摁下了葫芦浮起了瓢，解决的就是瓢的问题。 在OMS正向迁移（Oracle->OB）过程中报错主要分两部分，一部分是链路问题，OMS也需要在源端以及目标端创建进程来抽取数据分析日志并写入目标端。这部分的问题我们运维人员更多是想办法排查并规避，更多的问题需要阿里工程师对OMS工具优化。今天我们主要分享表结构迁移和数据迁移过程中报错常见问题及解决方法。 [ 场景回放 ] 下面两种报错解决方式均通过具体的报错解决案例来介绍 （一）表结构迁移报错 这种处理方式主要处理表结构迁移过程中的报错，以及数据迁移过程中因为表结构问题，数据还未插入表中时产生的报错 案例：隐藏列异常（OMS迁移ORACLE到OB过程中会在OB端表上创建隐藏列以及一个约束） 报错现象： 图1：OMS全量迁移过程中隐藏列报错![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_000.png) 解决步骤： 登录OB客户端->确认建表语句 showcreate table table\_nameG 图2：报错表建表语句 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_001.png) 可以看到建表语句中并没有创建上隐藏列，这时候就需要我们手工去修复，可以去查一下正确的建表语句 查看建表语句方法一： 图3：通过迁移任务结构迁移部分查看 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_002.png) 图4：在结构迁移的表结构同步的子任务里可以看到具体表的信息 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_003.png) 图5：查看报错表上下文找到DDL建表语句 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_004.png) 查看建表语句方法二： 登录OMS的租户 图6：登录语句 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_005.png) 切换OMS\_META用户,useoms\_meta 图7：查询OMS\_DDL表找到报错表的建表语句 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_006.png) 查询到正确的建表语句之后，在OB目标库删除有问题的表，然后执行建表语句，创建隐藏列和索引 图8：在OB端执行正确建表语句 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_007.png) 图9：创建完表showcreate table检查建表语句，复检迁移作业 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_008.png) （二）数据迁移过程中报错 这种方式主要处理表中已导入部分数据，在全量迁移途中报错 案例：源端表空间move触发bug导致正在迁移的分区找不到(ADGBug) 报错现象： 图10：迁移任务报错页面 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_009.png) 图11：oms后台报错日志，显示找不到对象 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_010.png) 解决步骤： 针对这个bug，OB研发更新了OMS校验规则，更多的需要我们规避迁移过程中DDL操作，在解决了问题之后，需要登录oms主机登录管理docker，检查配置文件 dockerexec  -it oms bash Cd/home/ds/run/134.80.184.66-9000:90243:0000000057/migrate/1 检查overview-done文件如果有报错表，手工删除下，overview-runing中找到报错表，随便修改一个不存在的名字避开校验 OB端清空报错表 obclient> truncate table SMSERXXXX; QueryOK, 0 rows affected (1.13 sec) obclient>truncate table I168USEXXXX; QueryOK, 0 rows affected (0.99 sec) 处理完之后 发起复检 图12：复检之后作业正常继续 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130083/images/130083_011.png) [ 分析总结 ] 在OB推行数据库商业化的过程中会存在各种各样的问题，需要我们大家协同发现问题，分析问题，解决问题。只有这样才能打造一款坚实的国产化产品。国产化必将是未来几年国内各行各业经济和技术革新的一个趋势。因此，基于近一段时间的问题的处理以及总结，针对OMS迁移过程中的一些问题我们也能做出相应的分类以及汇总，并总结出一定的处理方案。在这过程中，也使得我们使用人员对于迁移过程中涉及的原理有了更深的理解，这篇文章的分享就是我们近期在OMS迁移过程中探索的总结，虽不能覆盖所有问题，但类似问题的处理大同小异，都有共通之处，望给大家抛砖引玉。