某省电信核心库迁移方案

第1章 现状及任务背景

1）                   停机时间有限

某核心数据库的迁移停机时间最长不能超过3小时，这包括了业务启停及测试时间，

即真正用于数据库迁移停机的时间大约2-3小时。

第2章 前期准备

2.1                 迁移方案确定

      根据前期的调研工作, 确定采用第三方软件DSG RealSync作为此次某核心数据库迁移的方案。

2.2                 数据库层面

2.2.1 原库准备

l            清理/区分无用的表

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

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

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

l            根据生产，需要把第二个节点的archivelog nfs挂在到第1个节点上来（目录可以自己定义）

2.2.2 新库准备

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

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

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

l            修改所有表的属性为nologging

l            禁用所有约束

l            加大sort_area_size >100MB

l            建立到原库的database link

2.2.3 表分类

    按照数据表的类型，分成静态表（不经常变化的表），同态表（时时变化的表）。

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

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

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

 

第3章 迁移步骤

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

3.1                  数据库迁移时间安排

时间	任务	是否影响业务	需要配合人员
1.5-2个小时	数据环境调查，以及软件安装	不影响	系统管理员，数据库管理员
4-12小时（提前一天）	数据首次同步(共计939.29GB数据)	不影响（在业务量较小的时候做，以避免影响业务，占用10-30%之间的cpu）	系统管理员
2-6小时	数据库变数据增量	不影响业务。	系统管理员
2-6小时	实际数据比对	动态数据比对，停业务（2-6小时） 静态数据比对，不影响业务	数据库管理员，系统管理员
30分钟	比对对象，以及启动trigger,job等	在停业务比对数据期间操作	数据库管理员

 

3.2                数据库的迁移步骤

3.1.1数据初始化同步：

在原系统业务不中断的情况下，通过RealSync的首次同步功能，依次将原系统中的所有表（Table）中的记录复制到新系统的对应表（Table）中去。大约需要3-7小时，不影响业务。

根据业务的需求，分成2套分别复制，防止增量日志太大：

l        普通数据

l        LOB数据

3.3                应用迁移

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

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

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

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

n          启动所有的Trigger，Job

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

 

第4章 数据验证

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

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

n            数据一致性验证；     dsg提供的比对脚本验证

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                        数据一致的验证

数据校验从应用层面，可以抽样进行，对生产环境和迁移之后环境上的工单，用户信息，某核心信息等进行比对。

由于通过人工进行，若单靠联创和某核心中心进行测试，数据采样过小，对数据校验不能起到实际意义，建议这块的校验由联创和某核心中心准备测试环境和测试方案，由分公司组织人员进行测试，这样覆盖面大，人员多，周期短，效果也会相对好一点。

人员：待定

预计用时：待定

4.3.4                        同步统计信息

第5章        迁移回退

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

5.1                  数据库迁移回退的情况

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

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

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

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

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

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

5.2                  回退步骤

回退有如下两种情况：

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

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

a)        停止业务办理

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

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

d)       若新库里面的数据不可用，则暂停后台停机催缴业务，通过营业厅前台补录新库里面办理的业务，保证各种数据一致（在割接后的几天中将保留前台办理业务的工单）。

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