数据库迁移应急

《数据库迁移应急》由会员分享，可在线阅读，更多相关《数据库迁移应急（5页珍藏版）》请在金锄头文库上搜索。

1、数据库迁移应急方案1.3系统迁移应急策略1.3.1系统迁移实施前的异常如果在规划的时间点之前没有完成实施准备阶段的任务，实施时间顺延，在确保准备工作 就绪的前提下才进行实施工作。项目组将在该项目开始实施前进行全面性的系统软、硬件健康检查，确保在项目实施前系 统完好。1.3.2系统迁移实施过程中的异常本次系统迁移实施的原则是确保系统在规划的实施时间段之外可以正常运行。为确保系统 在发生硬件或软件故障时能够及时得到技术响应，需要协调各相关人员到位。在实施过程中操 作步骤具有可逆性，确保以外发生的时候可将系统迅速回退到最初状态。系统和数据在实施前 都做最新的备份。由于在正式数据库迁移之前，已经做过测

2、试迁移的工作，应该能够估算出迁移大概所需的 时间。如果由于一些不可测原因导致迁移过程异常缓慢或终止，数据库升级所需时间超过原定 时间，我们可以迅速将数据库系统恢复到最初状态。1.3.3系统迁移实施后的异常由于该项目实施过程中，只有在确认了 Oracle数据库迁移成功并且Oracle9i成功升级到 10G成功后，才打开对数据库数据的增加、删除、修改等数据库变更操作，否则所有表空间均设 置为readonly状态（或者通过调整Websphere中间件，停止对后端数据库的写操作以便限制成 功迁移、升级之前的Oracle数据库的变更），因此，系统迁移实施后的异常情况下，由于迁移 前后均不涉及到数据库数据

3、的变更，严格来说可以简单通过恢复原环境节点承担中间件连接即 可恢复为原有环境。另一方面，前期的充分测试也是对该应急措施的保障性测试。1.4风险分析及对策分析通过天玑科技多年以来专业服务项目实施的经验，我们建议xxx在该项目的实施过程中应 把风险管理贯穿整个项目，天玑科技充分考虑了可能造成项目失败的所有因素和预防措施，以 及发生时的管理办法，以此作为该项目的风险规避方案。1.4.1风险种类不可控制的风险（1）重大政策出台，影响公司发展；（2）重大社会事件发生（3）自然灾难导致机房，机器在升级过程中受损可控制的风险（1）随意变更项目目标、范围、时间；（2）随意调用项目人员，使其没有足够的参与时间；

4、（3）不能及时决策、及时确认项目阶段报告；（4）不遵守项目大纲的要求。可能的风险（1）数据库版本升级带来的与应用不兼容，包括性能方面和功能方面（2）数据库版本升级带来的现有硬件不兼容，比如带库（3）数据库版本升级带来的现有软件不兼容，比如备份软件，监控软件（4）数据库版本升级带来的管理人员培训需要以上从系统的各个方面简单描述了各种类 型的风险，具体风险及防范措施将通过下面依据升级工作生命周期的阶段性分析来详细描述， 将涵盖可能产生的各方面风险。1.4.2风险分析及防范措施我们根据以往数据库Oracle9i到Oracle10G的升级的成功经验，对于xxx改造项目实施过程 中可能出现的以下风险点及

5、提出了对应的应对措施：风险一：直接在生产库上升级使用脚本升级方式，也就意味着最终的正式升级只能是在产品库上直接进行，那么无论之 前做过何种测试，都可能由于意外原因导致升级失败（比如升级过程中意外断电，硬件发生意 外损坏等），升级失败就可能意味着生产库的不可用。稳妥的备份策略是升级工作的后备军。只要有有效的数据库备份，就能够胆大心细地进行 升级工作。而目前帐务数据库在无施锡新区有异地备份的容灾库，这更是一种有力的保证，让 升级工作无后顾之忧。风险二：生产库恢复时间如果升级失败，那么可能需要恢复生产库以应对第二天的业务，因为移动的数据量很大， 即使是使用增量备份的方法也需要至少恢复一天的归档日志，

6、那么如果万一升级出现问题，能 否在升级窗口期内完成数据库恢复是一个风险。稳妥的备份策略不仅仅包含备份的效率，同样也包含恢复的效率，一个只能备份而无法在 规定时间内恢复的备份策略是不合施格的，也是没有意义的。因此同样，制定有效的备份策略 同时进行同比数据量的恢复测试是必要的风险防范措施。风险三：数据库服务器之间版本不一致在一段时间内，Oracle9i和Oracle10g将同时存在于数据库风险系统中，各个系统之间存在 着不同版本数据库数据交互的现象，可能产生数据不兼容的情况。详细考虑升级的先后顺序，哪套系统先升级，哪套系统后升级。尽量使有数据交互的系统 在同一时刻进行升级。施如果无法做到同一时刻升

