在DB2 V9版本中，提供了一个重要的新特性，即利用DB2表空间的备份来快速恢复数据库，甚至可以根据数据的重要性选择恢复一部分重要数据，达到快速恢复的目的。本文结合实例对DB2 V9的该重要技术特性做了详细介绍，希望对用户规划系统备份/恢复策略有所帮助。

关于DB2数据库的恢复(Rebuild)

当我们的DB2数据库由于一些严重错误 ( 如存储损坏等 ) 而导致数据库库损坏时，我们通常需要在修复相关错误后，通过Restore命令来进行数据库的恢复(DB2目前也支持通过 HADR 等多机容错机制实现系统高可用，本文仅对单机数据库损坏，需要进行数据库恢复的情况进行探讨 )。一般的做法是通过以前的数据库全备份来进行整库恢复，然后通过日志对数据库进行前滚(RollForward)，从而使数据库恢复到接近灾难点的时间。但当我们数据库的数据量较大时，数据库的全备份和整库恢复都会很是非常消耗时间的。

在DB2 V9版本中，提供了一个重要的新特性，即利用DB2表空间的备份来快速恢复数据库，甚至可以根据数据的重要性选择恢复一部分重要数据，达到快速恢复的目的。本文结合实例对DB2 V9的该重要技术特性做了详细介绍，希望对用户规划系统备份 / 恢复策略有所帮助。

场景1：利用表空间备份来重建整个DB2数据库

在进行数据库重建时，DB2 V9现在能够支持通过表空间一级的备份来重建整个数据库，而不需要整个数据库的全备份。DB2的此项能力使得我们对核心系统的重要数据进行快速备份和恢复成为可能。让我们首先看以下的一个例子： 

假设我们有一个数据库TEST，该数据库采用归档日志。某天，系统突然掉电，导致数据库存放的磁盘损坏了。这时，数据库将处于不可用的状态，作为 DBA，我们需要迅速对数据库进行恢复。假如该数据库有以下的表空间：

◆SYSCATSPACE ( 系统表空间 )

◆USERSPACE1 ( 用户数据表空间 1)

◆USERSPACE2 ( 用户数据表空间 2)

◆USERSPACE3 ( 用户数据表空间 3)

你手头可用于进行数据库恢复的数据包括 :

所有数据库日志文件由于日志被存放在另外的磁盘上(而且很多时，我们还会对日志进行镜像，因为它们实在太重要了)，因此它们没有损坏。

你没有数据库的全备份，但是你有以下的表空间备份：

◆TEST.3.DB2.NODE0000.CATN0000.20060515135047.001 – SYSCATSPACE 和 USERSPACE 1 表空间在 2006051513504 7 时间点的备份；

◆TEST.3.DB2.NODE0000.CATN0000.20060516135136.001 – USERSPACE 2 和 USERSPACE 3 表空间在 2006051613513 6 时间点的备份；

◆TEST.3.DB2.NODE0000.CATN0000.20060517135208.001 – USERSPACE 3 表空间在 2006051713520 8 时间点的备份。

对于传统的Restore和Rollforward的DB2恢复策略，我们需要一个数据库的全备份影像来进行数据库恢复然后利用日志来进行数据库的前滚(Rollforward)操作，但不幸的是，在本例中，我们并没有数据库的全备份，而只有不同时间做的表空间备份。

错误的数据库恢复方法

如果我们试图直接用表空间备份来恢复整个数据库，我们会得到以下的错误提示：

清单1 ：直接用表空间备份来恢复整个数据库的错误提示

db2 restore db test taken at 20060517135208

SQL2560N The target database is not identical to the source database

for a restore from a table space level backup.

上述命令支持完整数据库备份的数据库恢复，不支持表空间级别的数据库恢复。

利用表空间备份恢复数据库

在DB2 V9中，提供了一个新的功能，就是通过表空间备份和日志来快速重建整个 DB2 数据库，这个功能是通过在RESTORE DATABASE命令中加入REBUILD选项来实现的。

以下的步骤帮助我们通过REBUILD选项来利用表空间备份恢复TEST数据库：

第一步，我们利用表空间备份执行带REBUILD选项的RESTORE DATABASE命令恢复数据库。

清单2：通过REBUILD选项来利用表空间备份恢复TEST数据库

db2 restore db test rebuild with all tablespaces in database taken at 20060517135208

这一步我们是从已有的几个表空间备份影像中选取一个备份来进行数据库恢复。一般，我们会选取最近备份的表空间影像，这个备份影像我们称之为“目标影像”(Target Image)，因为它包含了我们用于恢复 TEST 数据库所需的最新的表空间备份、数据库配置参数、日志序列等重要信息。实际上，这个“目标影像”可以是任何一种备份 ( 全备份、表空间备份、增量备份、在线或离线的备份 )。在本例中，最近的一个备份影像是TEST.3.DB2.NODE0000.CATN0000.20060517135208.001，因此我们就选取它作为我们进行数据库恢复的“目标影像”。

