Oracle迁移是数据库运维中一项必不可少的工作，具体到项目层面上则有系统割接、数据库版本升级迁移、数据库主机更换、数据库拆库、数据库合库、测试系统搭建等等各类场景，然而正所谓万变不离其宗，迁移总的来说就是Dataguard、RMAN、底层复制等物理方式以及Datapump、GoldenGate等逻辑方式。本文目的在于从笔者实际参与的各种迁移类项目出发，简明扼要地从宏观的角度数一数迁移类项目中可能遇到的坑。

对于一个核心的系统来说，数据库很可能并不是孤立的，而是涉及应急、容灾、BCV、备份等各个方面，同时这个数据库又可能是别的数据库的数据源的源端或者目标端。当进行这种复杂系统的迁移时，务必考虑到这些方面。

笔者进行参与的某运营商数据库升级项目是通过GoldenGate方式实现换机器方式升级的，这个运营商的某核心库则相当复杂了，其涉及的外围因素如下：

1. 通过赛门铁克底层同步库软件实现的容灾库；

2. 通过赛门铁克底层同步库软件实现的BCV库；

3. 通过GoldenGate软件实现的应急系统。

由于涉及的数据库较多，我们在处理这个项目时，采用了提前升级应用系统，同时升级主系统以及容灾系统，最后升级BCV系统的方式进行调配。

迁移工作应当尽可能降低对现网运维工作的影响，由于迁移工作而引发的现网系统出现问题是客户很难接受的事情，然而在实际的迁移工作中，因为疏忽大意或者对系统架构不了解而导致问题。

对于需要从源端数据库直接进行DATAPUMP等方式数据导出的迁移工作而言，需要注意导出工作对源端造成的CPU、内存、IO、文件系统等影响相信很多DBA都能想到，但在后续的传输以及入库中，则反而容易遇到不了解系统架构的问题了，例如下述两个例子：

1. 网络未分离，过多ftp进程并发传输占用网络带宽，进而影响应用系统；

2. 目标数据上没有应用，但其存储与现网是共用的，大并发进行数据导入导致影响现网。

对于目标端本身就是生产系统的情况，则操作更得小心翼翼了，除了常规的CPU、内存等指标外，还得注意归档、表空间等细节，遗漏其中一项都可能引发故障，这种迁移只能步步为营，慢慢搞了。

迁移工作的完成需要应用厂商和数据库的相互支撑，然而，从笔者亲身的项目经验来看，偶尔也会遇到个别不靠谱的开发人员，进而影响整个项目的推进，下面是笔者遇过的几个例子：

1. 割接后跑过来抗议说新库和旧库数据不一致，核查原因发现旧库应用未停止干净，幸亏提前做了监控，否则问题说不清；

2. 未正确修改应用配置，导致连错实例，影响进度；

3. 前期未充分测试，在升级期间才发现，处理起来相当被动。

与上面相比起来，数据库本身的问题就更复杂了，需要通过项目经理来积累了，下面是笔者总结的类型：

1. SQL语句性能类，例如版本变更导致的语句性能退化；

2. 对象及权限类问题，例如对象编译不通过，这种问题留到割接期间会显得相当被动；

3. JOB调度问题，例如实例重启导致的job多余调度导致脏数据；

4. 数据库管理问题，例如监控或者备份机制跟不上；

5. 数据库配置问题，例如参数设置不合理；

6. 特殊对象类型问题，例如不常用的QUEUE仅迁移而未START导致应用报错。