DB2 备份与恢复.docx

DB2 备份与恢复.docx

《DB2 备份与恢复.docx》由会员分享，可在线阅读，更多相关《DB2 备份与恢复.docx（34页珍藏版）》请在冰豆网上搜索。

DB2备份与恢复

备份与恢复

1.0简介

本教程是关于什么的

本教程讨论了备份与恢复主题。

它讲解了不同的恢复与日志记录方法，并详细描述如何使用BACKUP、RESTORE和ROLLFORWARD命令。

在本教程中，您将学习：

∙可用于DB2®的恢复方法

∙事务日志的概念和可用的不同类型的日志

∙可以使用的日志记录方法的类型

∙如何执行BACKUP操作

∙如何执行RESTORE操作

∙如何执行ROLLFORWARD操作

∙索引的重新创建问题

这是由六个教程组成的系列的最后一个教程，这些教程帮助您准备DB2V8.1forLinux,UNIX®andWindowsTMDatabaseAdministrationCertification考试（考试701）。

本教程中的资料主要针对该考试第6部分中的目标，该部分的标题是“备份与恢复”。

不需要DB2UniversalDatabaseTM的副本就能学完本教程。

但是，如果愿意的话，可以下载IBMDB2通用数据库，企业服务器版的免费试用版。

本教程的适用对象

为了理解本教程所提供的材料，您应该熟悉下列内容：

∙DB2环境（数据库管理器配置文件、数据库配置文件和DB2注册表变量等）

∙使用命令行处理器（CommandLineprocessor）和DB2GUI工具来调用DB2命令

∙不同的DB2对象（缓冲池、表空间、表和索引等）

∙可以针对数据库执行的基本SQL操作（UPDATE、INSERT、DELETE和SELECTSQL语句）

关于作者

RaulF.Chong是IBM多伦多实验室的一名数据库顾问，主要与IBM业务伙伴一起工作。

Raul已经在IBM工作了五年，其中三年从事DB2技术支持，两年作为专攻数据库性能调优、数据库应用程序开发以及从其它RDBMS迁移到DB2等方面的顾问。

Raul撰写了好几篇有关用于不同受支持平台的DB2方面的文章，包括DB2UDBforz/OS®andOS/390®以及DB2UDBforiSeries，当然还包括DB2forLinux、UNIX和Windows。

这些文章已经发布在DB2开发者园地网站上。

您可以使用该网站上的搜索域来查看它们；只要输入Raul作为搜索关键词即可。

可以通过rfchong@与Raul联系。

致谢

非常感谢DwaineR.Snow和ClaraLiu抽出时间来审阅本教程中的材料。

Dwaine具有丰富的DB2产品经验，而且还撰写了好几本有关这方面的书。

Clara也具有DB2方面的大量经验，并且为许多IBM业务伙伴和客户讲授DB2认证（DB2Certification）备考课程。

他们两位都提供了颇有价值的意见！

2.0数据库恢复概念

恢复方案

您永远不会知道系统何时会遇到灾难或故障。

最好的做法是做好准备，不仅要防止外界因素破坏数据，而且还要防止内部用户可能无意中用错误信息毁坏您的数据库。

您备份数据库了吗？

您能恢复直到最后一秒种为止所执行的所有事务吗？

为了使数据损失降低到最小程度，需要有一个恢复策略，确保它起作用，并经常实行这一策略。

您应该考虑的一些恢复方案包括：

∙系统故障。

电源故障、硬件故障或软件故障都能够使数据库处于不一致状态。

∙事务故障。

用户无意中会用错误数据修改数据库，从而毁坏数据库。

∙介质故障。

如果磁盘驱动器变得不能使用，那么可能会丢失所有或部分数据。

∙灾难。

系统所在的设施可能会遭受火灾、洪水或其它类似灾难的损坏。

恢复策略

为了规划恢复策略，您应该问自己一些问题：

∙可以再次从另一个来源装入数据吗？

∙您能承受丢失多少数据？

∙您能花多少时间来恢复数据库？

∙哪些存储资源可用于存储备份和日志文件？

事务

工作单元（unitofwork，UOW），也称作事务，由一个或多个以COMMIT或ROLLBACK语句结尾的SQL语句组成。

该UOW中的所有语句都被作为一个单元处理，这确保了数据一致性。

用于说明这个概念的典型示例是：

客户尝试将100美元从储蓄存款帐户转移到活期存款帐户。

