谈谈IBM DB2的数据库备份与恢复

日期: 2008-03-12 作者:彭建军 来源:TechTarget中国

  本文探讨了基于 IBM DB2 的各种数据库备份与恢复策略,并附有完整的实验步骤。本文试图通过具体的实验使读者领会各种数据库备份方式的优劣和异同,并掌握 IBM DB2 的数据库备份与恢复技术。


  若无特殊说明,以下数据库备份与恢复的试验环境均为 Windows XP + IBM DB2 V9 企业版,同样的语句也在 AIX 5.2 + IBM DB2 V8.2 上验证通过。


  一、 数据库备份的重要性


  在信息日趋发达的时代,数据显得尤其重要。如何保障数据的完整性和安全性呢?如何避免数据灾难事故的发生呢?数据库备份作为数据安全和完整最有利保障手段的重要性就不言而喻了。


  数据库备份的重要性主要体现在:


  1、提高系统的高可用性和灾难可恢复性;(在数据库系统崩溃的时候,没有数据库备份怎么办!?)


  2、使用数据库备份还原数据库是数据库系统崩溃时提供数据恢复最小代价的最优方案;(总不能让客户重新填报数据吧!?)


  3、没有数据就没有一切,数据库备份就是一种防范灾难于未然的强力手段;(没有了数据,应用再花哨也是镜中花水中月)


  4、对于DBA来说,最首要也是最重要的任务就是数据库备份。


  二、 DB2 数据库备份的方式与分类


  1、按照数据库备份对数据库的使用影响来划分
  A、联机备份(也称热备份或在线备份)
  B、脱机备份(也称冷备份或离线备份)


  说明:联机备份和脱机备份最大的不同在于:联机备份数据库时,数据库仍然可以供用户使用,而脱机备份数据库则不行。脱机备份数据库时,必须断开所有与数据库有连接的应用后才能进行。


  2、按照数据库的数据备份范围来划分
  A、完全备份
  B、增量备份


  说明:完全备份数据库是指备份数据库中的所有数据,而增量备份只是备份数据库中的部分数据。至于增量备份到底备份哪些数据,稍候会提到。
  3、增量备份的两种实现方式
  A、增量备份(也称累计备份)
  B、delta备份


  说明:这两种备份方式的严格定义如下,
  增量备份是自最近成功的完全备份以来所有更改的数据的备份。
  delta 备份则是上一次成功的完全、增量或 delta 备份以后所做更改的数据的备份。


  这里请读者们仔细的看上面两个增量备份方式的定义,注意这两种备份方式的细微差别。这里我们举一个例子来说明。


  假设有一个数据库,它每天都有部分数据在发生变化。我们星期一晚上对该数据库做了一次完全备份,星期二晚上对该数据库做了一次增量备份A(注:这里的增量备份是指累计备份,下同),星期三晚上又做了一次增量备份B,星期四则做了一次delta 备份。


  那么,我们可以得出以下结论:
  星期一的数据库备份包含了所有的数据。
  星期二没有变动过的数据没有发生备份,在星期二变动过的数据会备份,并且备份到增量备份A中。
  星期三的备份中含有自星期一完全备份以来发生过变动的所有数据,包含了星期二和星期三发生过变动的数据。显然,增量备份A 被 增量备份 B 包含。
  星期四做的是delta备份,注意,它会也只会备份自星期三备份之后变动过的数据。


  三、 DB2 备份文件的结构介绍


  在不同的操作系统下,DB2 的备份文件的结构是不同的,这里概要地介绍一下。


  1、 Windows 操作系统下的数据库备份文件结构:



 


  说明:Windows 操作系统下的数据库备份文件是嵌套在一系列文件夹之下的特殊结构。上例中,D:DB2_Train 是指备份目录,TESTDB.0 是指数据库名称为 TESTDB,DB2 是指实例名称,NODE0000 是指节点名称,CATN0000 是指编目名称,20070801 是指备份发生的年月日,形如YYYYMMDD,181241是指备份发生的时间,精确到秒,也就是指 18 点 12 分 41 秒,形如HHMMSS,最后的 001 则是备份文件的一个序列号。


  2、 Unix 操作系统下的数据库备份文件结构:




  说明:Unix 操作系统下的数据库备份文件就是一个文件。上例中,HTDC 是指数据库名称,db2inst1 是指实例名称,NODE0000 是指节点名称,CATN0000 是指编目名称,20070310002357 是指备份发生的具体时间,形如YYYYMMDDHHMMSS,同样地,它的时间精确到秒,也就是指 2007年3月10日0点23分57秒发生备份,最后的 001 则是备份文件的一个序列号。


  四、 DB2 数据库备份实验(附完整命令脚本清单)


  4.1 DB2 数据库实验准备工作
  (1)、Step1:创建测试数据库 TestDB


  脚本清单


  CREATE DATABASE TestDB
  ON ‘D:’
  USING CODESET GBK TERRITORY CN
  WITH ‘Pjj”s Test DB’;
  }


  (2)、Step2:创建数据库管理表空间 Data_SP(注意路径,如果没有请创建)


  脚本清单


  CREATE REGULAR TABLESPACE Data_SP
  PAGESIZE 4 K
  MANAGED BY DATABASE
  USING ( FILE ‘D:DB2ContainerTestDBUserDataUserData’ 2560 )
  BUFFERPOOL IBMDEFAULTBP;
  说明:上面的脚本创建了一个名为 Data_SP 的数据库管理表空间,该表空间使用的缓冲池为 IBMDEFAULTBP,存储路径为 D:DB2ContainerTestDBUserData,存储文件名为 UserData,大小为 2560 * 4K = 10M,页大小为 4K。


  (3)、Step3:创建测试表 TestTable 并插入测试数据


  脚本清单


  CREATE TABLE TestTable
  (
  ID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 0, INCREMENT BY 1, NO CACHE ),
  Message VARCHAR(100),
  PRIMARY KEY(ID)
  )IN Data_SP;
  –插入测试数据 INSERT INTO TestTable(Message) VALUES(‘测试表建立成功’);
  说明:建立测试表并插入数据是为了稍候验证数据库恢复的时候用的。


  (4)、Step3:创建测试表 TestTable 并插入测试数据
  脚本清单


  CREATE TABLE TestTable
  (
  ID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 0, INCREMENT BY 1, NO CACHE ),
  Message VARCHAR(100),
  PRIMARY KEY(ID)
  )IN Data_SP;
  –插入测试数据
  INSERT INTO TestTable(Message)
  VALUES(‘测试表建立成功’);
  4.2 DB2 数据库脱机备份与恢复实验


  脚本清单


  –Step1:完全备份数据库(脱机,备份时间戳记为 20071121152940)


  db2 backup db TestDB to D:DB2_Train
  –Step2:模拟灾难,强制删除数据库


  db2 drop db TestDB
  –Step3:根据该数据库完全备份还原数据库


  db2 restore db TestDB from D:DB2_Train taken at 20071121152940
  4.3 DB2 数据库增量备份与恢复实验


  脚本清单


  –数据库增量备份以及还原实验


  –修改数据库参数 TrackMod ,使之支持数据库进行增量备份
  db2 update db cfg using TrackMod YES
  –更改参数后必须完全离线备份数据库(脱机,备份时间戳记为 20071121153818)
  db2 backup db TestDB to D:DB2_Train
  –插入测试数据
  INSERT INTO TestTable(Message)
  VALUES(‘开始增量数据库备份测试’);
  –开始增量备份(脱机,备份时间戳记为 20071121154006)
  db2 backup db TestDB incremental to D:DB2_Train
  –删除数据库,模拟数据灾难
  db2 drop db TestDB
  –首先还原至完全离线备份状态
  db2 restore db TestDB from D:DB2_Train taken at 20071121153818
  –还原至增量离线备份状态
  db2 restore db TestDB incremental automatic from D:DB2_Train taken at 20071121154006
  –注意:上述语句中,有一个 automatic ,它表示无论有多少个增量备份,系统将全自动检索恢复数据库的顺序并自动恢复数据库。如果没有 automatic ,则需要多次手动恢复数据库,很麻烦而且容易出错。


  –Step3:根据该数据库完全备份还原数据库
  db2 restore db TestDB from D:DB2_Train taken at 20071121152940
  –还原数据库后查询测试表数据检验数据是否恢复成功


  4.4 DB2 数据库联机机备份与恢复实验
  说明:联机备份数据库可以使数据库在备份的同时仍然保持在可用状态。要让数据库支持联机备份,必须更改数据库的日志归档方式。在脱机备份模式下,数据库采用循环日志方式记录数据库日志,在联机备份模式下,数据库则采用归档日志的方式备份数据库日志。另外,对于联机备份的数据库来说,活动日志和归档日志就很重要了,一定要经常备份、保存。


  脚本清单


  –数据库联机备份以及还原实验


  –连接至数据库并插入测试数据
  db2 connect to TestDB
  –插入测试数据
  INSERT INTO TestTable(Message)
  VALUES(‘开始联机数据库备份测试–完全备份’);
  –修改数据库参数,使之支持在线联机备份
  db2 update db cfg for TestDB using logretain on trackmod on
  –执行增量、在线备份之前必须执行离线全备份一次,否则数据库将处于备份暂挂的不可用状态
  –(联机完全备份,时间戳记:20071121160548)
  db2 backup db TestDB
  –连接至数据库并插入测试数据
  db2 connect to TestDB
  –插入测试数据
  INSERT INTO TestTable(Message)
  VALUES(‘开始联机数据库备份测试–增量备份’);
  –执行联机备份,备份同时再打开一个会话,模拟应用在线(联机增量备份,时间戳记:20071121152922)
  db2 backup db TestDB online incremental to D:DB2_Train
  –模拟灾难,删除数据库!
  –重要,此前一定要将活动日志文件备份至另一个路径,保存好,本例中,活动日志保存在 C:db2admin 下。
  db2 drop db TestDB
  –根据在线完全备份恢复数据库
  db2 restore db TestDB from D:DB2_Train taken at 20071121160548
  –根据在线增量备份恢复数据库
  db2 restore db TestDB incremental automatic from D:DB2_Train taken at 20071121152922
  –恢复后的数据库处于前滚暂挂的不可用状态
  db2 connect to TestDB
  –前滚数据库,并指定归档日志位置,重要!
  db2 ROLLFORWARD DATABASE TESTDB TO END OF LOGS AND COMPLETE OVERFLOW LOG PATH (“C:db2admin”)


  五. 综述


  对于数据库管理人员或者维护人员来说,怎么强调数据库备份的重要性都不为过。


  希望本文能抛砖引玉,能让大家对 IBM DB2 UDB 的数据库备份与恢复有一些深入的认识。也希望大家能在本机上按照本文的脚本认真的做一次实验,这样,你的认识会更加深刻。


  数据库崩溃和灾难并不可怕,可怕的是在发生数据库崩溃和灾难的时候没有数据库备份。这句话与各位数据库爱好者共勉。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐

  • 数据保护领域趋势:勒索软件,企业间的并购将占据头条

    2017年,勒索软件登上了国际新闻的头条,各大备份供应商亦纷纷推出其方案,加以针对。另一方面,各大厂商忙于彼此并购,转向超融合备份。我们在这里排列了今年数据保护领域的趋势和见闻。

  • 评估数据备份与恢复过程的正确姿势

    数据丢失已是一种极为常见的难题,因此企业或组织会考虑将数以百倍的数据量进行备份,而在恢复时却远没有这么多。换而言之,这种备份定会产生些许商业价值;又或者是我们是否可以在保证商业价值的同时,减少些许工作量。

  • 让存储服务于数据库应用(下)

    改善数据库存储性能需要一个过程。在大多数环境中,其会要求到一些调优操作。调优的关键是能够满足今天的性能所需,并在今后性能要求增加时留有余地。

  • 让存储服务于数据库应用(上)

    许多企业的业务依赖于高效能的数据库应用。本篇概述了如何确保存储系统支撑您的数据库应用所需。