全库数据迁移,咨询个靠谱的解决方案。

将 A 数据库的数据全部迁移至 B 数据库:

  1. 均为 Oracle 数据库
  2. B 库表结构的字段精度、唯一约束、主键都可能有改动。 表名一致。
  3. 涉及大约四千张表。

相关文章

32 thoughts on “全库数据迁移,咨询个靠谱的解决方案。

  1. @xiaoleis 用 tsm 或者其他工具恢复一个一模一样的库作为 b
    然后跑 dll 修改脚本
    对 b 做日志追加数据同步
    上线前做最后的 dll 变更和索引重建
    直接切换到 b

  2. 选择了 oracle 当然请人迁移啊!
    长痛就是请人维护
    短痛就是去 O,如果强 OLAP 可以选 pg

  3. 1 、数据泵导出 初始化
    2 、OGG 同步追平
    3 、申请检修,切换业务数据源
    4 、验证
    5 、停止 OGG
    6 、原数据库停用,下线

  4. 17 楼是比较稳妥的方案。
    特点是业务系统停机时间比较短,特别是用 OGG 来追平数据,可以较好的适应对你需求里的 B 表结构可能发生变更这个特殊点。

  5. 17 楼方案加一
    公认标准方案。
    我试过几 T 的数据量都是这样迁移,不过只有几十张表,单表高达 21 亿条数据,依然很稳。

  6. @zlowly
    @yiyi11 现在统计的结果是有 700 多张表发生了结构变更。如果因为结构变更,数据冲突无法插入,就不好办了。

  7. 另外,也不是不能没有经费。
    如果没有经费,这个迁移项目最值钱的精髓就是方案设计了……
    方案做万无一失,怎么也值几十 K
    会做的人不可能让你白嫖或者打折

  8. @xiaoleis 对于如果因为结构变更,数据冲突无法插入,最坏的结果,也就是 B 库不能用而已,这个时候还没切换,A 库还是正常提供业务的,顶多就是浪费了时间而已,慢慢再梳理调整 B 库数据结构罢了。

  9. 大约的流程就是
    0 、准备好 B 库以及变更数据结构脚本,A 、B 库上安装 OGG 并做好相关配置
    1 、A 上启动 OGG 抽取投递进程
    2 、A 库上导出数据,传输到 B 库导入
    3 、B 库上运行变更数据结构脚本
    4 、B 库上启动 OGG 应用进程
    5 、停止业务应用,等待 A 、B 库上 OGG 完成所有抽取投递应用
    6 、更改业务数据源到 B 库
    7 、启动业务应用
    可以看到这种方案只在最后三步才需要停顿业务,前面实施时间完全可以很充裕(特别是 2T 数据量的导入导出一个周末,稍微不顺利还真不一定搞得定),所以真正对业务影响比较短。这些过程,应该先进行演练,最后三步用业务测试环境来进行最后验证。如果 AB 数据结构变化过大,单靠 OGG 也不一定能适应,就还需要其它方案来弥补。

发表评论

电子邮件地址不会被公开。 必填项已用*标注