解读IBM DB2容灾备份方案

数据库 容灾备份
企业信息化过程中,说起数据库“亡羊”的故事——数据丢失事故,真是让人痛心疾首。特别是以数据为营业主体的行业,例如彩票行业这个“羊”实在是“亡不起”呀!一旦有所闪失,不仅要承担商业利益的损失,而且无形中商誉损失不可预计,更有甚者会存有法律风险。

我们要讲述的就是某省级体彩中心下辖投注站数据遗失及补救的案例,该投注站由于数据遗失对于日常业务产生了很大的影响,迫切需要一套解决方案。彩票的业务模式是将散落的数据“集中”到省级中心的数据库中,并上传国家级数据备份中心,这是一个典型异地、异构数据备份系统。主要特点体现在:

  1. 营业终端条件差,仅就硬件方面考虑,服务器被盗、火灾 、硬盘整体损坏、其他物理损伤都会造成数据的丢失。
  2. 地域分布广,受终端投入的局限,仅能借助窄带宽跨互联网进行实时环境下的数据库复制,得以容灾。
  3. 依据业务数据承载量的不同,省级中心和各级投注站使用的数据库不同——中心使用DB2,投注站或县级中心有的采用Oracle,有的Sybase,或直接就是SQL Server。
  4. 业务的不可中断性要求数据实现分钟级的实时同步。并将历史数据放在独立数据库,使得读、写分别指向不同的数据库提升性能。

我们讲述故事中,所幸的是丢的仅是个别“羊”只——个别投注站上传数据丢失、利用较窄带宽传输数据“失真”——局部号段错位、丢失,等等,好在还没有丢失“羊群”,但这个警钟已敲响,彩票在投注站打印出来就形成了合同关系,如中奖数据丢失还需给付奖金造成的损失都是由省体彩中心“买单”的。

究其上述某省级体彩中心数据丢失灾难的原因是因为存在手工上传数据时低带宽环境的信号延时、不同数据库类型间转换数据等潜在的漏洞,这些漏洞更需“补牢”,而且这次“补牢”需要一个彻底的解决方案——实现数据库异构备份:各投注站与省级中心间、各省级中心与国家中心间都要建立跨平台的“N+1”模式容灾。 纵观各路数据库备份产品中,能够实现异构备份者已是凤毛麟角。再论性能优劣、技术前瞻性、客户口碑,IBM TSM(Tivoli Storage Manager)备份管理工具实为最佳选择。

IBM TSM全面支持主流平台和主流厂商的数据库系统,包括Oracle、DB2、Informix、SQL Server、Sybase等。对于异构数据库(以Oracle为例),使用TSM的数据库保护模块TSM for Database/Oracle能够很好的对其进行全面的保护——使用数据库的备份接口,以透明化的方式提供数据库管理员一种进行数据备份的方法。基本原理是:

  1. 捕捉:在源数据库实时读取交易日志捕捉数据变化并可实现过滤 。
  2. 队列文件:暂存数据变化。
  3. 传输: 数据经过压缩和加密传送到目的地。
  4. 执行所需的数据变化,然后将数据变化提交到目的库。

仍以Oracle为例,备份Oracle数据库需要TSM for Database/Oracle,它利用ORACLE数据库提供的备份接口RMAN来对数据库进行备份。Oracle备份工具RMAN能够生成需要备份的数据文件,并能够保证数据库的一致性,所有的热备和逻辑备份都通过Oracle RMAN唯一接口进行。Tivoli可以利用这些工具实现对Oracle数据库的各种对象进行在线/离线备份,另外通过RMAN增量备份的机制,TSM可以实现对Oracle数据库的增量备份。而在被备份数据的输出上采用了和TSM结合的方式,TSM就是一个双向管道,一方面利用数据库的API和数据库备份软件连接,另一方面利用TSM的API和TSM连接,将数据库备份软件的输出传送到TSM管理的备份介质中。在Oracle中,直接设置了和TSM的连接,只需要在Oracle的相关配置中设置TSM服务器的名称和IP地址即可。为了减少DB主机压力和减少备份时间,对于Oracle数据库,同时能够提供数据库的增量备份,仅仅备份包括自从上次备份过程以后被改变过的data files的data blocks。这些数据可以和上面谈到的文件备份分开,存在不同的存储池中,通过不同的存储策略来进行管理。

恢复同样可以根据发生故障的种类,在数据库管理员的判断下,灵活的针对数据库的任意一个部件进行。如果业务数据量较大,建议对数据库的全备份每天或每两天做一次,而每隔一段时间备份数据量较小的Transaction Log。当发生数据损坏或丢失时,先恢复最近备份的数据库和Transaction Log,再用Transaction Log进行Forward Recovery,从而将数据库恢复到最近一次备份Transaction Log时的状态。在这种备份策略下,最坏情况会丢失一段时间的数据。通过将备份Transaction Log的时间间隔减小,例如减小到每小时备份一次(这一备份时间间隔应根据Log数据量和网络带宽情况制定),能够最大限度地减少数据丢失;对于 master database的数据,由于数据量不会太大,而且数据变化相对较小,所以建议每周做一次全备份。

综上所述,使用TSM能够灵活的对用户的异构数据库自动化的定时进行备份的工作,已达到容灾的效果——应用到上述省级彩票中心的案例中,在全省方位内没有对终端数据库进行改造的前提下,可以将各投注站或县市级体彩中心数据“整齐划一”,也彻底消灭了数据丢失!而且与主要竞争对手的备份方案各方面对比,详见下表,均有优势。通过上述技术性能的阐述,TSM作为当今面临数据爆炸式增长环境中,企业成功管理和控制 “信息浪潮”的利器,应该被人信服的。唯一有所忌惮的是先期成本的投入,诚然TSM这样优秀产品是有代价的。但“补牢”后,不仅不会再丢羊,而且羊儿会更强壮!——有助于提高IT操作的效率, 帮助削减与存储管理相关的成本,特别是数据灾难的“沉没成本”。

【编辑推荐】

  1. 令我难忘的DB2数据库之路
  2. DB2复杂的应用环境中的性能优化
  3. DB2并发连接时的性能考虑
  4. DB2实用程序的性能优化
  5. 一个笔记告诉你,从Java存储转到SQL存储的过程
责任编辑:艾婧 来源: ITPUB
相关推荐

2010-08-18 10:59:20

IBM DB2 Cat

2010-08-17 13:37:18

DB2 Online

2012-11-21 18:25:08

容灾备份数据中心华为

2009-03-25 17:43:09

备份DB2IBM

2010-08-12 16:10:45

DB2 Online

2010-11-03 10:35:45

DB2存储过程

2010-11-03 14:05:58

DB2离线备份

2010-11-03 14:16:29

DB2增量备份

2011-03-28 12:42:35

ibmdwDB2

2010-11-02 10:07:46

DB2数据库备份

2020-03-16 12:39:47

容灾备份规划

2009-07-22 14:44:36

ibmdw

2010-07-29 13:09:48

DB2 9.7 兼容

2010-01-08 11:47:15

ibmdwDB2

2011-05-17 10:11:24

IBM DB2维护

2010-08-18 16:45:40

IBM DB2 Cat

2010-08-26 10:13:52

DB2java连接

2009-04-01 14:07:44

表空间备份恢复

2010-11-03 14:57:44

DB2备份所有表

2010-09-01 11:17:29

DB2备份
点赞
收藏

51CTO技术栈公众号