应用和数据迁移方案.docx

该【应用和数据迁移方案 】是由【雨林书屋】上传分享，文档一共【13】页，该文档可以免费在线阅读，需要了解更多关于【应用和数据迁移方案 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。.

因为xxx生产作业是24小时不中断运作的,所以要求系统能连续运转,并
拥有很高的安全靠谱性,用户希望在以最小的系统停机时间达成生产系统迁徙工
作。本次系统迁徙工作的最大的风险点和难点在于在有限的停机时间内达成数据
库的迁徙工作。

数据库系统数据量较大,而且应用系统的可用性要求极高,所以此次升级要求在有限的停机时间内,最大限度的降低风险、数据库业务在新的主机和储存系统上能够正常运转。为了尽可能减少业务系统的停机时间,保证数据库迁徙工作的顺利达成,我们鉴于过去实行的数据库迁徙成功事例(,迁徙时间不超出15分),经过严格的数据库迁徙测试,提出了采纳数据库Dataguard
技术的数据迁徙。
采纳数据库Dataguard技术的数据迁徙的特色:
对业务的影响小,switchover到新主机的时间小于10分钟
一旦新数据库出现问题能够方便的回切到本来的数据库,不丢掉差异数据
采纳数据库Dataguard技术的数据迁徙的主要步骤以下:
在新主机上安装Oracle9i数据库软件
在新主机上配置Dataguard数据库(物理standby)
利用DataGuard技术,主数据库不停的将新产生的数据库归档日记传输到新主机并将这些归档日记应用到standby数据库,实现主备数据库之间的数据同步
系统割接时期只需将新主机上的standby数据库切换为主数据库即可(switchover的时间小于10分钟)
一旦新系统上数据库运转出现问题只需将数据库切换回本来主机上即可,不会丢掉任何数据
.
.


保证公司生产及业务系统运转的安全性、连续性
战胜原有系统缺点
汲取合用的系统新特征
迁徙工作必定波及到数据库系统的扰动,所以减少关于正常业务系统的冲
击,保证它的连续性和安全性是第一个出发点,数据库系统是业务系统的基础,
认真准备和设计数据库迁徙是开始的第一步。
迁徙到更新版本的工作也是纠正原有系统内含的错误的优秀时机,这个原则
相同也合适于任何软件系统和硬件设备。

Oracle9i到Oracle10G的迁徙有三种方式:
使用export和import
长处:经过导出和导入方式对数据库储存构造进行重整有助于减少
数据库碎块
弊端:关于超出150G以上的数据库,采纳exp/imp方式的停机时间
很长
使用Migrate脚本
长处:速度快,一般在30分钟内能达成脚本升级
弊端:一旦升级后就没法回退
使用Migrate导游工具(DBUA)
长处:速度快,一般在30分钟内能达成脚本升级
弊端:一旦升级后就没法回退,容错性较差
我们综合考虑了数据库规模、停机时间、升级风险和过去的成功事例后,我们建议采纳数据库升级脚本方式直接升级迁徙后的数据库,
.
.


为了降低项目实行的风险,我们建议将整个系统迁徙和升级项目拆分为五个
阶段:
准备阶段
准备阶段需要达成搭建新系统环境,是整个系统迁徙项目成功的基石,主要
工作包含安装操作系统、系统参数调整、储存及LVM设计和规划、MS/SG规划和
实行等
测试阶段
因为数据库升级采纳脚本直接在生产库上实行,所以齐备仔细的测试工作是整个项目成功与否的重点,在测试阶段我们需要达到以下目的:
考证迁徙方案的可行性
解决迁徙测试过程中碰到的错误
依据测试的结果调整迁徙过程
对整个系统迁徙过程做进一步的优化
数据库迁徙阶段
为了尽可能的减少系统停机时间数据库的迁徙工作,我们计划采纳Oracle9iDataguard技术:将数据库热备份恢复到新主机,配置主备节点的数据库归档日记同步,系统割接的时候只需做switchover操作将新节点上备用数据库角色切换为主数据库即可。
数据库迁徙到新节点后将应用系统也切换到新数据库,在新系统上运转一段时间,假如发现新节点上数据库或主机出现问题,能够方便的回切到本来的数据库,不丢掉任何数据。
数据库升级阶段
数据库升级因为直接在生产数据库上履行升级脚本,一旦升级失败对业务影响较大,所以其实行的前提是:
测试阶段数据库升级测试成功
对升级风险有预判和应急举措
.
.
整个数据库升级时间在用户可接受的范围内
在数据库升级前一定有个最新的、可用的数据库全备份数据库迁徙升级后的工作
数据库迁徙升级后的工作包含数据库全备份、主机和数据库性能监控等