当我们执行完上述RESTORE命令之后，TEST数据库的结构将被重建和恢复。我们可以得到数据库的参数和其备份历史之类的信息。如果我们发出LIST HISTORY命令 ( 如：LIST HISTORY ALL FOR TEST)，我们将得到以下的输出（参照清单 3） 。

清单3 ：使用 LIST HISTORY查询数据库备份历史信息

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID

— — —————— —- — ———— ———— ————–

R D 20060519121107001 F 20060517135208

—————————————————————————

Contains 1 tablespace(s):

00001 USERSPACE3

—————————————————————————

Comment: RESTORE TEST WITH RF

Start Time: 20060519121107

End Time: 20060519121108

Status: A

—————————————————————————

EID: 7 Location:

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID

— — —————— —- — ———— ———— ————–

R P 20060519121108001 F 20060515135047

—————————————————————————

Contains 2 tablespace(s):

00001 USERSPACE1

00002 SYSCATSPACE

—————————————————————————

Comment: RESTORE TEST WITH RF

Start Time: 20060519121108

End Time: 20060519121113

Status: A

—————————————————————————

EID: 8 Location:

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID

— — —————— —- — ———— ———— ————–

R P 20060519121113001 F 20060516135136

—————————————————————————

Contains 1 tablespace(s):

00001 USERSPACE2

—————————————————————————

Comment: RESTORE TEST WITH RF

Start Time: 20060519121113

End Time: 20060519121114

Status: A

—————————————————————————

EID: 9 Location:

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID

— — —————— —- — ———— ———— ————–

R D 20060519121107 R S0000001.LOG S0000003.LOG 20060518135208

—————————————————————————

Contains 4 tablespace(s):

00001 USERSPACE3

00002 USERSPACE2

00003 USERSPACE1

00004 SYSCATSPACE

—————————————————————————

Comment: REBUILD TEST WITH RF

Start Time: 20060519121107

End Time: 20060519121115

Status: A

—————————————————————————

EID: 10 Location:

如上，LIST HISTORY 命令产生了 4 条输出条目 (EID 7 – EID 10)，它们都和我们数据库的恢复有关。第一个条目，EID 7，包含了在 20060517135208 时间点做的备份影像，该备份影像中我们只对 USERSPACE3 做了备份。然而，回顾我们进行数据库恢复时发出的命令，参照清单 4。

 清单4:使用ALL TABLESPACES参数恢复数据库

db2 restore db test rebuild with all tablespaces in database taken at 20060517135208

 我们使用了ALL TABLESPACES参数要求恢复所有的表空间，所以DB2会利用LIST HISTORY中所看到的其它备份影像来恢复数据库其它的表空间( 注意，在使用 TEST.3.DB2.NODE0000.CATN0000.20060516135136.001备份影像进行恢复时EID=9，虽然该影像包括 USERSPACE2 和 USERSPACE3 的备份，但 DB2只恢复了USERSPACE2，因为 USERSPACE3 已经通过更新的备份影像 TEST.3.DB2.NODE0000.CATN0000.20060517135208.001完成恢复了 )。在完成上述恢复后，表空间将处于 ROLL-FORWARD 状态。通过LIST HISTORY命令，我们可以看到表空间都被置成了 WITH RF 标志，表明这些表空间处于ROLL-FORWARD 状态。另外，为了使该恢复顺利完成，所有备份影像都需要放在 HISTORY FILE所表明的备份路径下，否则 DB2将会给出一个无法找到备份影像的错误提示。

第二步，通过ROLLFORWARD DATABASE命令及TO END OF LOGS选项来前滚数据库TEST，使其恢复到最近的一个同步时间点(Point in Time)。

清单5：前滚数据库到最近的一个同步时间点

db2 rollforward db test to end of logs

 当所有表空间恢复完毕，它们将处于rollforward pending的状态，我们需要通过数据库日志和 rollforward 命令来对数据库进行前滚操作，从而将数据库置为正常(Normal)状态。

为了顺利完成前滚操作，从上述备份影像最早一个时间点到最近一个时间点之间的数据库日志必须存在，以用于将上述通过不同时间点备份影像进行恢复的表空间前滚到同一时间点上。本例中，从 20060515135047 到 20060517135208 时间点的日志必须存在，我们才可以将表空间同步到同一个时间点。如果我们还想继续前滚数据库，则我们还需要从 20060517135208 时间点往后的日志文件。

在本例中，我们假设这些日志文件都能够在LOGPATH数据库配置参数所指定的目录中找到，如果它们被移动了位置，则我们还需要在 ROLLFORWARD 命令中通过OVERFLOW LOG PATH选项来指定这些日志文件的新位置。

 第三步，通过执行ROLLFORWARD DATABASE命令来结束数据库前滚的状态。

 清单6：结束数据库前滚的命令

db2 rollforward db test stop

 该命令执行完毕后，TEST数据库就恢复到NORMAL状态，这样您就可以正常使用它了。