为了正常的体验网站,请在浏览器设置里面开启Javascript功能!

应用和数据迁移方案

2019-02-13 10页 doc 58KB 30阅读

用户头像

is_751406

暂无简介

举报
应用和数据迁移方案第1章. 应用和数据迁移方案 由于xxx生产作业是24小时不间断运作的,因此要求系统能连续运行,并具有很高的安全可靠性,用户希望在以最小的系统停机时间完成生产系统迁移工作。本次系统迁移工作的最大的风险点和难点在于在有限的停机时间内完成数据库的迁移工作。 1.1 数据库迁移的解决思路 xxx数据库系统数据量较大,并且应用系统的可用性要求极高,所以此次升级要求在有限的停机时间内,最大限度的降低风险、数据库业务在新的主机和存储系统上能够正常运行。为了尽可能减少业务系统的停机时间,保证数据库迁移工作的顺利完成,我们基于以往实施的数据...
应用和数据迁移方案
第1章. 应用和数据迁移 由于xxx生产作业是24小时不间断运作的,因此要求系统能连续运行,并具有很高的安全可靠性,用户希望在以最小的系统停机时间完成生产系统迁移工作。本次系统迁移工作的最大的风险点和难点在于在有限的停机时间内完成数据库的迁移工作。 1.1 数据库迁移的解决思路 xxx数据库系统数据量较大,并且应用系统的可用性要求极高,所以此次升级要求在有限的停机时间内,最大限度的降低风险、数据库业务在新的主机和存储系统上能够正常运行。为了尽可能减少业务系统的停机时间,保证数据库迁移工作的顺利完成,我们基于以往实施的数据库迁移成功(1.1T的数据量,迁移时间不超过15分),经过严格的数据库迁移测试,提出了采用数据库Dataguard技术的数据迁移。 采用数据库Dataguard技术的数据迁移的特点: ● 对业务的影响小,switchover到新主机的时间小于10分钟 ● 一旦新数据库出现问能够方便的回切到原来的数据库,不丢失差异数据 采用数据库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 实施计划 根据以上步骤整理的该项目实施计划表格如下: 时间 工作内容 负责单位 配合单位 准备阶段   系统环境调研 天玑科技 xxx   新主机系统盘做mirror 天玑科技     安装HP DP备份软件 天玑科技     双机HP MC/SG规划及配置 天玑科技     主机系统参数、卷组、文件系统及数据库配置参数检查 天玑科技   测试阶段   实施Dataguard 数据库迁移 天玑科技     应用测试       HP MC/SG双机切换测试 天玑科技     实施数据库升级测试 天玑科技     应用测试       HP MC/SG双机切换测试 天玑科技   数据库迁移阶段   数据库全备份 天玑科技     在新主机上创建dataguard physical standby db 天玑科技     配置datagurad使得主备数据库之间归档日志同步 天玑科技     停应用 xxx     生产数据库切换为physical standby db 天玑科技     在新主机的原physical standby db切换为主数据库 天玑科技     应用系统测试及相关应用连接数据库配置修改 天玑科技     MC/SG 切换测试 天玑科技     DataProtector数据库备份配置 天玑科技     系统上线 天玑科技   数据库升级阶段   Oracle9i数据库全备份及数据库软件备份 天玑科技     数据库升级前的检查 天玑科技     数据库参数调整 天玑科技     停应用 xxx     运行数据库升级脚本 天玑科技     编译数据库无效对象 天玑科技     重启数据库,应用系统测试 天玑科技     DataProtector数据库备份配置 天玑科技     HP MC/SG切换测试 天玑科技     系统上线 天玑科技   数据库升级后的工作   主机性能监控 天玑科技     数据库性能监控 天玑科技     Oracle10g数据库全备份 天玑科技           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改造项目实施过程中可能出现的以下风险点及提出了对应的应对措施: ? 风险一:直接在生产库上升级 风险 使用脚本升级方式,也就意味着最终的正式升级只能是在产品库上直接进行,那么无论之前做过何种测试,都可能由于意外原因导致升级失败(比如升级过程中意外断电,硬件发生意外损坏等),升级失败就可能意味着生产库的不可用。 防范措施 稳妥的备份策略是升级工作的后备军。只要有有效的数据库备份,就能够胆大心细地进行升级工作。而目前帐务数据库在无锡新区有异地备份的容灾库,这更是一种有力的保证,让升级工作无后顾之忧。     ? 风险二:生产库恢复时间 风险 如果升级失败,那么可能需要恢复生产库以应对第二天的业务,因为移动的数据量很大,即使是使用增量备份的方法也需要至少恢复一天的归档日志,那么如果万一升级出现问题,能否在升级窗口期内完成数据库恢复是一个风险。 防范措施 稳妥的备份策略不仅仅包含备份的效率,同样也包含恢复的效率,一个只能备份而无法在规定时间内恢复的备份策略是不合格的,也是没有意义的。因此同样,制定有效的备份策略同时进行同比数据量的恢复测试是必要的风险防范措施。     ? 风险三:数据库服务器之间版本不一致 风险 在一段时间内,Oracle9i和Oracle10g将同时存在于数据库系统中,各个系统之间存在着不同版本数据库数据交互的现象,可能产生数据不兼容的情况。 防范措施 详细考虑升级的先后顺序,哪套系统先升级,哪套系统后升级。尽量使有数据交互的系统在同一时刻进行升级。 如果无法做到同一时刻升级,那么需要进行升级测试和升级预演,确保在测试环境中不同版本的数据库之间交互是没有问题的。    
/
本文档为【应用和数据迁移方案】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。 本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。 网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。

历史搜索

    清空历史搜索