某省移动核心数据库迁移方案

第1章 现状及任务背景

任务

需要将某核心数据库从当前平台(AIX+ORACLE9.2.0.7)迁移到新平台(HPUX+ORACLE9.2.0.7)。

现状

1）                  数据量大

目前数据库总体大小约为4TB，其中表约2.5TB，索引及其他对象1.5T。共有表40061个，索引42334个，最大用户下表数量甚至达到24981个。某核心数据库承担着boss系统数据存储、管理的核心任务。

2）                  跨平台

某核心数据库目前采用IBM P690+AIX5.2的主机平台，由于该主机CPU已满配,无法进一步扩容，因此需更换新主机已满足平台扩展性的要求。新主机为HP SUPERDOME+HP_UX11.23。此次迁移即是将某核心数据库从IBM P690主机迁移至HP SUPERDOME 主机。

3）                  停机时间有限

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

即真正用于数据库迁移的时间大约3－5小时。

4）                  数据准确性要求高

由于是某核心数据库记录的都是客户资料、欠费缴费信息和计费信息。如果出现数据准确性问题，将导致整个营业收费系统，帐务处理系统的紊乱，引起客户的投诉。

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

 

第2章前期准备

2.1  迁移方案确定

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

 

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                         设置非归档模式

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

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

l           修改所有表的属性为nologging

l           禁用所有约束

l           建立到原库的database link

 

应用层面

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

迁移演练

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

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

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

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

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

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

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

最近迁移演练已经完成, 数据已经全部迁移到新的平台数据库中, 经过亚信工程师在应用层面的功能性测试,目前没有发现异常情况. 底层的数据验证工作还在进行中。

 

第3章迁移步骤

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

3.1 数据库的迁移步骤

3.1.1数据初始化同步：

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

步骤	数据分类	存数据量	表数量	索引数量	处理方式	估计时间
1、	普通用户	225G(纯数据)	7000	5752	realsync	平时晚上	8小时
2、	zk,zg,kt,zc用户当前数据	800G（纯数据）	12049	9818	realsync	平时晚上	14小时
3、	zk,zg,kt,zc用户历史数据	800G（纯数据）	15591	24806	realsync	平时晚上	14小时
4、	压缩表数据	120G（纯数据）	4589	6698	dblink	平时晚上	18小时
5、	所有的对象	所有的存储过程，触发器等	4204		realsync	平时晚上	1-2小时
6、	物化视图		1个TJ.AAA_M		realsync	平时晚上
7、	特殊表处理，col#=0的表	25G（纯数据）	21	54	dblink	割接当晚	2小时

 

 

3.1.2增量数据同步：

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

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

l       普通用户、

l       特殊用户

3.2           应用迁移

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

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

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

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

n         启动所有的Trigger，Job

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

 

第4章数据验证

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

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

n           数据一致性验证；

n           应用验证；

n           性能验证

4.1 DSG RealSync 提供的比较工具

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

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

 

 

数据验证	数据验证分类	存数据量	验证方式	估计时间
	普通用户（重要表）	225G(纯数据)	Dsg realsync比对工具	平时	14小时
	普通用户（普通表）		Dsg 脚本	平时
	zk,zg,kt,zc用户当前数据	800G（纯数据）	Dsg realsync比对工具	平时	40小时
	zk,zg,kt,zc用户历史数据	800G（纯数据）	Dsg 脚本	平时	40小时
	所有的对象	所有的存储过程，触发器等	Dsg 脚本	平时	1小时
	压缩表数据	120G（纯数据）	Dsg 脚本	割接当晚	5小时
	特殊表处理，col#=0的表	25G（纯数据）	Dsg 脚本	平时	2小时

上述数据验证工作除了压缩表数据的核对需要在割接当晚进行，其它的数据验证在平时数据的同步的过程能够同步进行，都能够在一周时间内完成。

4.2 ORACLE数据库层的比较

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

4.3 应用层面的数据验证

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

4.3.1功能测试

功能测试主要在数据库迁移之后，对BOSS系统的功能做全面测试，测试内容主要包括如下几个大的模块，详见附件3：全业务测试覆盖表

前台测试，包括业务办理，查询及统计

应用后台测试，包括工单，停开机，暂拆，欠拆，冲销。

数据库存贮过程测试，各种后台统计，积分结算等。

其他模块，包括PRM，渠道，客服接口及IVR查询，各种接口功能，计费及帐务处理。

人员：待定

预计用时：待定

4.3.2          性能测试

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

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

人员：待定

预计用时：待定

  4.3.3   数据一致的验证

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

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

人员：待定

预计用时：待定

第5章        迁移回退

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

5.1           数据库迁移回退的情况

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

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

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

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

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

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

5.2           回退步骤

回退有如下两种情况：

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

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

a)       停止业务办理

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

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

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

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