企业业务连续性和数据容灾解决方案

企业业务连续性和数据容灾 解决方案 Quest Software P r e p a r e d b y N a m e H e r e Q u e s t S o f t w a r e I n c White Paper S 2 Internal Partner Win Story 目录目录 1企业的业务连续性和数据容灾建设需求 3 2主流容灾技术和解决方案比较 4 3基于 SHAREPLEX的容灾方案 9 3 1SharePlex for Oracle 产品介绍 9 3 2系统构架图 11 3 3容灾接管和反向回切 11 3 4RTO RPO 指标规划 13 4业务连续性和数据灾备方案选型 14 4 1本地业务连续性和报表分离方案 14 4 2同城异地灾备方案 14 4 3超远距离异地灾备 15 4 4多灾备中心方案设计 15 5成功案例 17 5 1银联数据 17 5 2山西移动 20 5 3北京地税 23 S 3 Internal Partner Win Story 1企业的业务连续性和数据容灾建设需求企业的业务连续性和数据容灾建设需求 目前 企业对业务连续性和数据容灾有很高的要求 主要的管理目标如下 提供数据安全保障 规避业务风险数据安全保障 规避业务风险 确保应用高可用性 确保应用高可用性 消除计划外的停机时间 减少计划外的停机时间 考虑平战结合的方案 提高投资回报提高投资回报 很多企业都已经建设或正在规划业务连续性和数据容灾系统 一般会考虑三种灾备方式 本地业务连续 性和报表分离 主要目标为业务连 续性 应对局部数据风险 对应用接管和反 向回切要求较高 一般考虑平战结合 的解决方案 同城异地灾备 兼顾业务连续性和 数据安全性 应对除地区级外的 所有数据风险 复 制距离较近 同时考虑物理级和 逻辑复制方案 超远距离灾备 主要目标为数据安 全性 应对地区级数据风 险 复制距离较远 关注带宽使用等维 护性成本 每种灾备方式面向的管理目标不同 需要采用不同的方案满足需求 S 4 Internal Partner Win Story 2主流容灾主流容灾技术和解决方案比较技术和解决方案比较 目前几种主流的容灾技术或解决方案如下 实时获取数据日志进行复制 异步方案 实时性较高 典型代表 Quest Shareplex for Oracle 数据库逻辑复制 采用物理日志的方法进行复制 异步方案 实时性较差 典型代表 Oracle Datagurad Physical Standby 数据库物理复制 以逻辑卷为单位 通过TCP IP 网络进行复制 典型代表 Symantec VVR 逻辑卷复制 依赖存储设备的传输网络 可以采用同步和异步技术 典型代表 EMC HP Hatti 等存储厂商 存储级复制 上述四种方式分别从应用底层到应用上层进行复制 复制的数据量越来越小 对带宽的 占用越来越低 对硬件设备的依赖越来越少 复制的灵活性越来越高 针对这些解决方案的 具体说明如下 1 基于存储的容灾复制方案 基于存储的容灾复制方案 此类技术的特点是基于特定的存储阵列产品 利用专用接口和专用软件实现 一般要求 数据复制的源和目标有相同的磁盘阵列产品 且两点之间通常采用光纤连接 运行 FC ESCON 或其它专有协议 典型的代表是 EMC SRDF IBM PPRC HP Business Copy HDS True Copy 等 可以实现同步或异步两种方式的复制 优势 基于存储设备实现 对主机透明 对主机资源占用少 S 5 Internal Partner Win Story 通过 SAN 自身的网络进行复制 不占用网络带宽 同步模式下没有数据损失 劣势 环境要求高 需要同构的存储和主机 操作系统 数据库版本等要求一致 接管时间长 灾难恢复时 目标系统经过数据库恢复才能够被用户所访问 需要一 定的接管时间 目标数据库不可用 如果需要目标系统可读 需要额外的配置和设备 而且有一天 左右的延迟 基于物理层的复制 对于逻辑错误 硬件错误无法规避 可能会出现一些故障导致 真正需要时数据库无法启动的状态 无法提供对逻辑坏块和手工错误的保护 实施工作量较大 扩展性和可伸缩性比较差 基于存储的容灾复制方案目前被广泛使用 适合超大数据量的同城异地容灾 但因对网 络资源使用非常大 异地容灾不大现实 同时对于中小应用系统来说 解决方案过于复杂和 昂贵 2 基于逻辑卷的容灾复制方案 基于逻辑卷的容灾复制方案 这种技术的机制是通过基于 TCP IP 的网络环境进行复制 由操作系统进程捕捉逻辑卷 的变化进行复制 典型代表为 Symantec 原 Veritas 的 VVR 可以实现同步或异步两种方式 的复制 基于逻辑卷的容灾复制方案对数据库应用没有任何优势 环境要求高 需要同构的主机 操作系统 数据库版本等要求一致 接管时间长 灾难恢复时 目标系统经过数据库恢复才能够被用户所访问 需要一 定的接管时间 目标数据库不可用 如果需要目标系统可读 需要额外的配置和设备 而且有 1 天 S 6 Internal Partner Win Story 左右的延迟 基于物理层的复制 对于逻辑错误 硬件错误无法规避 可能会出现一些故障导致 真正需要时数据库无法启动的状态 无法提供对逻辑坏块和手工错误的保护 使用 IP 网 对带宽占用非常高 扩展性和可伸缩性比较差 这种方式比较适用于非数据库文件的容灾备份 3 数据库物理复制方式 数据库物理复制方式 Oracle Dataguard 是 Oracle 公司提供的数据保护技术 通过传输日志文件在目标数据 库恢复的方式操作系统进程捕捉逻辑卷的变化进行复制 只提供异步方式 是一种常规使用 的复制模式 管理简单 但是无法规避物理复制的一些主要问题 环境要求高 需要同构的主机 操作系统 数据库版本等要求一致 接管时间长 灾难恢复时 目标系统经过数据库恢复才能够被用户所访问 需要一 定的接管时间 目标数据库不可用 或可以在只读和恢复间进行切换 基于物理层的复制 所以对于逻辑错误 硬件错误无法规避 可能会出现一些故障 导致真正需要时数据库无法启动的状态 无法提供对逻辑坏块和手工错误的保护 使用 IP 网 对带宽占用较高 延迟较高 一般来说为一个日志文件 扩展性和可伸缩性比较差 数据库物理复制方式在目前被广泛使用 适合于本地和异地物理数据备份 4 数据库逻辑复制方式 数据库逻辑复制方式 使用这种方式的主要有一些第三方的软件 如 Quest 公司的 SharePlex for Oracle SharePlex 使用 Oracle 以外的独立进程 捕捉 Redo Log File 的信息 将其翻译成 S 7 Internal Partner Win Story SQL 语句 再通过网络传输到目标端数据库 在目标端数据库执行同样的 SQL 如果其进 程赶不上 Oracle 日志切换 也可以捕捉归档日志中的内容 一般都是以表为单位进行复制 同时也支持大部分 DDL 的复制 这种方式还可以支持多种复制配置 比如数据集中 分发 对等复制 或者多层次的复 制等 基于数据库逻辑复制的解决方案技术特点如下 复制软件使用 Oracle 以外的进程进行捕捉 对源系统数据库的性能影响很小 基于其实现原理及多个队列文件的使用 复制环境可以提供网络失败 数据库失败 主机失败的容错能力 能保证两端数据库的事务一致性 目标数据实时可用 用户可以对目标系统进行查询操作 因此 可以作为报表查询 统计分析等系统的数据源 减轻源系统的压力 使投资变为可用 而不是单纯的冷 备闲置 同时也保证了容灾快速接管 数据延迟小 每次 Oracle 日志文件发生变化后 复制软件都会迅速的捕捉 所以其 数据延迟非常小 在生产系统中 数据延迟和源系统复制事物的多少 事物的处理 方式有关 一般的业务可实现秒级复制 网络占用小 通过网络传输的数据量由于传输的内容只是 Redo Log 或 Archive Log 中的一部分 对网络资源的占用很小 一般为日志文件的 1 3 可以实现不同城市之 间的远程复制 支持异构环境 支持不同的操作系统和 Oracle 数据库的不同版本 与具体用什么硬 件无关 灵活性和扩展性强 提供多种配置方案 包括单向复制 双向复制 数据集中 数 据分布等等 支持双向复制 反向增量回切等 可以很好地满足系统的扩充性需求 充分保护投资 S 8 Internal Partner Win Story S 9 Internal Partner Win Story 3基于基于 SharePlex 的容灾的容灾方案方案 3 1SharePlex for Oracle产品介绍产品介绍 下图所示为 SharePlex for Oracle 的基本结构 Capture Read ExportImport Post Capture Export Post SQL Redo Logs 源目 数据捕获数据捕获 SharePlex for Oracle 由捕获进程来收集发生变化的数据 捕获进程驻留在源系统上 自动读取 Oracle 的在线日志文件 这种读操作是从操作系统的角度来完成的 而不是通过数 据库 通过将日志文件作为获取变化信息的源泉 Quest 可以完成数据的复制而不会给生产 S 10 Internal Partner Win Story 系统带来额外的开销 由于 Oracle 将所有的事物变化记录到日志中并使用日志文件进行系统 恢复 因此 Shareplex for Oracle 可以通过解析日志文件保障数据的一致性 捕获进程连续监控日志文件用以捕捉变化信息 当日志文件中出现一条新记录时 SharePlex 判断其是否属于被复制对象 如果是 则 SharePlex 为该条记录加入用于决定此 记录将被发向那个主机的地址信息并将包含地址信息的记录存放到自己的队列中 存储队列 存在于数据库之外 发生改变的数据被立即处理并被发送到目标系统中而不等待提交或回滚 动作的完成 因为等待提交或回滚完成将带来延迟 当提交或回滚信息被写入日志文件时 它们也将被发送到目标系统中 从而在目标系统中完成相对应的操作 捕获进程具有如下特点 捕获进程从 Oracle 日志文件中读取信息 因此复制过程不会给生产数据库实例带来 性能问题 只有发生改变的数据被传输 而不是日志文件中的全部信息 因此 SharePlex 的网 络负载非常小 尽管需要在 Oracle 数据库中安装少量的对象用来存储有关复制的一些基本信息 但 源数据库不需要参与到数据捕获和传输过程中 SharePlex 的捕获进程不但可以读取在线的日志文件 而且可以读取归档日志 甚至当 归档日志文件被移动到其它设备上时 SharePlex 会发出提示信息 正是这种能力极大地增 强了系统的冗余功能 例如 如果捕获进程由于某种原因被停止 当它重新启动后数据同步 不会受到影响 数据传输数据传输 SharePlex for Oracle 在基于 TCP IP 协议的网络环境完成源和目标系统之间的数据传输 其相关的进程确保数据的正确接收和网络数据包的正确顺序 从而提供网络传输冗余 确保 数据的完整 整个数据传输过程无需其它的中间件 应用数据应用数据 应用进程将传送到目标系统中的信息转化为 SQL 语句 然后发送给 Oracle 执行 S 11 Internal Partner Win Story SharePlex 能够实现精确复制的一个重要原因就是其能保证从源数据库到目标数据库的 Oracle 读一致性 不但按顺序复制事务 而且也复制上下文信息 将源数据库中发生变化的 全部事务信息都复制到目标数据库中 3 2系统构架图系统构架图 环境说明 环境说明 1 日常业务运行在生产数据库上 2 通过逻辑复制方式将生产数据库同步到容灾数据库 3 使用 SharePlex 复制出来的生产数据库的副本一直处于打开的状态 在提供数据库容 灾安全保障的基础上 还可为报表和查询业务提供数据源 分担生产系统的压力 3 3容灾接管和反向回切容灾接管和反向回切 S 12 Internal Partner Win Story 业务的连续性是保证服务质量的重要标准之一 一旦应用系统数据库出现故障 将影响 所有关键业务 系统恢复时间的长短 将直接影响到服务质量 应用接管应用接管 当生产数据库出现故障或事故无法使用时 应用程序可以立即接管到容灾数据库上 由 于目标数据库一直处于打开的状态 所以接管时间非常短 基本等于应用程序修改数据库连 接的时间 反向回切反向回切 通过 SharePlex for Oracle 复制技术 业务系统能快速反向回切 对恢复正常的生产数 据库不需要进行数据全同步或重新部署复制软件 仅将增量数据回写即可完成生产系统恢复 工作 SharePlex Oracle RAC Oracle S 13 Internal Partner Win Story SharePlex OracleOracle RAC 3 4RTO RPO指标规划指标规划 采用交易级数据实时备份技术 在 RTO RPO 指标方面可以做到 RPO RPO 指标取决于源端日志分析的频率 日志分析的效率 网络带宽和容灾端装载性能 SharePlex 在源端日志分析频率为 1 秒 即每间隔 1 秒钟判断日志是否有新的变化 加 上网络延迟和装载延迟 一般情况下 SharePlex 的复制延迟保证在 10 秒至 5 分钟之内 但建议关键系统在制定 RPO 标准时可以适当的留出一定富裕量 建议设置为 10 分钟 RTO RTO 指标牵涉到数据库接管时间 应用服务器的切换时间和终端的切换时间 对于采用交易复制技术的解决方案来说 在发生故障切换时 容灾端的数据库本来就处 于打开状态 所以不需要重新启动数据库 但是由于在正常复制过程 容灾数据库上的 trigger 是被 disable 的 所以在业务接管之前需要激活 trigger 所需要的时间根据 trigger 的 数量来定 一般可在 10 分钟以内完成 S 14 Internal Partner Win Story 4业务连续性和数据灾备方案选型业务连续性和数据灾备方案选型 4 1本地业务连续性和报表分离方案本地业务连续性和报表分离方案 本地业务连续性方案设计的关键因素 通过将查询类业务从生产系统进行分离 降低生产系统的负载 提供系统的可用 性和性能 在出现问题时 能够快速进行接管 提供反向回切能力 保障核心业务的可用性 支持灵活的平台 可以提供多种可选方案 节省投资 提高整体回报 根据上面的关键设计因素 对比所有的复制方案 以 SharePlex 为代表的数据库逻辑复 制解决方案提供了更快的接管时间 更方便的接管和反向回切方法 同时保证目标端数据库 可访问 提供查询报表能力 是适用于上述需求的首选复制解决方案 4 2同城异地灾备方案同城异地灾备方案 同城异地灾备中心兼顾业务连续性和数据安全性 异地灾备系统设计的关键因素 数据保护能力 需要规避数据风险 包括数据在任何情况下万无一失 目标数据库的可用性 目标系统的可用性可以满足未来的扩展性需求 接管和反向回切 出现问题后可以进行应用接管后 当原系统恢复正常时 将接 管期间的增量数据反向同步回去 平台支持的灵活性 灵活的平台支持可以提供多种可选方案 节省投资 提高整 体回报 从方案设计来看 可以采用基于磁盘级复制技术 也可以采用基于数据库逻辑复制技术 的方案 前者可以设计为同步复制模式 能够做到 零数据丢失 但是可能出现基于硬件 错误数据库无法启动的风险 而且管流程非常复杂 接管时间较长 在真正发生问题时很多 S 15 Internal Partner Win Story 容灾中心很难启用 后者提供根据更快的接管时间 更方便的接管和反向回切方法 同时目 标端数据库可访问 提供查询报表能力 具体方案可以根据用户的需求进行选择 很多情况 下 用户同时选择逻辑复制和物理复制的解决方案 4 3超远距离超远距离异地灾备异地灾备 异地灾备系统设计的关键因素 数据保护能力 建立异地灾备系统最重要的目标是保障核心业务系统的数据安全 需要规避数据风险 包括数据在任何情况下万无一失 网络带宽使用 带宽使用较少不仅可以减少电信网络的租用费用 还可以满意日 后数据增长的扩展性需求 复制延迟 数据延迟关系到灾难发生时的数据丢失多少 对于异地灾备来说 任 何复制技术必然会数据延迟和数据损失 数据损失越少越好 目标数据库的可用性 目标系统的可用性可以满足未来的扩展性需求 接管和反向回切 出现问题后可以进行应用接管后 当原系统恢复正常时 将接 管期间的增量数据反向同步回去 平台支持的灵活性 灵活的平台支持可以提供多种可选方案 节省投资 提高整 体回报 4 4多灾备中心方案设计多灾备中心方案设计 对于很多对业务连续性和数据安全性要求很高的系统 可以设计多灾备份中心方案 当本地生产中心发生全局性运营中断事件之后 备用中心能够按计划接管生产中心的数据或 者应用 从而实现业务持续运营 S 16 Internal Partner Win Story 集成方案推荐同时采用存储层复制技术和数据库逻辑层复制技术 实现以下业务连续性 和数据安全性的以下战略目标 最大程度地保障了数据安全 最大程度地保障了数据安全 解决方案提供物理级和逻辑级双重保护 在同城异地和远程都建立了灾备系统 无论主 机 数据库 存储或站点失败 都可以通过最佳方式恢复数据 更重要的 通过数据库逻辑 复制方式复制的数据库处于打开的状态 确保了数据的安全性和可访问性 集成解决方案也 提供更多的灾难恢复保护 通过本地的同步磁盘镜像方案可以保障数据的 零损失 而基 于数据库逻辑级别的复制提供了对逻辑坏块和人为的错误操作 提供全方位的业务连续性保障能力 提供全方位的业务连续性保障能力 解决方案提供了同城异地和远程异地容灾实例 采用了物理和逻辑的两种实现技术 在 本地的主机 数据库 存储或网络出现问题时 通过同城异地灾备系统进行接管 在站点失 败时 可以通过远程异地灾备中心进行接管 有效地保障了业务连续性 S 17 Internal Partner Win Story 平战结合的容灾方案 提高投资回报 平战结合的容灾方案 提高投资回报 通过数据库逻辑复制方式提供的目标数据库实时可用 可以平时用作查询 综合统计等 业务 建立了真正意义上的 双活 设计 提高总体投资回报 5成功案例成功案例 SharePlex for Oracle 产品面世已经有十年时间 目前在全球范围内有 1000 家以上的 成功案例 其中中国大陆地区有 70 家 5 1银联数据银联数据 银联数据服务有限公司是中国银联股份有限公司 简称 中国银联 的子公司 公司 成立六年来 以银行卡发卡数据处理外包服务为突破口 秉承 市场第一 客户第一 服务 第一 的企业理念 积极进取 勇于开拓 赢得了广大客户的信任和尊重 在国内发卡数据 处理外包服务市场处于绝对领先地位 截止 2009 年 6 月 30 日 公司已经与兴业银行 民生 银行 华夏银行 中国邮政储蓄银行 花旗银行 东亚银行等境内外 66 家机构签署发卡外 包服务合同 其中 58 家机构已经在银联数据发卡系统上发卡运营 卡量累计 1700 万张 公司主要业务包括 贷记卡业务 银联数据为客户银行提供发卡业务的一揽子解决方案 包括客户银行 的信用卡中心设计 业务规划 系统建设 业务培训和咨询 7X24 小时运营 全程 服务 目前 已经与银联数据合作以外包模式发卡 和正在积极筹建中的合作方已 有邮政储蓄银行 华夏银行 民生银行 兴业银行 东亚银行等四十余家银行 借记卡业务 是一个以处理卡片支付为主线 处理整个零售银行业务的系统 已经 过多年的实际生产验证 该系统具有客户管理 产品定义 卡片管理 账务处理与 会计核算 业务处理和风险控制等基本功能 支持转账与支付 储蓄存款 小额信 贷 个人理财等零售银行业务处理 提供有灵活的卡产品 业务产品定义和卡片 客户个性化服务定制功能 S 18 Internal Partner Win Story 银联数据预付卡业务 是一个专门用于发行和管理小额支付卡的系统 能够支持国 内外金融机构 非金融机构发行支付卡的业务处理 系统具有产品定义 卡片管理 和行业支付等基本功能 提供有灵活的卡片个性化服务定制功能 业务挑战业务挑战 为了提高为各个银行提供卡业务的服务质量 银联数据计划在北京建设异地灾备系统 技术需求如下 接管时间 RTO 2 小时 数据恢复点目标 RPO 15 分钟 目标系统平时能够承担查询业务 实时可用 对网络带宽的使用小 节省电信网络租用费用 提高投资回报 不影响源系统的运行 可扩展性强 能够支持未来三年的数据量 解决方案解决方案 银联数据在与其它方案进行了仔细对比以后 确定选用 Quest 公司的 SharePlex 解决方 案 SharePlex 具有对带宽要求低 对源系统性能影响小 容易部署等特点 SharePlex 解决方案如下图 S 19 Internal Partner Win Story 生产系统采用了 Sun 25K 建立了四个分区 每个分区上运行 1 到多个 Oracle 实例 包括不同公司的信用卡 贷计卡信息 针对每个实例 建立从上海到北京的复制链路 通过 Shareplex 建立生产中心到灾备中心的异地数据复制 当灾难发生时 通过灾备库进行容灾接管 灾备库可以在平时运行查询业务 生产中心每台机器上可能有多个数据库 与目标端的数据库一一对应 用户收益用户收益 银联数据异地灾备项目实施后通过部署 Shareplex 解决方案 用户获得了以下收益 O Or ra ac cl le e R RA AC C O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e R RA AC C O Or ra ac cl le e O Or ra ac cl le e S Sh ha ar re eP Pl le ex x O Or ra ac cl le e O Or ra ac cl le e O Or ra ac cl le e 分分区区A A 分分区区B B 分分区区C C 分分区区D D S SF F 2 25 5K K S SF F 1 15 5K K S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x S Sh ha ar re eP Pl le ex x 生生产产数数据据库库灾灾备备数数据据库库I In nt te er rn ne et t 上上 海海 北北 京京 S 20 Internal Partner Win Story 1 实现了容灾系统建设目标 解决方案充分实现了容灾系统的建设目标 目标数据库出于打开的状态 能够确保目标 数据的安全性 经过了几次容灾演习 非常顺利地实现应用接管和反向回切 RTO 和 RPO 满足大大低于预订目标 2 网络带宽使用少 维护成本低 银联数据采用从上海到北京的复制 在目前带宽为 4M 的情况下能够保障复制的实时性 Shareplex for Oracle 方案对带宽的使用只有日志文件 1 3 对带宽占用较少减少了每年租 用带宽的成本 提供了总体投资回报 全面提升了银联数据的服务能力 容灾系统建设后 为银联数据的中小银行的信用卡和贷计卡提供了容灾服务 服务的提 升可以避免现有客户的流失 保持企业竞争力 5 2山西移动山西移动 用户概述用户概述 中国移动通信集团山西有限公司 简称中国移动山西公司 于 1999 年 9 月 1 日成立 2002 年 7 月在香港和纽约成功上市 成为中国移动 香港 有限公司的全资子公司 注册 资本 28 亿元人民币 资产规模超过 80 亿元 服务的用户数接近 1500 万 山西移动主要经营移动话音 数据 IP 电话和多媒体业务 计算机信息网络国际联网和 基于移动通信业务的各类增值业务 除提供基本话音业务外 还提供数据 传真 IP 电话 无线上网 宽带接入 视讯通 移动办公 信息点播 彩铃 彩信 手机证券等多种增值业 务 拥有 全球通 神州行 动感地带 等著名服务品牌 目前全省已建成了以营业厅服务 1860 电话服务及互联网服务 大客户个性化服务为主 体的客户服务体系 营业网点达到 4200 多个 业务挑战业务挑战 S 21 Internal Partner Win Story 集中化管理是 IT 系统发展的一个趋势 山西公司在完成 BOSS 系统的集中化管理后 大大提高了系统的可维护性 可管理性 可扩充性 但正如把一筐鸡蛋放进一个篮子里一样 集中化管理也带来了一定的风险 而且 近几 年随着业务的发展 集中的 BOSS 系统所支撑的客户规模剧增 如何提高系统运行的高可靠 性 抵抗灾难 提高业务连续运行的能力就成为山西省移动公司现阶段面临的一个挑战 解决方案解决方案 山西移动根据业务的迫切需求 在与其它方案进行了仔细对比以后 确定选用 Quest 公 司的 基于 SharePlex 业务支撑系统应急 报表解决方案 SharePlex 具有对源系统性能影响 小 复制延迟小 并能快速的实现关键业务的接管与反向回切 以及分担查询报表等业务等 特点 SharePlex 解决方案如下图 S 22 Internal Partner Win Story 生产系统数据库 Oracle Standby 生产应用服务器 Oracle Oracle 查询应用服务器 Oracle SharePlex 备份磁带库 查询 应急数据库 RAC Archive log 生产系统使用采用 Oracle RAC 架构 由两个节点共同承担业务的访问 生产系统的数据安全主要有本地的磁带备份与基于 Oracle Standby 技术的容灾数据库保障 应急 报表数据库采用 SharePlex 数据复制技术 实施的同步生产系统中交费等关键业务 以及报表业务所需数据 应急 报表数据库一直处于可用状态 可分担生产系统的查询业务 以减轻生产系统数 据库的负担 当生产数据库出现系统故障 无法对外提供服务时 可由应急 报表数据库在 3 5 分钟 内实现关键业务的接管 用户收益用户收益 山西移动的应急 报表方案能够解决各种发生概率较高的系统故障 保护关键业务应用 在 7X24 小时内不间歇运行 从技术上保障了业务系统的连续性和数据的安全性 独立的报 S 23 Internal Partner Win Story 表 查询数据库也大大减轻了生产系统的负担 使得高峰期业务办理的性能有了大幅度的提 高 快速应用接管和反向回切快速应用接管和反向回切 山西移动应急方案充分考虑到了应用 数据和系统各级的保护 当生产系统出现任何软 件 硬件或其他不可知故障时 占整个业务量 75 以上的关键业务能迅速的实现应用的接管 接管步骤可在几分钟内完成 当应用切换到应急系统后 SharePlex 的数据复制会自动切换 成由应急系统到生产系统的反向复制 并把切换之后产生的数据变化 以对列文件的形式缓 存在 SharePlex 独立的队列文件系统中 而当生产系统数据库恢复后 可将切换后所有的数 据变化 反向增量同步回生产数据库 同时应用可以迅速切换回生产数据库运行 SharePlex 的应急解决方案大大的降低了切换时间 切换风险以及切换操作的成本 为 山西移动的业务支撑系统提供了有效的业务连续性保障 报表及查询业务的分担报表及查询业务的分担 通过应用和中间件双重灵活配置 充分保证了各种情况下报表打印和数据查询的正确性 即达到了降低生产数据库的额外压力 又满足了前台业务人员对业务数据即财务数据稽核的 要求 根据报表中心迁移到应急数据后对营业数据库性能分析 正常时段内 营业数据库的等 待事件平均下降了 10 业务高峰时段内等待事件下降了 20 左右 以前月初由于月报表 打印导致回滚段资源紧张的情况已经不再出现 由于报表的分离 目前前台核心业务报表的 打印速度提升了 30 左右 5 3北京地税北京地税 用户概述用户概述 北京市地方税务局是主管北京市地方税收工作的市政府直属机构 于 1994 年 8 月 15 日 正式成立 业务上接受国家税务总局的指导 它主要负责组织实施北京市各税 费 种的征 S 24 Internal Partner Win Story 收和管理 不包括已明确由国家税务机关负责征收的地方税部分 同时进行税务法规 宣 传等方面的等方面的工作 北京地方税务局于 1995 开始建设税务管理信息系统 已经形成了连接全市 23 个区县分 局及 217 个税务所的三级税务专网 实现了税收征管 办公及综合管理业务的电子化 目前 北京地方税务局已经具备了进一步利用新技术 发展新的电子化应用 拓宽税收征管信息化 应用领域 开展基于互联网技术的高度统一 严格规范的纳税服务的条件 北京地税的容灾系统于 2004 年开始建设 其核心复制软件 Quest Software 的 SharePlex 不但达到了系统的高可用性的目标 而且实现了投资收益的最大化 业务挑战业务挑战 随着最终客户网上纳税的开通 网上纳税的服务内容包括网上申报 企业年检审批 综 合查询等业务 以及数据集中机制的施行 鉴于税务行业的特点 最终客户对业务连续性 和企业数据安全性的要求也越来越高 建设一个可靠而高效的容灾系统成为当务之急 另外 由于数据量的不断增加 市局和各个区县