Oracle向分布式数据库迁移？

一、架构类问题
涉及应急、容灾、BCV、备份等各个方面
二。资源问题
迁移工作应当尽可能降低对现网运维工作的影响，由于迁移工作而引发的现网系统出现问题是客户无法接受的，避免因疏忽大意或对系统架构不了解而导致此类问题。
对于需要从源端数据库直接进行DATAPUMP等方式数据导出的迁移工作而言，需要注意导出工作对源端造成的CPU、内存、IO、文件系统等影响，在后续的传输以及入库中，容易遇到不了解系统架构的问题了，例如：

1. 网络未分离，过多ftp进程并发传输占用网络带宽，进而影响应用系统；
2. 目标数据上没有应用，但其存储与现网是共用的，大并发进行数据导入导致影响现网。
   对于目标端本身就是生产系统的情况，则操作更得小心翼翼了，除了常规的CPU、内存等指标外，还得注意归档、表空间等细节，遗漏其中一项都可能引发故障，这种迁移只能步步为营，慢慢来。
   三 .难以省心的应用
   迁移工作的完成需要应用厂商和数据库的相互支撑，偶尔也会遇到个别不靠谱的开发人员，进而影响整个项目的推进。如：
3. 割接后跑过来抗议说新库和旧库数据不一致，核查原因发现旧库应用未停止干净，幸亏提前做了监控，否则问题说不清；
4. 未正确修改应用配置，导致连错实例，影响进度；
5. 前期未充分测试，在升级期间才发现，处理起来相当被动。
   四.五花八门的数据库问题
   与上面相比起来，数据库本身的问题就更复杂了，需要逐渐积累了，相关类型总结：
6. SQL语句性能类，例如版本变更导致的语句性能退化；
7. 对象及权限类问题，例如对象编译不通过，这种问题留到割接期间会显得相当被动；
8. JOB调度问题，例如实例重启导致的job多余调度导致脏数据；
9. 数据库管理问题，例如监控或者备份机制跟不上；
10. 数据库配置问题，例如参数设置不合理；
11. 特殊对象类型问题，例如不常用的QUEUE仅迁移而未START导致应用报错。