第1章 现状及任务背景

1.1 任务

需要将数据库从当前现有平台迁移到新系统平台。

相应的流程规划如下：

1.2 现状

1）                  数据量大

数据库table   张，数据量有  G，索引  G，Lob数据  G。

2）                  跨平台

此次迁移即是将数据库从_win2003 server 32位_主机迁移至_win2003 server 64位_主机。

3）                  跨数据库版本

从oracle9.2.0.8.0 迁移到oracle10g。

4）                  停机时间有限

有数目前数据库是核心系统，迁移时间有限。

5）                  数据准确性要求高

由于是数据库记录的都是重要信息。如果出现数据准确性问题，将导致整个数据库系统的紊乱。

因此，此次迁移工作具有“跨平台，跨数据库版本，大数据量，停机时间短，数据准确性要求高”

第2章 前期准备

2.1  迁移方案确定

      根据前期的调研工作, DSG提供数据迁移方案。

2.2数据库层面

2.2.1 原库准备

l   清理/区分无用的表

l   整理出可以不停应用，预先迁移的历史、静态表（以下称第一阶段迁移的表）的列表

l   整理出需要停应用才能迁移的其它表（以下称第二阶段迁移的表）的列表

l   整理出第二阶段迁移的表的索引以及约束的ddl，并修改nologging以及并行属性

2.2.2 新库准备

l   为导入及建索引优化调整新库的参数：

n      加大pga到8～12GB

n      加大undo到100GB/实例

n      加大db_file_multiblock_read_count

n      加大sort_area_size参数

n      设置非归档模式

l   新库的表空间名与大小要与原库完全一致

l   导入生产库的所有用户schema的空结构（不导入数据），完成表、索引、约束、sequence、trigger、           procedure、package、database link等的创建，注意进行第二阶迁移前需先drop第二阶段迁移的表的索引和约束，另外所有的用户sequence在第二阶段迁移完成后需要重建。

l   修改所有表的属性为nologging

l   禁用所有约束

l   建立到原库的database link

2.3 应用层面

搭建基于新库的应用环境，在新库上测试应用

2.4迁移演练

迁移前的充分演练非常重要：

l   最大限度的优化迁移步骤

l   比较真实的评估各迁移步骤的消耗时间

l   了解基于新库的应用是否能正常运行

2.4.1从生产库导出空结构到新库

用于在新库创建所有用户、表及附属对象的定义。

2.4.2测试基于新库的应用是否正常

经确定迁移演练已经完成后, 并且数据已经全部迁移到新的平台数据库中,由因为无部分在应用层面的功能性测试,目前没有发现异常情况。（全业务测试覆盖表）

. 底层的数据验证工作：首先对表的数据进行count，如果两边count一致，再做minus比对。如果count不一致，默认为失败。在比对过程中，处理出错的表。

第3章 迁移步骤

根据前期迁移演练的结果，迁移步骤如下：

3.1 数据库的迁移步骤

3.1.1数据初始化同步：

在原系统业务不中断的情况下，通过RealSync的首次同步功能，依次将原系统中的所有表（Table）中的记录复制到新系统的对应表（Table）中去。该过程需要时间较长，根据前期演练的情况，迁移顺利和所需时间估计如下；

根据当前系统估算同步的时间：

在平时数据中（割接前），需要预留出3-5个个晚上的空闲时间能够对同步过程中出现的问题进行处理。以上总需要  时间。

3.1.2增量数据同步：

将在大数据量同步过程中新增加的记录复制到新系统上，并且在割接前保持新系统与原系统的记录实时同步；

根据业务的需求，分成3套以上分别复制，防止增量日志太大，分析跟不上：

l  静态数据、

l  动态数据

l  特殊数据

3.2        统计信息迁移

等完成所有的数据迁移之后，开始统计信息的迁移，确保迁移后的SQL执行计划和原来一样，尽量降低迁移之后出现性能问题。

3.3        应用迁移

    首先停止原系统的业务进程；

n  更改相应的数据连接配置

n  然后等待RealSync中的复制队列完全结束后，在停止RealSync的复制进程。

n  等待RealSync对压缩表的验证完成。

n  启动所有的Trigger

n  Job需要单独处理，只能有各自用户来单独建立。

n  在新系统上启动业务进程。

第4章 数据验证

数据库迁移结束后，最主要的是对迁移的数据进行验证。

数据验证包括两个方面内容：

n   数据一致性验证；

n   应用验证；

n   性能验证

4.1 DSG RealSync 提供的比较工具

DSG RealSync提供了数据一致性比较手段。该功能可以比较在某个时间点源系统和目标系统的数据是否完全一致。

比对的步骤和估计的时间如下表：

4.2 ORACLE数据库层的比较

由oracle工程师在oracle层面进行数据一致性的比较

4.3 应用层面的数据验证

由应用工程师提供在应用层面的数据验证工作，包括数据一致性的验证、功能性验证、性能验证3个方面的验证。

4.3.1功能测试

功能测试主要在数据库迁移之后，对整个系统的功能做全面测试。

人员：

预计用时：

4.3.2          性能测试

性能测试是在功能正确的前提下，对业务办理的速度，开通速度等跟数据库迁移相关的业务进行测试，校验数据库迁移之后数据库的存取速度是否有影响。

测试不采用压力测试的方式，不考虑各种并发情况，在前台进行正常的业务办理，通过后台日志提取各种业务的办理时间，跟正式环境上相同业务的办理时长进行比较，若时长低于正式环境，则认为数据迁移基本没有问题。

人员：

预计用时：同功能测试同时进行

  4.3.3   数据一致的验证

数据校验从应用层面，可以抽样进行，对生产环境和迁移之后环境上的数据.

由于通过人工进行，若单靠业务工程师和支撑中心进行测试，数据采样过小，对数据校验不能起到实际意义。

对于静态数据可在切割前比对完成，对于大量动态数据只能在切割前的停业务期间进行。整个验证时间需要进一步测试。

人员：

预计用时：

第5章        迁移回退

在迁移的过程中，会产生很多问题，如果迁移数据不一致将会严重影响业务的使用，数据库迁移将进行回退。

5.1        数据库迁移回退的情况

 数据库迁移在如下情况下是不成功的，将进行回退：

（1）       在数据验证正确，没有发现数据丢失，但是业务办理不成功，功能测试不能完全通过；

（2）       在数据验证正确，没有发现数据丢失，但是业务性能显著下降；

（3）       数据验证不正确，找不到原因；

（4）       数据迁移在规定时间内不能迁移完成。

以上情况将进行数据库迁移的回退

5.2        回退步骤

回退有如下两种情况：

（1） 若迁移之后数据校验立即发现数据不对，则应用系统指向不变，依然用老系统进行业务受理即可。

（2） 若业务已迁移，已有业务办理一段时间之后发现数据差异较大，且没有办法通过再次同步解决的，需   要考虑回退处理。大概步骤如下：

a)       停止业务办理

b)      更改配置，指向旧系统

c)       若新库里面的新数据可用，则采用后台同步的方式进行处理。

d)      若新库里面的数据不可用，则暂停后台业务，通过业务部分补录新库里面办理的业务，保证各种数据一致。

校验检查测试完成后，恢复后台服务。