这种情况的UOW类似于：

DELETE100dollarsfromSAVINGSaccount

INSERT100dollarstoCHECKINGaccount

COMMIT

如果没有将这些语句作为一个单元处理，那么您可以想象一下，如果在DELETE之后但又在INSERT语句之前发生硬件故障，会发生什么情况：

该客户将丢失100美元！

然而，由于这些语句被作为一个单元处理，所以这种情况决不会发生：

DB2将知道该单元没有完成（COMMIT），因而它将ROLLBACK先前语句所做的所有更改，并将受影响的行返回到事务开始之前所拥有的状态。

注：

没有用于标识事务开始的语句。

COMMIT或ROLLBACK之后的语句将开始新事务。

恢复类型

让我们熟悉一下恢复类型的概念。

DB2考虑到了下列恢复类型：

∙崩溃恢复。

这种类型的恢复通过撤销（回滚）未提交的事务来防止数据库处于不一致状态。

请再次考虑上一页中的示例。

如果在COMMIT语句之前发生电源故障，那么下一次DB2重新启动，再访问该数据库时，DB2将先回滚（ROLLBACK）INSERT语句，然后回滚（ROLLBACK）DELETE语句。

（注：

回滚语句的顺序与最初执行时的顺序相反。

）

∙版本恢复。

这种类型的恢复通过使用从BACKUP命令获取的备份映像来恢复先前的数据库版本。

恢复的数据库将包含在执行BACKUP命令时所处状态的信息。

如果在执行备份之后针对数据库执行进一步操作，那么该信息将丢失。

∙前滚恢复。

这种类型的恢复通过使用完全数据库备份，结合日志文件来扩展版本恢复。

必须先恢复备份以用作基线；然后在该备份之上应用日志。

该过程会将数据库或表空间恢复到某个特定时间点。

前滚恢复要求启用归档日志记录。

我们将在本教程的稍后部分中讨论归档日志记录（请参阅日志记录类型）。

3.0DB2日志

理解DB2日志

DB2事务日志对于恢复来说极其重要。

它们记录对数据库对象和数据所做的更改。

可以将日志存储在文件或裸设备中；对于以下示例，我们将使用文件。

为了确保数据完整性，DB2使用先写日志记录方案，在该模式中，它在将更改写入同样位于磁盘上的数据库（此过程也称为外部化）之前先写入日志。

下图说明了这一方案：

在该图中，执行了四条SQL语句。

这些语句已经被高速缓存在包高速缓存中，而且已经将这些语句需要的数据页从数据库检索到缓冲池中。

执行SQL语句时，先将更改记录在日志缓冲区中，然后将更改写入日志文件中。

在该示例中，还未将新版本的数据页外部化到数据库；这通常在需要缓冲池空间时执行，或因性能方面的原因而异步执行。

主日志文件和辅助日志文件

主日志文件是在首次数据库连接时或数据库激活时直接分配的。

辅助日志文件需要时每次动态地分配一个。

有几个与日志记录相关的数据库配置参数。

其中一些参数是：

∙LOGPRIMARY：

该参数确定要分配的主日志文件数。

∙LOGSECOND：

该参数确定可分配的辅助日志文件的最大数目。

∙LOGFILSIZ：

该参数用于指定日志文件的大小（用4KB页为单位）。

让我们考虑一个示例。

假设数据库配置文件中有下列值：

Logfilesize（4KB）（LOGFILSIZ）=250

Numberofprimarylogfiles（LOGPRIMARY）=3

Numberofsecondarylogfiles（LOGSECOND）=2

Pathtologfiles=C:

\mylogs\

一旦首次建立与数据库的连接，就分配三个主日志文件，它们均由250个4KB页组成。

如果查看C:

\mylogs目录，会看到三个文件：

DirectoryofC:

\MYLOGS\

2003-03-1006:

06p1,032,192S0000000.LOG

2003-03-1006:

06p1,032,192S0000001.LOG

2003-03-1006:

06p1,032,192S0000002.LOG

3File（s）3,096,576bytes

现在，假定数据库中没有活动，您决定执行以下事务，该事务将插入一百万条记录：

INSERTINTOTABLE1VALUES

（1）;

INSERTINTOTABLE1VALUES

（2）;

...

INSERTINTOTABLE1VALUES（1,000,000）;

COMMIT;

早先，我们提到过对数据库所做的更改被记录在日志中。

