(完整)应用和数据迁移方案编辑整理：尊敬的读者朋友们：这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望（(完整)应用和数据迁移方案）的内容能够给您的工作和学习带来便利。
同时也真诚的希望收到您的建议和反馈，这将是我们进步的源泉，前进的动力。
本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快业绩进步，以下为(完整)应用和数据迁移方案的全部内容。
第一章. 应用和数据迁移方案由于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 实施计划根据以上步骤整理的该项目实施计划表格如下：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改造项目实施过程中可能出现的以下风险点及提出了对应的应对措施：➢风险一：直接在生产库上升级➢风险二:生产库恢复时间➢风险三：数据库服务器之间版本不一致➢风险四:客户端和服务端版本不一致➢风险五：Failover➢风险六：升级Pro*C程序版本➢风险七：不升级Pro＊C程序版本➢风险八:疲劳操作➢风险九：执行计划稳定性➢风险十:High Version Count➢风险十一：并行性能➢风险十二：RMAN Catalog➢风险十三：培训成本➢风险十四：管理磨合期1.5 项目需要的资源保证1.5.1 组织与人力资源保证(1) 组建强有力的由各相关业务部门骨干参加的项目组织，并明确职责。
(2) 决策层:高层领导负责,定期听取汇报，及时决策执行层上交的问题。
(3) 执行层：能够协调各分公司、各相关部门，必要时能提交决策层。
(4) 操作层:项目骨干成员必须为稳定的业务骨干，并能在日后的优化、维护中发挥作用.1.5.2 系统与办公环境保证(1) 硬件、软件的采购、安装、调试、维护要有保证。
(2) 相对固定的，便于随时与各部门业务人员交流的办公场所。
(3) 必要的办公与通讯设施（电话、传真、互联网、打印机、复印机）。
1.5.3 项目成功的关键因素主要包括以下几方面：(1) 高层管理对项目的承诺和决心，并且加以大力推动。
(2) 明确的项目目标与范围。
(3) 充分的沟通和交流, 上下保持一致的项目目标.(4) 决策迅速,顺畅的变革管理。
(5) 有效、充分的知识转移。
(6) 实力雄厚，经验丰富的项目实施队伍。