应用和数据迁移方案

第第 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 将同时存在于数据 库系统中 各个系统之间存在着不同版本数据库数据交互的现 象 可能产生数据不兼容的情况 防范措防范措 施施 详细考虑升级的先后顺序 哪套系统先升级 哪套系统后 升级 尽量使有数据交互的系统在同一时刻进行升级 如果无法做到同一时刻升级 那么需要进行升级测试和升 级预演 确保在测试环境中不同版本的数据库之间交互是没有 问题的 风险四 客户端和服务端版本不一致风险四 客户端和服务端版本不一致 风险风险 客户端 Websphere 中间件 和服务端 Oracle 10G 同 样在一段时间内存在着版本不一致的现象 服务端可能无法正 常处理客户端请求 而客户端也可能无法正常接收服务端数据 防范措防范措 施施 对于可能存在的客户端和服务器端版本问题 在升级之前 必须有测试环境进行全面测试 将普通的功能问题在测试环境 中就予以解决 尽量减少产品环境中的升级风险 对于已知故障 可以按照天机科技对应的故障解决方法 通过 Patch 和设置 Event 来避免产生 Core Dump 风险五 风险五 Failover 风险风险 对于网卡不支持单机多网卡之间的 Failover 以往的网卡 Failover 设置需要改动 防范措防范措 施施 建议使用操作系统功能将多块网卡捆绑为一个 NIC 设备 以此避免网卡的单点故障 风险六 升级风险六 升级 Pro C 程序版本程序版本 风险风险 在新版本数据库下可能无法正常编译 如果无法正常编译 需要原开发人员的技术支持 但 是原开发人员可能因为人员变动而无法找到 如果需要其它开发人员修改 需要确保源代码还存在 并且同时要考虑现任人员的修改能力 防范措防范措 施施 对于这样的情况只有通过测试才能确认是否兼容 尽量详 尽地进行升级测试和升级预演是防范问题出现在产品环境中的 必要手段 风险七 不升级风险七 不升级 Pro C 程序版本程序版本 风险风险 旧版本 Pro C 连接新版本数据库可能会出现非预测的错误 结果或者低下的应用性能 需要确认 xxx 应用系统是否采用该 选项 防范措防范措 施施 在 Oracle 顾问参与的某项目中 客户就直接使用 9i 版本 的 Pro C 程序连接 Oracle10g 数据库 获得了跟以往一样的功 能和性能 但是由于 Pro C 程序的多样性 所以必须谨慎测试 对于这样的情况也只有通过测试才能确认是否兼容 尽量详尽 地进行升级测试和升级预演是防范问题出现在产品环境中的必 要手段 风险八 疲劳操作风险八 疲劳操作 风险风险 升级工作比较紧张 高强度的工作也容易使人疲劳 而在 紧张和疲劳的状态下 是比较容易产生人为失误的 防范措防范措 施施 升级工作必须由至少 2 人协同完成 按照升级预演的文档仔细操作 重大命令必须有协同工作人员确认之后才可以输入 完善的备份让升级工作无后顾之忧 风险九 执行计划稳定性风险九 执行计划稳定性 风险风险 Oracle10g 在创建完数据库之后会产生一个自动定期收集 数据库对象统计信息的 Schedule 默认是在周一到周五的每天 晚上 10 点以及周六的凌晨 0 点 对于执行计划已经比较稳定 的产品环境来说 每天收集统计信息是没有必要的 同时还存 在可能改变执行计划的隐患 防范措防范措 施施 禁用统计信息自动收集 加强性能监控 风险十 风险十 High Version Count 风险风险由于 Oracle10 2 0 3 对于 cursor 是否能够重用的安全性检 查加强 因此在 Cursor sharing SIMILAR 或者 FORCE 的系 统中 可能会产生同一 SQL 的大量 Version 将会严重影响应 用的性能 防范措防范措 施施 完善测试应用的功能和性能 风险十一 并行性能风险十一 并行性能 风险风险 对于在表或者索引上定义了并行度的情况 对于 xxx 系统 这样的负载较大的 OLTP 系统 可能会由于并行进程的大量占 用资源而导致数据库性能急剧下降 防范措防范措 施施 在升级之后需要仔细检查表和索引的并行度 建议将所有 并行度都设置为 1 如果确实需要并行 那么通过在程序中指 定 parallel hint 来实现并行 风险十二 风险十二 RMAN Catalog 风险风险 10gR2 的 RMAN Catalog 跟 9i 的 Catalog 有差别 继续使 用旧版本的 RMAN Catalog 会造成 RMAN 命令错误 防范措防范措 施施 在升级完数据库之后立刻升级 RMAN Catalog 数据库 或 者创建新的 RMAN Catalog 因为可能有还未及时升