在没有增加设法精确地计算每条插入占用多少空间这一复杂性的情况下，您应该明白我们正在设法说明什么：

DB2将填满第一个日志，然后继续填满第二个和第三个日志。

填满第三个日志文件后，没有更多的主（预分配的）日志文件，因此DB2将动态地分配第一个辅助日志文件，因为LOGSECOND大于零。

一旦这个日志文件被填满，DB2将继续分配另一个辅助日志文件，并将重复该过程，直到达到LOGSECOND日志文件数目的最大值为止。

对于该示例，当DB2尝试分配第三个辅助日志文件时，它将返回一个错误，指出已经达到事务满条件。

此时，将回滚该事务。

无限日志记录

难道不就能通过增大LOGSECOND来避免日志空间用尽吗？

辅助日志文件的最大数目为254。

然而，您不会去指定一个较大的数，因为会产生与文件分配相关联的性能代价。

一般情况下，您希望指定足够多的LOGSECOND日志文件来应付负载中的峰值（如月末较为繁重的事务负载）。

在下一次激活数据库（或所有连接断开之后的首次连接）之前，不会除去辅助日志文件。

要允许无限的活动日志记录：

1.将USEREXIT数据库配置参数设置为ON。

2.将LOGSECOND设置为值-1。

请注意上面术语“活动（active）”的用法。

我们将在下一页讨论活动日志和归档日志的概念

日志类型

在这一页中，我们将简要地定义不同类型的日志。

在下一页中，您将了解在描述循环和归档日志记录时如何使用它们。

有三种类型或状态的DB2事务日志：

∙活动日志。

如果满足下面两个条件中的任何一个，则认为该日志是活动的：

o它包含有关还未提交或回滚的事务的信息。

o它包含有关已经提交但其更改还未被写入数据库磁盘（外部化）的事务的信息。

∙联机归档日志。

这种类型的日志包含已提交的且已外部化的事务的信息。

这种日志被保存在与活动日志相同的目录中。

∙脱机归档日志。

是指已经从活动日志目录移动到另一个目录或介质的归档日志。

可以手工或使用用户出口（userexit）的自动过程来完成这个移动。

日志记录类型

有两种类型的日志记录：

循环日志记录。

循环日志记录是DB2的缺省日志记录方式。

从其名称可以知道，这种类型的日志记录以循环方式重用日志。

例如，如果有四个主日志文件，那么DB2将以如下顺序使用它们：

Log#1，Log#2，Log#3，Log#4，Log#1，Log#2等。

只要日志仅包含有关已经提交的且被外部化到数据库磁盘的事务的信息，就可以用循环日志记录方式重用它。

换言之，如果日志仍是一个活动日志，则不能重用它。

采用上面的示例，如果一个长期运行的事务使用五个日志，那么将发生什么情况呢？

在这种情况下，DB2将分配另一个日志文件—辅助日志文件，如上一章中所描述的那样（请参阅主日志文件和辅助日志文件）。

下图说明了它是如何工作的：

归档日志记录。

同样，可以从其名称知道，当使用归档日志记录时，将归档（保留）日志。

在循环日志记录中，要覆盖已提交且已外部化的事务，而在归档日志记录中，将保存它们。

例如，如果有四个主日志，DB2可能以如下顺序使用它们：

Log#1，Log#2，Log#3，Log#4，（如果Log#1的所有事务都已被提交且外部化，则将其归档），Log#5，（如果Log#2的所有事务都已被提交且外部化，则将其归档），Log#6等。

正如您从上面的示例所看到的那样，DB2将使四个主日志文件保持可用，并且将不重用那些已经用某些事务填满的日志文件，这些事务已经被提交且外部化。

换言之，它不会覆盖已变成归档日志的日志。

下图说明了它是如何工作的：

上图不需要加以解释，它应该能够总结我们到目前为止所讨论的几个概念。

注：

在使用归档日志记录之前，需要启用它。

要启用它，必须同时打开下列参数或打开其中的任意一个：

LOGRETAIN（db2updatedbcfgfordatabase_nameusingLOGRETAINON）

USEREXIT（db2updatedbcfgfordatabase_nameusingUSEREXITON）

其它恢复主题

日志记录类型vs.恢复类型

既然您了解了不同类型的日志记录和恢复，您就会认识到：

并不是所有的日志记录类型都支持所有的恢复类型。

循环日志记录仅支持崩溃和版本恢复，而归档日志记录支持所有类型的恢复：