依据以上步骤整理的该项目实行计划表格以下:
时间
工作内容
负责单位
配合单位
准备阶段
系统环境调研
天玑科技
xxx
新主机系统盘做
mirror
天玑科技
安装HPDP备份软件
天玑科技
双机HPMC/SG规划及配置
天玑科技
主机系统参数、卷组、文件系统及数据库配置
天玑科技
参数检查
测试阶段
实行Dataguard
数据库迁徙
天玑科技
应用测试
HPMC/SG双机切换测试
天玑科技
实行数据库升级测试
天玑科技
应用测试
HPMC/SG双机切换测试
天玑科技
数据库迁徙阶段
数据库全备份
天玑科技
在新主机上创立
dataguardphysical
standby
天玑科技
db
配置datagurad
使得主备数据库之间归档日记
天玑科技
同步
停应用
xxx
生产数据库切换为physicalstandbydb
天玑科技
在新主机的原physicalstandbydb
切换为主
天玑科技
数据库
应用系统测试及有关应用连结数据库配置修
天玑科技
改
MC/SG切换测试
天玑科技
DataProtector
数据库备份配置
天玑科技
系统上线
天玑科技
数据库升级阶段
Oracle9i数据库全备份及数据库软件备份
天玑科技
.
.
数据库升级前的检查天玑科技
数据库参数调整天玑科技
停应用xxx
运转数据库升级脚本天玑科技
编译数据库无效对象天玑科技
重启数据库,应用系统测试天玑科技
DataProtector数据库备份配置天玑科技
HPMC/SG切换测试天玑科技
系统上线天玑科技
数据库升级后的工作
主机性能监控天玑科技
数据库性能监控天玑科技
Oracle10g数据库全备份天玑科技


假如在规划的时间点以前没有达成实行准备阶段的任务,实行时间顺延,在
保证准备工作就绪的前提下才进行实行工作。
天玑科技将在该项目开始实行行进行全面性的系统软、硬件健康检查,保证
在项目实行前系统完满。

本次系统迁徙实行的原则是保证系统在规划的实行时间段以外能够正常运
行。为保证系统在发僵硬件或软件故障时能够实时获取技术响应,需要协调各相
关人员到位。在实行过程中操作步骤拥有可逆性,保证以外发生的时候可将系统
快速回退到最先状态。系统和数据在实行前都做最新的备份。
因为在正式数据库迁徙以前,已经做过测试迁徙的工作,应当能够估量出迁
移大体所需的时间。假如因为一些不行测原由致使迁徙过程异样迟缓或停止,数
据库升级所需时间超出原准时间,我们能够快速将数据库系统恢复到最先状态。
.
.

因为该项目实行过程中,只有在确认了Oracle数据库迁徙成功而且Oracle
9i成功升级到10G成功后,才翻开对数据库数据的增添、删除、改正等数据库
更改操作,不然全部表空间均设置为readonly状态(或许经过调整Websphere
中间件,停止对后端数据库的写操作以便限制成功迁徙、升级以前的Oracle数
据库的更改),所以,系统迁徙实行后的异样状况下,因为迁徙前后均不波及到
数据库数据的更改,严格来说能够简单经过恢还原环境节点担当中间件连结即可
恢复为原有环境。
另一方面,先期的充分测试也是对该应急举措的保障性测试。
.
.

经过天玑科技多年以来专业服务项目实行的经验,我们建议xxx在该项目的实行过程中
应把风险管理贯串整个项目,天玑科技充分考虑了可能造成项目失败的全部要素和预防措
施,以及发生时的管理方法,以此作为该项目的风险躲避方案。

不行控制的风险
重要政策出台,影响公司发展;
重要社会事件发生
自然灾害致使机房,机器在升级过程中受损可控制的风险
任意更改项目目标、范围、时间;
任意调用项目人员,使其没有足够的参加时间;
不可以实时决议、实时确认项目阶段报告;
不恪守项目纲领的要求。
可能的风险
数据库版本升级带来的与应用不兼容,包含性能方面和功能方面
数据库版本升级带来的现有硬件不兼容,比方带库
数据库版本升级带来的现有软件不兼容,比方备份软件,监控软件
数据库版本升级带来的管理人员培训需要
以上从系统的各个方面简单描绘了各样种类的风险,详细风险及防备举措将
经过下边依照升级工作生命周期的阶段性剖析来详细描绘,将涵盖可能产生的各
方面风险。

