应⽤和数据迁移⽅案计划
第⼀章.应⽤和数据迁移⽅案
由于xxx⽣产作业是24⼩时不间断运作的,因此要求系统能连续运⾏,并具有很⾼的安全可靠性,⽤户希望在以最⼩的系统停机时间完成⽣产系统迁移⼯作。本次系统迁移⼯作的最⼤的风险点和难点在于在有限的停机时间内完成数据库的迁移⼯作。
1.1 数据库迁移的解决思路
xxx数据库系统数据量较⼤,并且应⽤系统的可⽤性要求极⾼,所以此次升级要求在有限的停机时间内,最⼤限度的降低风险、数据库业务在新的主机和存储系统上能够正常运⾏。为了尽可能减少业务系统的停机时间,保证数据库迁移⼯作的顺利完成,我们基于以往实施的数据库迁移成功案例(1.1T的数据量,迁移时间不超过15分),经过严格的数据库迁移测试,提出了采⽤数据库Dataguard 技术的数据迁移。
采⽤数据库Dataguard技术的数据迁移的特点:
●对业务的影响⼩,switchover到新主机的时间⼩于10分钟
●⼀旦新数据库出现问题能够⽅便的回切到原来的数据库,不丢失差异
oracle10g客户端安装步骤数据
采⽤数据库Dataguard技术的数据迁移的主要步骤如下:
1) 在新主机上安装Oracle9i 数据库软件
2) 在新主机上配置Dataguard 数据库(物理standby )
3) 利⽤DataGuard技术,主数据库不断的将新产⽣的数据库归档⽇志
传输到新主机并将这些归档⽇志应⽤到standby数据库,实现主备
数据库之间的数据同步
4) 系统割接期间只需将新主机上的standby数据库切换为主数据库即
可(switchover的时间⼩于10分钟)
5) ⼀旦新系统上数据库运⾏出现问题只需将数据库切换回原来主机上
即可,不会丢失任何数据
1.1.1 数据库升级的解决思路
1.1.1.1 数据库升级的基本出发点
保证企业⽣产及业务系统运⾏的安全性、连续性
克服原有系统缺陷
吸收适⽤的系统新特性
迁移⼯作必然涉及到数据库系统的扰动,所以减少对于正常业务系统的冲击,保证它的连续性和安全性是第⼀个出发点,数据库系统是业务系统的基础,认真准备和设计数据库迁移是开始的第⼀步。
迁移到更新版本的⼯作也是纠正原有系统内含的错误的良好机会,这个原则同样也适合于任何软件系统和硬件设备。
1.1.1.2 数据库迁移⽅式
从Oracle9i到Oracle10G的迁移有三种⽅式:
1. 使⽤export和import
优点:通过导出和导⼊⽅式对数据库存储结构进⾏重整有助于减少数据库碎块
缺点:对于超过150G以上的数据库,采⽤exp/imp⽅式的停机时间很长
2. 使⽤Migrate脚本
优点:速度快,⼀般在30分钟内能完成脚本升级
缺点:⼀旦升级后就⽆法回退
3. 使⽤Migrate向导⼯具(DBUA)
优点:速度快,⼀般在30分钟内能完成脚本升级
缺点:⼀旦升级后就⽆法回退,容错性较差
我们综合考虑了数据库规模、停机时间、升级风险和以往的成功案例后,我们建议采⽤数据库升级脚本⽅式直接升级迁移后的数据库,
1.2 项⽬实施计划
1.2.1 实施步骤
为了降低项⽬实施的风险,我们建议将整个系统迁移和升级项⽬拆分为五个阶段:
●准备阶段
准备阶段需要完成搭建新系统环境,是整个系统迁移项⽬成功的基⽯,主要⼯作包括安装操作系统、系统参数调整、存储及LVM设计和规划、MS/SG规划和实施等
●测试阶段
由于数据库升级采⽤脚本直接在⽣产库上实施,因此完备细致的测试⼯作是整个项⽬成功与否的关键,在测试阶段我们需要达到以下⽬的:?验证迁移⽅案的可⾏性
解决迁移测试过程中遇到的错误
根据测试的结果调整迁移过程
对整个系统迁移过程做进⼀步的优化
●数据库迁移阶段
为了尽可能的减少系统停机时间数据库的迁移⼯作,我们计划采⽤Oracle9i Dataguard技术:将数据库
热备份恢复到新主机,配置主备节点的数据库归档⽇志同步,系统割接的时候只需做switchover 操作将新节点上备⽤数据库⾓⾊切换为主数据库即可。
数据库迁移到新节点后将应⽤系统也切换到新数据库,在新系统上运⾏⼀段时间,如果发现新节点上数据库或主机出现问题,可以⽅便的回切到原来的数据库,不丢失任何数据。
●数据库升级阶段
数据库升级由于直接在⽣产数据库上执⾏升级脚本,⼀旦升级失败对业务影响较⼤,因此其实施的前提是:
1) 测试阶段数据库升级测试成功
2) 对升级风险有预判和应急措施
3) 整个数据库升级时间在⽤户可接受的范围内
4) 在数据库升级前必须有个最新的、可⽤的数据库全备份
数据库迁移升级后的⼯作
数据库迁移升级后的⼯作包括数据库全备份、主机和数据库性能监控等1.2.2 实施计划
根据以上步骤整理的该项⽬实施计划表格如下:
1.3 系统迁移应急策略
1.3.1 系统迁移实施前的异常
如果在规划的时间点之前没有完成实施准备阶段的任务,实施时间顺延,在确保准备⼯作就绪的前提下才进⾏实施⼯作。天玑科技将在该项⽬开始实施前进⾏全⾯性的系统软、硬件健康检查,确保在项⽬实施前系统完好。
1.3.2 系统迁移实施过程中的异常
本次系统迁移实施的原则是确保系统在规划的实施时间段之外可以正常运⾏。为确保系统在发⽣硬件或软件故障时能够及时得到技术响应,需要协调各相关⼈员到位。在实施过程中操作步骤具有可逆性,确保以外发⽣的时候可将系统迅速回退到最初状态。系统和数据在实施前都做最新的备份。
由于在正式数据库迁移之前,已经做过测试迁移的⼯作,应该能够估算出迁移⼤概所需的时间。如果由于⼀些不可测原因导致迁移过程异常缓慢或终⽌,数据库升级所需时间超过原定时间,我们可以迅速将数据库系统恢复到最初状态。
1.3.3 系统迁移实施后的异常
由于该项⽬实施过程中,只有在确认了Oracle数据库迁移成功并且Oracle 9i成功升级到10G成功后,才打开对数据库数据的增加、删除、修改等数据库变更操作,否则所有表空间均设置为readonly状态(或者通过调整Websphere 中间件,停⽌对后端数据库的写操作以便限制成功迁移、升级之前的Oracle数据库的变更),因此,系统迁移实施后的异常情况下,由于迁移前后均不涉及到数据库数据的变更,严格来说可以简单通过恢复原环境节点承担中间件连接即可恢复为原有环境。
另⼀⽅⾯,前期的充分测试也是对该应急措施的保障性测试。
1.4 风险分析及对策分析
通过天玑科技多年以来专业服务项⽬实施的经验,我们建议xxx在该项⽬的实施过程中应把风险管理贯穿整个项⽬,天玑科技充分考虑了可能造成项⽬失败的所有因素和预防措施,以及发⽣时的管理办法,以此作为该项⽬的风险规避⽅案。
1.4.1 风险种类
不可控制的风险
(1) 重⼤政策出台,影响公司发展;
(2) 重⼤社会事件发⽣
(3) ⾃然灾难导致机房,机器在升级过程中受损
可控制的风险
(1) 随意变更项⽬⽬标、范围、时间;
(2) 随意调⽤项⽬⼈员,使其没有⾜够的参与时间;
(3) 不能及时决策、及时确认项⽬阶段报告;
(4) 不遵守项⽬⼤纲的要求。
可能的风险
(1) 数据库版本升级带来的与应⽤不兼容,包括性能⽅⾯和功能⽅⾯
(2) 数据库版本升级带来的现有硬件不兼容,⽐如带库
(3) 数据库版本升级带来的现有软件不兼容,⽐如备份软件,监控软件
(4) 数据库版本升级带来的管理⼈员培训需要
以上从系统的各个⽅⾯简单描述了各种类型的风险,具体风险及防范措施将通过下⾯依据升级⼯作⽣命周期的阶段性分析来详细描述,将涵盖可能产⽣的各⽅⾯风险。
1.4.2 风险分析及防范措施
我们根据以往数据库Oracle9i到Oracle10G的升级的成功经验,对于xxx改造项⽬实施过程中可能出现的以下风险点及提出了对应的应对措施:
风险⼀:直接在⽣产库上升级
风险⼆:⽣产库恢复时间
风险三:数据库服务器之间版本不⼀致
风险四:客户端和服务端版本不⼀致
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论