崩溃恢复、版本恢复和前滚恢复。

可恢复的数据库vs.不可恢复的数据库

可恢复的数据库是可以通过使用崩溃恢复、版本恢复或前滚恢复来进行恢复的数据库；因而，需要为这些数据库启用归档日志记录。

不可恢复的数据库是那些不支持前滚恢复的数据库；因而，只使用循环日志记录。

用户出口

我们在前几章中多次提到用户出口。

用户出口是允许将联机归档日志移到另一个目录（非活动日志目录）或另一个介质的程序。

当为完全数据库恢复进行ROLLFORWARD操作期间需要脱机归档日志时，用户出口还会将它们检索到活动日志目录中。

要启用用户出口，将USEREXIT数据库配置参数设置为ON。

一旦启用，DB2将根据需要自动调用用户出口程序。

需要将该程序命名为db2uext2，在Windows中，应该将它存储在sqllib\bin目录中，在UNIX中，应该将它存储在sqllib/bin目录中。

复习

到目前为止，我们已经讨论了几个有关数据库日志和日志记录的概念。

下图总结了其中的一些概念：

上图显示了几个运行了一段时间的事务。

一些事务并发地运行；它们先开始填充日志缓冲区，随后被写入磁盘上的日志文件中。

当日志缓冲区满或者发出MINCOMMIT次提交命令时，日志缓冲区中的内容将被写入日志文件中。

（MINCOMMIT是一个数据库配置文件参数。

）对已提交的事务的数据页所做的更改将被外部化（从缓冲池异步地写入数据库磁盘）。

为了简单起见，在图中我们显示这是在提交时发生的，但通常不是这样的。

请注意，带活动标签的六角形。

这表示日志文件X仍被视为活动日志的时间量。

正如您看到的那样，该六角形在两个正方形的上方，这两个正方形在日志文件Y中分别代表事务D和C的一部分。

为什么甚至在日志文件X填满之后还被认为是活动的呢？

这是因为它包含还未提交和外部化的事务。

正如您看到的那样，日志文件X包含事务A、B和C。

只提交了事务A和B（在该示例中，立即被外部化）；事务C仍在运行，同时还向日志文件Y中写入。

当在日志文件Y中提交事务C（在该示例中，立即被外部化）时，不再将日志文件X视为活动日志，但它将变成联机归档日志。

4.0数据库和表空间备份

联机访问vs.脱机访问

在接下来的几页中，我们将经常使用术语联机和脱机。

如果我们正在执行联机操作（备份、恢复和前滚），则允许其他用户同时访问我们正在使用的数据库对象。

如果我们正在执行脱机操作，则不允许其他用户同时访问我们正在使用的数据库对象。

数据库备份

数据库备份是数据库的完整副本。

除了数据外，备份副本还会包含有关表空间、容器、数据库配置、日志控制文件以及恢复历史记录文件的信息。

注：

备份将不存储数据库管理器配置文件或注册表变量。

只备份数据库配置文件。

要执行备份，需要SYSADM、SYSCTRL或SYSMAINT权限。

下面是用于这种备份的BACKUP命令实用程序的语法：

BACKUPDATABASEdatabase-alias[USERusername[USINGpassword]]

[TABLESPACE（tblspace-name[{,tblspace-name}...]）][ONLINE]

[INCREMENTAL[DELTA]][USE{TSM|XBSA}[OPENnum-sessSESSIONS]]|

TOdir/dev[{,dir/dev}...]|LOADlib-name[OPENnum-sessSESSIONS]]

[WITHnum-buffBUFFERS][BUFFERbuffer-size][PARALLELISMn]

[WITHOUTPROMPTING]

让我们来看一些示例，以了解其中一些选项是如何工作的。

要执行数据库“sample”的完全脱机备份并将备份副本存储到目录d:

\mybackups，请使用以下命令：

BACKUPDATABASEsample

TOd:

\mybackups

要使用其它备份选项来执行数据库“sample”的完全脱机备份，可以使用以下命令：

（1）BACKUPDATABASEsample

（2）TO/db2backup/dir1,/db2backup/dir2

（3）WITH4BUFFERS

（4）BUFFER4096

（5）PARALLELISM2

让我们更仔细地研究该命令：

1.指明要备份的数据库的名称（或别名）。

2.指定用来存储备份的一个或多个位置。

3.确定在备份操作期间可以使用内存中的多少缓冲区。

使用多个缓冲区可以改善性能。