7、级，那么需要进行升级测试和升级预演，确 保在测试环境中不同版本的数据库之间交互是没有问题的。风险四：客户端和服务端版本不一致客户端（Websphere中间件）和服务端（Oracle 10G）同风险样在一段时间内存在着版本不 一致的现象，服务端可能无法正常处理客户端请求，而客户端也可能无法正常接收服务端数据。对于可能存在的客户端和服务器端版本问题，在升级之前必须有测试环境进行全面测试， 将普通的功能问题在测试环境中就予以解决，尽量减少产品环境中的升级风险。对于已知故障，可以按照天机科技对应的故障解决方法，通过Patch和设置Event来避免 产生 Core Dump。风险五：Failover对于

8、网卡不支持单机多网卡之间的Failover，以往的网卡Failover设置需要改动。建议使用操作系统功能将多块网卡捆绑为一 个NIC设备，以此避免网卡的单点故障。风险六：升级Pro*C程序版本在新版本数据库下可能无法正常编译；如果无法正常编译，需要原开发人员的技术支持， 但风险是原开发人员可能因为人员变动而无法找到；令如果需要其它开发人员修改，需要确保 源代码还存在，并且同时要考虑现任人员的修改能力。对于这样的情况只有通过测试才能确认是否兼容，尽量详尽地进行升级测试和升级预演是 防范问题出现在产品环境中的必要手段。风险七：不升级Pro*C程序版本旧版本Pro*C连接新版本数据库可能会出现非预测

9、的错误结果或者低下的应用性能。（需 要确认Xxx应用系统是否采用该选项）在Oracle顾问参与的某项目中，客户就直接使用9i版本 的Pro*C程序连接Oracle10g数据库，获得了跟以往一样的功能和性能。但是由于Pro*C程序的 多样性，所以必须谨慎测试。对于这样的情况也只有通过测试才能确认是否兼容，尽量详尽地 进行升级测试和升级预演是防范问题出现在产品环境中的必要手段。风险八：疲劳操作升级工作比较紧张，高强度的工作也容易使人疲劳，而在紧张和疲劳的状态下，是比较容 易产生人为失误的。升级工作必须由至少2人协同完成；按照升级预演的文档仔细操作；重大命令必须有协同 工作人员确认之后才可以输入；完

10、善的备份让升级工作无后顾之忧。风险九：执行计划稳定性Oracle10g在创建完数据库之后会产生一个自动定期收集数据库对象统计信息的Schedule, 黑默认是在周一到周五的每天晚上10点以及周六的凌晨0点，对于执行计划已经比较稳定的产品 环境来说，每天收集统计信息是没有必要的，同时还存在可能改变执行计划的隐患。禁用统计信息自动收集。加强性能监控。风险十：High Version Count由于Oracle10.2.0.3对于cursor是否能够重用的安全性检查加强，因此在 Cursor_sharing=SIMILA或者FORCE的系统中，可能会产生同一SQ L的大量Version，将会严重影

11、响应用的性能。完善测试应用的功能和性能。风险十一：并行性能对于在表或者索引上定义了并行度的情况，对于xXXx系统这样的负载较大的OLTP系统，可 能会由于并行进程的大量占用资源而导致数据库性能急剧下降。在升级之后需要仔细检查表和索引的并行度，建议将所有并行度都设置为1。如果确实需 要并行，那么通过在程序中指定parallel hint来实现并行。风险十二：RMAN Catalog10gR2的RMAN Catalog跟9i的Catalog有差别，继续使用旧版本的RMAN Catalog会造成RMAN 命令错误。在升级完数据库之后立刻升级RMAN Catalog数据库，或者创建新的RMAN Cat

12、alog（因为可 能有还未及时升级的Oracle9i数据库需要使用原来的Catalog）来存储已经升级的Oracle数据库 RMAN备份信息。风险十三：培训成本是否对于数据库管理员的管理培训成本有足够的预算。保证提供足够的成本预算对数据库管理员进行新版本数据库的培训。风险十四：管理磨合期Oracle10g数据库管理磨合期风险。提前对于管理人员进行Oracle 10g新特性以及管理技巧的培训，以保证升级后管理磨合期 的时间尽可能缩短。检查旧版本中所有监控工具或者监控脚本在新版本数据库中是否仍然有正常功能。1.5项目需要的资源保证1.5.1组织与人力资源保证（1）组建强有力的由各相关业务部门骨干参

13、加的项目组织，并明确职责。（2）决策层：高层领导负责，定期听取汇报，及时决策执行层上交的问题。（3）执行层：能够协调各分公司、各相关部门，必要时能提交决策层。（4）操作层：项目骨干成员必须为稳定的业务骨干，并能在日后的优化、维护中发挥作用。1.5.2系统与办公环境保证（1）硬件、软件的采购、安装、调试、维护要有保证。（2）相对固定的，便于随时与各部门业务人员交流的办公场所。（3）必要的办公与通讯设施（电话、传真、互联网、打印机、复印机）。1.5.3项目成功的关键因素主要包括以下几方面：（1）高层管理对项目的承诺和决心，并且加以大力推动。（2）明确的项目目标与范围。（3）充分的沟通和交流，上下保持一致的项目目标。（4）决策迅速，顺畅的变革管理。（5）有效、充分的知识转移。（6）实力雄厚，经验丰富的项目实施队伍。