一定要基于数据库厂商提供的工具！其他行业我不知道，在金融行业，人民银行发布的有金融行业数据库标准 《分布式数据库技术金融应用规范》（ JR/T 0204—2020），明确要求厂家提供数据迁移工具。没有这个工具就别在金融行业混饭吃，换句话说重点，数据迁移的风险必须由国产数据库厂商来...

OceanBase OMS 可以提供一站式的数据迁移解决方案, 包含结构迁移、全量迁移、增量同步及全量校验。对于Oracle数据库，可以迁移至 OB_Oracle及 OB_MySQL模式。

根据迁移经验，目前适配问题较多的是存储过程和函数之类的特殊数据库对象，通常我们采取将这些特殊对象改造通过应用实现。

上线是需要制定应急预案，出现问题要把数据倒刷回去紧急回退，对于已经上线并运行一段时间出现问题想回退，需要满足两个条件。第一应用支持两种不同数据库，支持oracle和国产数据库，并且应用两套代码都支持同步开发，可以更改配置数据源后能切换数据库。第二，两个数据库间数据准实时...

这个跟应用系统，国产硬件芯片类型，操作系统和国产数据库都有关系，同等配置下性能会有一些损失，但是损失不会太大，我们测试基本不超过30%。不过可以通过增加节点解决性能问题。总之就是要通过性能实测看是否满足业务系统需求。...

这种大库是很难办的。常用的方法：（1）花力气对原Oracle库进行改造，把表分为历史表和当前表。比如3个月前的数据放1个表或几十张表里，当前交易进行增删改查的作为一个表，给当前交易用；（2）先对历史表进行数据迁移；（3）投产窗口对当前表进行迁移，可能3T里面只有300G~800G左右，这样才能控制投...

谢邀！据我了解，应该是没有的。本人也是希望有，这样可以防止国产数据库出现天大的问题（数据不一致）的时候，我们客户能及早的发现，不至于酿成大错。可是目前国内应该没有这样的异构数据库之间的数据稽核。小厂商都是基于MySQL和PG开发的，不值得大厂去开发工具稽核它们。大厂的数据...

一般是先约几家了解情况、然后功能POC、性能POC、业务测试，最后挑选一家厂商随后就是确定具体的业务上国产数据库，做应用代码改造和兼容性适配、最后上线业务使用国产数据库一般都是先从不重要的外围业务逐步开始使用，自己单位也需要人员有个熟悉的过程...

谢邀！从我们的经验看，灰度迁移是个危险的想法，哈哈！真的，容易把数据搞脏掉，不建议这样做。虽然整体数据迁移，风险高，但是容易保持数据一致性。一旦失败后，可以追日志来找到数据一致点。至于您担心的事情，我个人的意见是：1，提前把国产数据的环境搭好，小库要提前两周，大库要提前一个月；2，在...

根据经验有以下建议：先对Oracle库进行优化改造，对大表改造为分区表，缩小每个分区表的大小。然后为改Oracle库建立ADG读库，将读交易改造至读改ADG库。优化完成后，再进行国产化改造就很方便了。甚至可以分阶段先改造读交易至国产数据库，再改造写交易至国产数据库。最后：如果一个系...