一、前期调研
1、概要信息

关于XXX数据迁移升级，前期调研了解的情况内容如下：

数据库A附加信息：数据量大小约1.8T，700张表左右，源数据库用户总数<800，常用<5。

数据库B附加信息：在一台IBM AIX服务器上安装两个版本的Oracle数据库：9i和10g。需要把数据库9.2.0.8实例的数据迁移到实例oracle 10.2.0.4上。数据大小约200G，之前oracle 9.2.0.8大约有200个表与主数据库A通过CDC进行同步，迁移完成之后依然与之前的主库A进行同步。

2、目标要求

（1）需要把库A（1.8TB）从oracle 9.2.0.4( hp-ux)升级迁移到oracle 10.2.0.4 (AIX)

（2）需要把库B（200GB）从oracle 9.2.0.8( AIX)升级迁移到oracle 10.2.0.4 (AIX)

（3）升级完库A和库B以后，库B需要重新配置CDC同步数据表

（4）停机窗口控制在24小时以内

二、因素分析

此次数据迁移，需要考虑的因素比较多，主要需要考虑的问题包括如下几个方面：

1、风险与可控性

风险与可控不单单指的是迁移升级过程中，更指迁移完毕后的新环境的运行情况(稳定性、性能等)以及对业务系统的支撑情况。所以一个号的迁移工程不仅需要强有力的迁移控制过程，更需要完善的模拟验证机制以及一个有效的回退方案。

2、停机维护窗口

迁移都需要在指定的停机时间内完成，以避免造成业务大面积的中断或者影响。对于高可用环境，需要有良好的迁移方案来尽可能压缩停机时间。

3、安全性

因为客户群体的特殊性，所以需要对迁移的数据做好保密工作，防止数据的丢失和泄露。

三、方案分析

这个案例属于很典型的跨平台、跨版本、大容量且有停机时间要求的高可用数据库迁移案例。国内这样的迁移升级案例其实并不是太多见。受到常规的工具无法满足要求，高级的工具过于复杂的局限，以往的实施方多已使用第三方迁移工具如Sharepex、DSG来进行迁移，虽然能达到相应的目标，但是这对于大多数企业来说，迁移的成本都过高。

以下是通过对oracle自身提供的工具进行一一分析，最终筛选出方案。

1、Exp/imp

它是Oracle 下最常用的数据迁移工具，可以跨平台、跨版本、跨字符集进行数据迁移，且迁移的过程可以对数据进行重组优化。

缺点是数据库数据量太大，时间与进度无法满足要求。

2、Oracle transportable tablespace

它只是拷贝物理文件到目标数据库上，并没有对数据进行重组，所以速度很快。

因为这里源数据库是oracle 9i。9i对使用transportable tablespace有诸多限制。

3、SQL * Loader

SQL* Loader主要用于数据表的迁移，数据仓库方面用的比较多。对于二进制对象等处理方式繁琐。而且后期的工作量比较大，配置控制文件相对来说会比较繁琐。

4、Data Guard

DG速度快，停机时间短。但是11g以下物理DG不支持跨平台、跨版本、跨字符集的升级。

5、Dblink 方式

dblink是在目标数据库通过透明网关建立到源数据库的数据库链接，然后进行数据插入。它对网络可靠性有一定的要求，执行的速度取决于网络带宽与目标数据库的cpu处理速度。经常和其他高级的迁移方式一起配合使用。

6、Oracle streams duplicate

Oracle的流复制方式支持跨版本、跨平台、跨数据库，处理的方式比较灵活。相对于其他工具而言，oracle streams要求的用户停机时间比常规的工具要短，相对来说客户更容易接受。鉴于此案例的规模以及跨平台、跨版本要求应以oracle streams作为主要的数据移植方案。

7、备选方案prebuild MV

Prebuild MV属于高度可自定义的迁移方式，灵活性大。但是它太过复杂，不仅需要使用者精通业务需求与数据库运行机制，还需精通数据库编程，所以只能作为备选方案。

8、备选方案DBUA

对于数据库B，因为其大小只有200G左右，这里可以考虑使用DBUA的方案。这样有一个很明显的好处在于操作相对来说要简单一些，且原来的CDC配置需要改动的地方比直接迁移要少。如果不能满足这个条件则使用expdp/impdp或者dblink技术来完成迁移。

四、方案流程

如下图所示：

五、数据迁移思路

1、对表分级，逐步迁移

对表分级，也就是说并不是所有的用户，所有的表都采用streams复制的方式。

对于业务量不繁忙的用户/表来说, 使用exp/imp或者dblink等常规工具是十分有效的，这样可以减轻整个项目的复杂度，也使得整个项目进度更加可控。

2、 分布实施，增量迁移

基于数据量大，需要停机的时间短。要把所有的数据一次性的迁移到目标数据库是很不现实的。所以我这里给出的方案是分步实施，按照系统的增量迁移。首先可以根据业务把数据库细分为表空间或者用户级数据，把各个步骤细化为一个个里程碑，然后再按照计划逐步推进。

3、以一种方案为主，多种方案辅助迁移

对于数据量在1TB级，且存在多个表空间/用户的情况下，以一种技术为主，其它技术为辅的方式往往更加灵活，也能够提高迁移升级的效率。而且在有备用方案的前提下，如果一种方案不是太适合可以马上考虑切换到另外一种方案。

比如大的库可以通过streams来迁移，比较小的库可以考虑使用expdp/impdp或者dblink来进行迁移。

4、尽量错开用户高峰期

因为迁移是非停机迁移，所以在迁移重要的数据时应该尽量避免用户高峰期，使得对用户的影响最小化。

5、变更之前应该先备份

对数据进行迁移难免会涉及到变更，而变更操作一般来说是有一定的风险系数的，所以在执行变更操作之前需要先备份原有数据，以保证如果变更失败或者出现灾难时，可以退回到之前的场景， 避免数据的丢失。

6、变更后须进行测试

迁移升级完成之后，须进行严格的测试，以保证迁移以后没有数据丢失，数据库及应用能够正常、准确无误的工作。

7、迁移时不能修改数据表结构

迁移期间，不要对迁移的数据表进行任何DDL操作，如：修改表结构等。否则在迁移后可能出现意想不到的错误。