只有奋斗的过程才是最真实的

那么假设我们周一晚上做了一个数据库的备份，周二中午12点数据库存储介质出现了故障。如何能够实现恢复呢?那么首先是把数据库恢复到我们备份的那个时刻（周一晚上），但是备份之后和周二12点之间对数据库已经做的交易（事物）怎么办呢？这就需要用到数据库日志，因为一旦交易提交，我们对数据库做的SQL（insert、update、delete等）都会记录到数据库日志中。所以我们就用数据库日志（前提是数据库日志没有受到损坏）把备份之后和数据库崩溃之前的所有SQL操作重做（redo）一遍，。这就是数据库备份恢复的原理。

1、DB2数据备份和恢复实验准备工作

Step1：创建测试数据库TestDB

1CREATE DATABASE TestDB
2ON 'E:'
3USING CODESET GBK TERRITORY CN
4WITH 'DEMO TestDB';

结果：

*** SCRIPT START: Connection: LENOVO-MILO-DB2-TOOLSDB (db2admin)  Jul-09-2009 14:34:49 ***

CREATE DATABASE TestDB
ON 'E:'
USING CODESET GBK TERRITORY CN
WITH 'DEMO TestDB';
completed successfully.
DB20000I  CREATE DATABASE命令成功完成。

Statement processed successfully in 32.42 secs.

*** SCRIPT END  : Connection: NONE  Jul-09-2009 14:35:21 ***



Step2：创建数据库管理表区间Data_SP(要先设置好路径和文件)

此处的路径为：E:\DB2_Train\TestDB\UserData
文件名设置为：TestDB.UserData

1CREATE REGULAR TABLESPACE Data_SP
2
3PAGESIZE 4K
4
5MANAGED BY DATABASE
6
7USING(FILE 'E:\DB2_Train\TestDB\UserData\TestDB.UserData' 2560)
8
9BUFFERPOOL IBMDEFAULTBP;

这里设置了初始化为4K * 2560 = 10MB的表空间

结果：TableSpace里面多了一个名为Data_SP表空间

 

Step3：创建测试表TestTable

1CREATE TABLE TestTable
2(
3   ID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY(START WITH 0 , INCREMENT BY 1, NO CACHE),
4   Message VARCHAR(100),
5   PRIMARY KEY(ID)
6)IN Data_SP;

结果:
:

Step4:在TestTable下面插入测试数据

1INSERT INTO TestTable(Message) 
2VALUES('测试表建立成功')

--说明:建立测试表并插入数据是为了稍后验证数据库恢复的时候用的--

结果：


或者可以使用

1db2stop force
2db2start
3db2 connect to TestDB
4db2 select * from TestTable

Step5：DB2数据库脱机备份和恢复实验

说明：我将脱机备份的文件放在了以下路径中：E:\DB2_Train\Offline

1、完全脱机备份数据库

 1db2stop force    //停止及启动DB2实例
 2db2start
 3
 4db2 connect to TestDB    
 5//指定当前活动的数据库为TestDB
 6
 7db2 backup db TestDB to "E:\DB2_Train\Offline"
 8//完全备份数据库,(脱机,备份时间戳为20090709152004)
 9
10

2、模拟灾难现场，强制删除TestDB数据库

1db2 drop db TestDB

3、根据数据库完全备份恢复数据库

1//利用离线完全备份恢复数据库
2db2 restore db TestDB from "E:\DB2_Train\Offline" taken at 20090709152004

4、查询表TestTable里面内容，这一块要重点关注，因为它涉及三种备份方式的区别

1db2stop force
2db2start
3
4db2 connect to TestDB
5
6db2 select * from TestTable

Step6、DB2数据库增量备份和恢复实验

1、查看数据库配置文件

1//查询数据库配置文件里的参数TRACKMOD的状态,默认为OFF
2db2 get db cfg for TestDB

2、修改数据库配置参数TRACKMOD，使之数据库进行增量备份

1//设置参数TRACKMOD为YES,使之数据库可以进行增量备份
2db2 update db cfg for TestDB USING TRACKMOD YES

3、更改参数后，必须需要完全离线全备份数据库

1//修改参数后需要全备份数据库，脱机，时间戳为20090709163256
2db2 backup db TestDB to "E:\DB2_Train\Online"

3、查看TestTable表的内容



4、插入测试数据

这里我要说明一下为什么要在表这里插入测试据？

状态	TestTable表里MESSAGE的值	备注
全备份	测试表建立成功
插入数据	测试表建立成功 开始增量数据库备份测试
增量备份	测试表建立成功 开始增量数据库备份测试
还原全备份	测试表建立成功
还原增量备份	测试表建立成功 开始增量数据库备份测试

1--插入数据 开始增量数据库备份测试--
2INSERT INTO TestTable(Message)
3VALUES('开始增量数据库备份测试')

5、开始增量备份（脱机备份）

1//增量备份数据库,脱机，时间戳为20090709170956
2db2 backup db TestDB incremental to "E:\DB2_Train\Online"

6、模拟灾难，强制删除数据库

1//强制删除数据库,模拟灾难现场
2db2 drop db TestDB

7、恢复数据库

首先还原至完全离线备份状态，然后还原至增量离线备份状态

7.1、还原至完全离线备份状态

1//还原离线完全备份数据库，脱机，时间戳为20090709163256
2db2 restore db TestDB from "E:\DB2_Train\Online" taken at 20090709163256

这里要注意还原完全备份后TestTable表里Message的值，也是为什么要加入测试数据的原因



7.2、还原至增量离线备份状态

1//--注意：下述语句中，有一个 automatic ，它表示无论有多少个增量备份，系统将全自动检索恢复数据库的顺序并自动恢复数据库。如果没有 automatic ，则需要多次手动恢复数据库，很麻烦而且容易出错
2db2 restore db TestDB incremental automatic from "E:\DB2_Train\Online" taken at 20090709170956
3//然后提示想继续吗y OR n,然后点击y进行恢复
4

Step7、DB2联机备份和恢复实验

联机备份数据库可以使数据库在备份的同时仍然保持在可用状态。要让数据库支持联机备份，必须更改数据库的日志归档方式。在脱机备份模式下，数据库采用循环日志方式记录数据库日志，在联机备份模式下，数据库则采用归档日志的方式备份数据库日志。另外，对于联机备份的数据库来说，活动日志和归档日志就很重要了，一定要经常备份、保存，像银行多数使用的是归档日志的方式，因为银行的数据关乎到民生的生活，哪怕是突然间断电了，数据库崩溃了，但是每一笔的银行交易都需要时时刻刻把交易记录保存下来，所以这里的联机备份模式就很适合这类的应用场景

1、实验开始之前，最好先重新启动数据库实例，并且连接到需要做联机备份的数据库，此例数据库为TestDB

1db2stop force
2db2start
3db2 connect to TestDB

1--开始联机备份恢复测试--
2INSERT INTO TestTable(Message)
3VALUES('开始联机备份恢复测试')