4.确定每个缓冲区的大小。

5.确定使用多少个介质阅读器／记录器进程／线程来执行备份。

注：

语法中没有关键字OFFLINE，因为这是缺省方式。

要执行sample数据库的完全联机备份，必须指定关键字ONLINE，如下所示：

BACKUPDATABASEsample

ONLINE

TO/dev/rdir1,/dev/rdir2

我们先前提到过：

联机备份允许其他用户在备份数据库时对它进行访问。

这些用户所做的一些更改很可能在备份时没有存储在备份副本中。

因此，恢复时需要联机备份和一组完整的归档日志。

此外，联机备份一完成，DB2就强制当前的活动日志关闭；结果，将归档该日志。

注：

联机备份要求为数据库启用归档日志记录。

表空间备份

在只有一些表空间有相当大更改的数据库中，可以选择不备份整个数据库，而只备份特定表空间。

要执行表空间备份，请使用以下语法：

（1）BACKUPDATABASEsample

（2）TABLESPACE（syscatspace,userspace1,userspace2）

（3）ONLINE

（4）TO/db2tbsp/backup1,/db2tbsp/backup2

上面示例中的第2行指出这是一个表空间备份，而不是完全数据库备份。

您也可以从该示例中看出：

想在备份中包括多少表空间，就可以包括多少。

不能使用表空间级备份来备份临时表空间。

通常，您想要将相关的表空间备份在一起。

例如，假设您正在使用DMS表空间，其中，一个表空间用于表数据，另一个用于索引，还有一个用于LOB。

您应该同时备份所有这些表空间，以使信息保持一致。

这同样也适用于包含定义了表间引用约束的表的表空间。

增量备份

有两种类型的增量备份：

∙增量：

DB2备份自上次完全数据库备份以来所更改的所有数据。

∙delta：

DB2将只备份自上一次成功的完全、增量或差异备份以来所更改的数据。

下图说明了这些类型之间的差异：

在该图的上半部分中，如果星期五进行增量备份之后发生崩溃，那么可以先恢复第一个星期日的完全备份，然后恢复星期五进行的增量备份。

在该图的下半部分中，如果星期五进行delta备份之后发生崩溃，那么可以先恢复第一个星期日的完全备份，然后恢复从星期一到星期五（包括星期五）所进行的每次delta备份。

使用控制中心（ControlCenter）执行备份

下图演示了如何从控制中心调用BACKUP实用程序。

要执行数据库或表空间备份，请用鼠标右键单击您想要备份的数据库。

下图显示了执行BACKUP实用程序所需填写的选项。

我们跳过了一些中间屏幕，在这些屏幕上，您可以选择要备份表空间还是数据库。

我们鼓励您亲自尝试一下。

备份文件

磁盘上的DB2备份文件的命名约定包含下列几项：

∙数据库别名

∙表示备份类型的数字（0表示完全数据库备份，3表示表空间备份，4表示来自LOAD的副本）

∙实例名

∙数据库节点（对于单一分区数据库始终是NODE0000）

∙目录节点号（对于单一分区数据库始终是CATN0000）

∙备份的时间戳记

∙映像序列号

确切的命名约定随平台的不同而略有不同，如下图所示：

5.0数据库和表空间恢复

数据库恢复

在本章中，我们将讨论RESTORE实用程序，该实用程序将备份文件用作输入，而将新的或现有数据库作为输出。

请注意，尽管我们讨论的是数据库恢复（recovery），但我们将使用的实用程序名为RESTORE，而不是RECOVER。

要恢复到现有数据库，需要SYSADM、SYSCTRL或SYSMAINT权限。

要恢复到新数据库，需要SYSADM或SYSCTRL权限。

下面是RESTORE命令的语法：

RESTOREDATABASEsource-database-alias{restore-options|CONTINUE|ABORT}

restore-options:

[USERusername[USINGpassword]][{TABLESPACE[ONLINE]|

TABLESPACE（tblspace-name[{,tblspace-name}...]）[ONLINE]|

HISTORYFILE[ONLINE]}][INCREMENTAL[AUTOMATIC|ABORT]]

[{USE{TSM|XBSA}[OPENnum-sessSESSIONS]|

FROMdir/dev[{,dir/dev}...]|LOADshared-lib

[OPENnum-sessSESSIONS]}][TAKENATdate-time][TOtarget-directory]

[INTOtarget-database-alias][NEWLOGPAT