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

• 資深大佬 : sunziren

  四千张表，我了个乖乖。

• 主 資深大佬 : xiaoleis

  @sunziren 对，大概 2000 个 g 的数据， 头大。

• 資深大佬 : xcstream

  硬盘镜像

• 資深大佬 : sun1991

  直接拷贝数据库文件, 挂载到新的 instance, 然后再改表结构?

• 資深大佬 : wunonglin

  阿里云 dts

• 資深大佬 : rrfeng

  1. 备份做好
  2. 能停机迁移就停机迁移，不要强行 0 停机时间。

• 資深大佬 : dexterzzz

  stand by 啊

• 資深大佬 : enrolls

  alibaba/DataX 这个看看

• 主 資深大佬 : xiaoleis

  @rrfeng 每天都有备份。还涉及及表结构的变动。

• 資深大佬 : xpresslink

  复制库文件，到新服务器挂 instance 最省事儿

• 主 資深大佬 : xiaoleis

  @wunonglin
  @enrolls 涉及到表结构的变更，有什么更好的处理策略吗？

• 資深大佬 : chendy

  既然是 oracle，找 oracle 的人或者找个做 oracle 的公司来迁移？…

• 資深大佬 : wangyzj

  oracle 到 oracle ？

• 主 資深大佬 : xiaoleis

  @wangyzj 是，oracle —> oracle

• 資深大佬 : wangyzj

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

• 資深大佬 : gemini767

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

• 資深大佬 : psirnull

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

• 資深大佬 : slyang5

  迁移的时候 数据库 还要对外服务吗 ？？？

• 資深大佬 : koolob

  感觉买 oracle 的服务应该可以。如果出问题，可以赔偿损失。

• 資深大佬 : saximoer

  停机时间要求多少呢?
  不同停机时间的方案不一样

• 資深大佬 : zlowly

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

• 資深大佬 : hantsy

  找 Oracle 吧，有 Oracle 数据库，应该有服务可以打折吧。

• 資深大佬 : yiyi11

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

• 主 資深大佬 : xiaoleis

  @slyang5
  @saximoer 计划的停机时间是 一晚上， 晚八点到早八点

• 主 資深大佬 : xiaoleis

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

• 主 資深大佬 : xiaoleis

  @hantsy 要是有经费。 ^—–^

• 資深大佬 : boshok

  @psirnull 可以

• 資深大佬 : realpg

  都选 oracle 了还能没有经费……

• 資深大佬 : realpg

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

• 資深大佬 : LightLolo

  可以 dump 分表分块导出
  可以 OGG 同步搞
  可以用 kettle 做数据抽取

• 資深大佬 : slyang5

  @xiaoleis 你不是都 停机导数据了么？ 会什么会有结构变更？？？

• 資深大佬 : zlowly

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

• 資深大佬 : zlowly

  大约的流程就是
  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 也不一定能适应，就还需要其它方案来弥补。