我们依据过去数据库Oracle9i到Oracle10G的升级的成功经验,关于xxx改造项目实
施过程中可能出现的以下风险点及提出了对应的应付举措:
.
.
风险一:直接在生产库上涨级
使用脚本升级方式,也就意味着最后的正式升级只好是在产
品库上直接进行,那么不论以前做过何种测试,都可能因为不测
风险
原由致使升级失败(比方升级过程中不测断电,硬件发买卖外破坏等),升级失败便可能意味着生产库的不行用。
安妥的备份策略是升级工作的后备军。只需有有效的数据库
防备措备份,便可以缜密细致地进行升级工作。而当前帐务数据库在无
施锡新区有异地备份的容灾库,这更是一种有力的保证,让升级工作无后顾之忧。
风险二:生产库恢复时间
假如升级失败,那么可能需要恢复生产库以应付次日的业
务,因为挪动的数据量很大,即便是使用增量备份的方法也需要
风险
起码恢复一天的归档日记,那么假如万一升级出现问题,可否在
升级窗口期内达成数据库恢复是一个风险。
安妥的备份策略不只是包含备份的效率,相同也包含恢复的
防备措效率,一个只好备份而没法在规准时间内恢复的备份策略是不合
施格的,也是没存心义的。所以相同,拟订有效的备份策略同时进
行同比数据量的恢复测试是必需的风险防备举措。
风险三:数据库服务器之间版本不一致
在一段时间内,Oracle9i和Oracle10g将同时存在于数据
风险库系统中,各个系统之间存在着不一样版本数据库数据交互的现
象,可能产生数据不兼容的状况。
详细考虑升级的先后次序,哪套系统先升级,哪套系统后升
防备措级。尽量使有数据交互的系统在同一时刻进行升级。
施假如没法做到同一时刻升级,那么需要进行升级测试和升级
预演,保证在测试环境中不一样版本的数据库之间交互是没有问题
.
.
的。
风险四:客户端和服务端版本不一致
客户端(Websphere中间件)和服务端(Oracle10G)相同
风险在一段时间内存在着版本不一致的现象,服务端可能没法正常处
理客户端恳求,而客户端也可能没法正常接收伏务端数据。
关于可能存在的客户端和服务器端版本问题,在升级以前必
须有测试环境进行全面测试,将一般的功能问题在测试环境中就
防备措
予以解决,尽量减少产品环境中的升级风险。
施
关于已知故障,能够依照天机科技对应的故障解决方法,经过Patch和设置Event来防止产生CoreDump。
风险五:Failover
关于网卡不支持单机多网卡之间的Failover
,过去的网卡
风险
Failover设置需要改动。
防备措
建议使用操作系统功能将多块网卡捆绑为一个
NIC设备,以
施
此防止网卡的单点故障。
风险六:升级Pro*C程序版本
在新版本数据库下可能没法正常编译;
假如没法正常编译,需要原开发人员的技术支持,但
风险是原开发人员可能因为人员改动而没法找到;
假如需要其余开发人员改正,需要保证源代码还存在,而且同时要考虑现任人员的改正能力。
关于这样的状况只有经过测试才能确认能否兼容,尽量详细
防备措
地进行升级测试和升级预演是防备问题出此刻产品环境中的必
施
要手段。
风险七:不升级Pro*C程序版本
.
.
旧版本Pro*C连结新版本数据库可能会出现非展望的错误
风险
结果或许低下的应用性能。(需要确认xxx
应用系统能否采纳该
选项)
在Oracle顾问参加的某项目中,客户就直接使用9i版本的
Pro*C程序连结Oracle10g数据库,获取了跟过去相同的功能和
防备措
性能。可是因为Pro*C程序的多样性,所以一定慎重测试。关于
施
这样的状况也只有经过测试才能确认能否兼容,
尽量详细地进行
升级测试和升级预演是防备问题出此刻产品环境中的必需手段。
风险八:疲惫操作
升级工作比较紧张,高强度的工作也简单令人疲惫,而在紧
风险
张和疲惫的状态下,是比较简单产生人为失误的。
升级工作一定由起码2人共同达成;
防备措依照升级预演的文档认真操作;
施重要命令一定有共同工作人员确认以后才能够输入;
完美的备份让升级工作无后顾之忧。
风险九:履行计划稳固性
Oracle10g在创立完数据库以后会产生一个自动按期采集
数据库对象统计信息的Schedule,默认是在周一到周五的每日
风险夜晚10点以及周六的清晨0点,关于履行计划已经比较稳固的
产品环境来说,每日采集统计信息是没有必需的,同时还存在可
能改变履行计划的隐患。
防备措禁用统计信息自动采集。
施增强性能监控。
风险十:HighVersionCount

风险
查增强,所以在Cursor_sharing=SIMILAR或许FORCE的系统
.