ITPub博客

首页 > 数据库 > Oracle > Oracle大型数据库迁移

Oracle大型数据库迁移

原创 Oracle 作者:一眼泉水 时间:2016-01-04 13:21:21 0 删除 编辑

    1 现状及任务背景

1.1 任务

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

相应的流程规划如下:

阶段

时间

工作内容

制定初步迁移方案

1

起草初步的迁移方案,包括:

(1)       需要迁移的软硬件环境确认

(2)       需要迁移的数据类型、数据量调查

(3)       数据按照变化频率划分为历史和当前数据

(4)       规划迁移时间和关键步骤

(5)       迁移过程和相关软件的配合

(6)       迁移过程中生产系统的配合

(7)       数据校验策略

(8)       迁移回退策略

 

迁移第一阶段测试

1

DSG公司在测试数据同步软件:

 

一、需要的环境准备:

(1)       确定用于测试的数据源:最好是直接的生产系统或者是生产系统的克隆系统。

(2)       确定用于测试的目标数据库:DSG将对所有的数据进行一次迁移测试,因此要求目标端的数据库的容量足够。

(3)       目标端的环境准备:

安装oracle数据库

Create database

Create tablespace

DSG在目标分配一个100GB200GB的文件系统。

(4)       源端的环境准备:

DSG在磁盘阵列上分配一个20GB以上的文件系统

 

二、测试的主要内容:

(5)       按照预先制定的迁移方案进行测试,对迁移方案进行验证,并且对不完善的地方进行补充。

(6)       测试DSG 同步软件是否支持所有的数据,找出不支持的数据,或者迁移有风险的数据,以形成特殊预案。

(7)       得到真实的性能数据,包括数据初始化性能、数据比对性能等。

 

迁移第2阶段测试

1

主要内容:

进行正式迁移之前的真实模拟,要求就在将来要迁移的老系统和新系统上进行。

 

一、环境准备

(1)       按照设计安装好新系统环境

(2)       协调在生产系统进行直接测试

(3)       在生产系统上为DSG分配20GB以上空间

(4)       协调应用软件在新系统上的模拟测试

 

二、测试内容

(1)       DSG在正式系统上进行数据迁移

(2)       迁移完成后,应用系统从业务层面对迁移的数据进行校验

(3)       校验完成后,应用在系统上进行模拟测试

(4)       对迁移方案进行最后的修改和定稿

正式迁移

1

根据最后形成的迁移方案进行迁移。

 

1.2 现状

1)                  数据量大

数据库table   张,数据量有  G,索引  GLob数据  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      加大pga812GB

n      加大undo100GB/实例

n      加大db_file_multiblock_read_count

n      加大sort_area_size参数

n      设置非归档模式

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

l   导入生产库的所有用户schema的空结构(不导入数据),完成表、索引、约束、sequencetrigger           procedurepackagedatabase 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)中去。该过程需要时间较长,根据前期演练的情况,迁移顺利和所需时间估计如下;

步骤

数据分类

存数据量

表数量

索引数量

处理方式

估计时间

 1

静态数据

____G(纯数据)

 

 

realsync

 

 

 2

动态数据

____G(纯数据)

 

 

realsync

 

 

 3

LOB数据

____G(纯数据)

 

 

realsync

 

 

 4

特殊表数据

____G(纯数据)

 

 

dblink

 

 

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

步骤

数据分类

存数据量

表数量

估计传输数据量

处理方式

估计时间

 1

静态数据

 

 

 

Realsync

 

 

 2

动态数据

 

 

 

Realsync

 

 

 3

LOB数据

 

 

 

Realsync

 

 

4

特殊表数据

 

 

 

 

 

 

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


3.1.2增量数据同步:

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

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

l  静态数据、

l  动态数据

l  特殊数据

3.2        统计信息迁移

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

3.3        应用迁移

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

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

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

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

n  启动所有的Trigger

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

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

 

4章 数据验证

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

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

n   数据一致性验证;

n   应用验证;

n   性能验证

4.1 DSG RealSync 提供的比较工具

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

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

数据验证

数据验证分类

存数据量

验证方式

估计时间

静态数据

____G(纯数据)

Dsg realsync比对工具

平时

 

动态数据

____G(纯数据)

Dsg realsync比对工具

平时

 

特殊数据

____G(纯数据)

Dsg realsync比对工具

平时

 

特殊表数据

____G(纯数据)

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)      若新库里面的数据不可用,则暂停后台业务,通过业务部分补录新库里面办理的业务,保证各种数据一致。

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24695024/viewspace-1970676/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-10-02

  • 博文量
    42
  • 访问量
    116166