作者在实践基于TSM的DB2备份的时候发现，已有的资料不是侧重于介绍TSM就是侧重于介绍DB2备份方法，而介绍基于TSM的DB2备份、恢复方法以及DB2的跨节点恢复方法的资料分散于各处，由于没有比较系统的资料以及介绍最佳实践操作方法的文章，作者在实践过程中十分不便，因此萌发了写一个全面系统介绍这方面内容的文章的想法。本文通过具体案例详细介绍了使用TSM进行DB2备份和恢复的方法，同时也介绍了如何跨节点进行DB2数据库恢复的步骤。读者可以通过这个案例了解到DB2如何结合TSM API实现便捷的数据库备份和恢复所需要的所有配置步骤和操作步骤，也可以了解到如何将一个数据库恢复到与原始服务器不同的服务器中去。在本文中，读者可以了解到基本的原理，也可以按照文章介绍的步骤，跟随作者一步一步地去实现基于TSM的DB2备份、恢复，以及跨节点恢复。

IBM DB2是广泛应用的关系型数据库管理系统产品，其上包含了关键数据。IBM DB2结合IBM Tivoli Storage Manager(本文后称TSM)可以实现便捷地数据备份和恢复，以保护这些关键数据。

作者在协助一家IT公司管理其IDC的过程中，遇到需要定期备份指定的生产DB2数据的需求，而且这些备份的数据需要被定期恢复到其它DB2服务器中以用于检查备份的有效性，同时，这些备份的生产数据要求在每天晚上被恢复到用于开发测试的DB2服务器中以用于使开发测试环境尽量保持于实际生产环境的数据一致。

目前，这套机制已经运行2年，5个生产数据库每周末进行在线全量备份，每日深夜进行增量备份;部分生产数据库在每天晚上在备份结束后跨节点恢复到开发测试用的DB2服务器中;其它生产数据库每月进行一次跨节点的恢复演练，将备份的数据恢复到在台用于检查备份数据有效性的DB2服务器中(后称“恢复演练DB2服务器”)。

由于有良好的备份机制以及备份数据有效性验证的机制，在一次生产事故中，一台生产DB2服务器的磁盘逻辑分区损坏，导致1个生产数据库的数据遭受永久的损坏。通过从TSM中成功恢复数据，结合从TSM中进行事务日志的恢复操作，只丢失事故前几分钟的数据，从而保障了该IT公司的重要数字资产。

作者在当初实施这个项目时发现，虽然有海量的参考资料，包括IBM的红皮书，以及其它用户的使用经验。但是，已有的资料不是侧重于介绍TSM就是侧重于介绍DB2备份方法，而介绍基于TSM的DB2备份、恢复方法以及DB2的跨节点恢复方法的资料分散于各处，由于没有比较全面的资料以及实际的最佳实践操作方法，作者在实践过程中十分不便。在整个项目实施运行并且证实有效之后，萌发了写一个全面介绍这方面内容的文章的想法。希望可以在文中，可以全面介绍相关的原理，读者也可以按照文章介绍的步骤，跟随作者一步一步地去实现基于TSM的DB2备份、恢复，以及跨节点恢复，而不需要每做一步都需要到浩瀚的资料大洋中搜索相关的内容。

本文通过具体案例，详细地介绍数据备份、备份计划以及数据恢复的步骤和方法。同时，本文也介绍了将一个数据库恢复到其它数据库服务器中去的步骤和方法。

一、原理简介

使用TSM进行数据备份有多种方式，本文介绍的是让DB2调用TSM API所提供的函数直接将数据库和表空间备份发送到TSM服务器的方式，这种方式经过2年的运行以来，证实是便捷和可靠的。图1表示了这种方法的架构。

▲图1

 

二、实验环境介绍

本案例以实际生产环境为例，包含了TSM系统(服务器、存储和带库)、DB2服务器 和恢复演练用的DB2服务器。

▲图2

 

图2说明了整个实验环境相关的设备之间的关系，生产DB2服务器和恢复演练DB2服务器都由IP网络与TSM Server连接;TSM Server与存储设备之间以SAN Fab-ric连接，为了说明的方便，不展开TSM多级存储的说明和讨论。我们将在后面的步骤操作中把一台DB2服务器上的数据备份到TSM系统中，随后再把数据从TSM系统中恢复到同一台DB2服务器上;在之后，我们再说明将数据从一台DB2服务器上备份到TSM系统之后再恢复到另一台DB2服务器上。

▲图3

 

图3说明了TSM系统内的NODE配置以及与2台DB2 Serv-er的实例和数据库之间的关系。在TSM系统上为生产DB2服务器创建了1个NODE，名为PRODDB2;为恢复演练DB2服务器创建了1个NODE，名为DRILLDB2， 这2个NODE都属于策略域DB2DOMAIN。在DB2DOMAIN策略域中，创建了一个名为DB2MGMTCLASS的管理类，在这个管理类中可以定义诸如备份版本数量、备份保持时长等等备份和归档策略，2个NODE都与该管理类关联。在生产DB2服务器上有实例db2inst1，在该实例内运行了一个数据库ZSHWL，在之后的步骤中，我们将在生产DB2服务器上安装TSM Client API，并且在这个API上配置登录到TSM系统的PRODDB2节点中。相类似的，恢复演练DB2服务器上的TSM Client API将登录到TSM系统的DRILLDB2节点中。

▲图4

 

三、TSM Client API安装和配置

要采用图1的架构进行数据库备份或者恢复都需要在DB2服务器上安装TSM Client API。首先要在DB2实例用户下运行db2level来确定DB2是32位的还是64位的，如下粗体部分显示本案例中的生产DB2服务器安装的是64位版本的DB2服务器：

[db2inst1@prod-db2-1 ~]$ db2level
DB21085I This instance or install (instance name, where applicable:
"db2inst1") uses "64" bits and DB2 code release "SQL09079" with level identifier "080A0107".
Informational tokens are "DB2 v9.7.0.9", "s131204", "IP23561", and Fix Pack "9".
Product is installed at "/opt/ibm/db2/V9.7".

到官网网址：http://www-01.ibm.com/support/docview.wss?uid=swg21239415去下载相应的软件，解包后依次运行下述命令行即可完成TSM Client API的安装：

rpm -Uhv gskcrypt64-8.0.14.14.linux.x86_64.rpm gskssl64-8.0.14.14.linux.x86_64.rpm
rpm -ihv TIVsm-API64.x86_64.rpm
rpm -ihv TIVsm-APIcit.x86_64.rpm

安装完成后，需要配置TSM Client API。首先要在dsm.sys中配置TSM Server和Nodename。

在生产DB2服务器上配置如下：

[db2inst1@prod-db2-1 ~]$ cat /opt/tivoli/tsm/client/api/bin64/dsm.sys
SErvername WIN-05T3KU001S9
　 COMMMethod TCPip
　 TCPPort 1500
　 TCPServeraddress 10.3.3.1
　 nodename PRODDB2
　 passwordaccess generate

在恢复演练DB2服务器上配置如下：

[db2inst1@db2tsmdrill ~]$ cat /opt/tivoli/tsm/client/api/bin64/dsm.sys
SErvername WIN-05T3KU001S9
　 COMMMethod TCPip
　 TCPPort 1500
　 TCPServeraddress 10.3.3.1
　 nodename DRILLDB2
　 passwordaccess generate

然后，在生产DB2服务器和恢复演练DB2服务器中的dsm.opt中启用TSM Server配置：

cat /opt/tivoli/tsm/client/api/bin64/dsm.opt
SErvername WIN-05T3KU001S9

在完成以上配置后，为TSM Client API设置TSM NODE的帐号密码，用root权限在其中一个实例用户的sqllib/adsm目录内执行dsmapipw命令，以下是示例：

[root@@prod-db2-1 ~]# cd /home/db2inst1/sqllib/adsm
[root@@prod-db2-1 adsm]# ./dsmapipw
*************************************************************
* Tivoli Storage Manager *
* API Version = 6.3.2 *
*************************************************************
Enter your current password:
Enter your new password:
Enter your new password again:
Your new password has been accepted and updated.

以上配置在每个DB2服务器上做1次就可以，做完以上操作之后，需要为每个DB2实例进行与TSM Client API相关的环境变量的配置，在每个需要进行备份和恢复操作的DB2实例上都要做一次。

以下是生产DB2服务器上db2inst1实例的配置示例：

[db2inst1@prod-db2-1 ~]$ cat sqllib/userprofile
export DSMI_CONFIG=/opt/tivoli/tsm/client/api/bin64/dsm.opt
export DSMI_LOG=/db2home/db2inst1
export DSMI_DIR=/opt/tivoli/tsm/client/api/bin64

修改了userprofile之后，需要重新登录实例用户，这些环境变量才能生效。在这些环境变量生效时，重新启动DB2实例才可以使用TSM Client API进行数据库备份和恢复。

注意：在生产环境进行数据库TSM备份变更时，有3个地方要重启DB2实例：

1.安装TSM Client API需要在 DSMI_CONFIG、 DSMI_LOG、 DSMI_DIR这3个环境变量配置正确时重启DB2实例。

2.为在线备份修改LOGARCHMETH1参数后，要重启数据库实例。

3.为增量备份修改TRACKMOD参数后，要重启数据库实例。

建议完成以上3处变更后一并重启数据库实例，可以减少停机时间。

[page]

七、跨节点进行数据库恢复

实际应用中，经常会有跨节点进行数据库恢复的需求。比如，验证生产数据库备份的正确性，或者，要将生产数据库恢复到预生产或者测试的数据库服务器中以供测试和开发使用。使用TSM Client API可以非常方便地实现这种跨节点的恢复。

在进行跨节点数据库恢复时，要注意目标节点的DB2与源节点的DB2的版本要一致。可以使用db2level来查看详细的版本信息。

以下将以把数据库ZSHWL从生产DB2服务器的db2inst4实例恢复到恢复演练DB2服务器的db2inst1实例中为例，说明如何实现数据库的跨节点和跨实例名恢复。

要实现跨节点数据库恢复，首先要在源节点实例用户上对目标节点的实例用户进行TSM备份访问授权。本示例中需要将在生产DB2服务器的db2inst4实例中的ZSHWL数据库的备份访问权授权给恢复演练DB2服务器(TSM NODE: DRILLDB2)上的db2inst1实例用户。

登录源节点上的实例用户，即生产DB2服务器的db2inst4用户，输入以下命令：

[db2inst4@prod-db2-1 ~]$ db2adutl grant user db2inst1 on nodename DRILLDB2 for db ZSHWL
Successfully added permissions for db2inst1 to access ZSHWL on node DRILLDB2.

在源节点实例中，可以查询已经对哪些数据库向哪些节点进行了授权：

[db2inst4@prod-db2-1 ~]$ db2adutl queryaccess
Node Username Database Name Type
--------------------------------------------------------------
STAGDB2 db2inst4 KBMASTER A
TSMTESTDB2 db2inst4 KBMASTER A
DRILLDB2 db2inst1 ZSHWL A
STAGDB2 db2inst4 ZSHWL A
--------------------------------------------------------------
Access Types: B - backup images L - logs A - both

此时，在目标节点用实例用户，即恢复演练DB2服务器的db2inst1用户中，已经可以查询到源节点中的ZSHWL的备份信息了。登录到目标节点的db2inst1用户中，输入如下命令：

[db2inst1@db2tsmdrill ~]$ db2adutl query db ZSHWL nodename PRODDB2 owner db2inst4
Query for database ZSHWL
Retrieving FULL DATABASE BACKUP information.
　　1 Time: 20150529231133 Oldest log: S0000278.LOG DB Partition Number: 0 Sessions: 2
　　2 Time: 20150522231134 Oldest log: S0000270.LOG DB Partition Number: 0 Sessions: 2
Retrieving INCREMENTAL DATABASE BACKUP information.
　　1 Time: 20150605001133 Oldest log: S0000286.LOG DB Partition Number: 0 Sessions: 2
　　2 Time: 20150604001132 Oldest log: S0000285.LOG DB Partition Number: 0 Sessions: 2
　　3 Time: 20150603001133 Oldest log: S0000283.LOG DB Partition Number: 0 Sessions: 2
　　4 Time: 20150602001143 Oldest log: S0000281.LOG DB Partition Number: 0 Sessions: 2
　　5 Time: 20150531001135 Oldest log: S0000280.LOG DB Partition Number: 0 Sessions: 2
　　6 Time: 20150530001132 Oldest log: S0000279.LOG DB Partition Number: 0 Sessions: 2
Retrieving DELTA DATABASE BACKUP information.
　No DELTA DATABASE BACKUP images found for ZSHWL
Retrieving TABLESPACE BACKUP information.
　No TABLESPACE BACKUP images found for ZSHWL
Retrieving INCREMENTAL TABLESPACE BACKUP information.
　No INCREMENTAL TABLESPACE BACKUP images found for ZSHWL
Retrieving DELTA TABLESPACE BACKUP information.
　No DELTA TABLESPACE BACKUP images found for ZSHWL
Retrieving LOAD COPY information.
　No LOAD COPY images found for ZSHWL
Retrieving LOG ARCHIVE information.
　 Log file: S0000120.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2015-01-30-23.22.27
　 Log file: S0000121.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2015-01-31-00.22.18
……

如果源节点没有对目标节点进行授权，在目标节点上是无法查询到源节点的备份信息的。

下面，我们来在恢复演练DB2服务器上恢复源节点上(生产DB2服务器上)时间标签为20150605001133的ZSHWL数据库备份。

由于20150605001133是一个增量备份，所以我们使用incremental automat-ic选项来实现自动的增量恢复;由于要将数据库恢复到与源数据库不同的目录，所以使用了redirect选项;由于是在线备份，所以我们使用logtarget将在线备份的同时备份到TSM的事务日志取到~/logretrieve目录中。本例中，我们将数据库恢复到目标服务器的实例home目录，即/home/db2inst1;同时将事务日志取回到/home/db2inst1/logretrieve目录：

[db2inst1@db2tsmdrill ~]$ mkdir logretrieve
[db2inst1@db2tsmdrill ~]$ db2 restore db ZSHWL incremental automatic use tsm options "'-fromnode=PRODDB2 -fromowner=db2inst4'" taken at 20150605001133 ON ~/ logtarget ~/logretrieve redirect
SQL1277W A redirected restore operation is being performed. Table space
configuration can now be viewed and table spaces that do not use automatic
storage can have their containers reconfigured.
DB20000I The RESTORE DATABASE command completed successfully.

由于使用了redirect选项，所以恢复中途会停顿以便用户配置Table space，本例中，我们不需要对Table space进行配置，可以直接使用continue选项继续恢复：

[db2inst1@db2tsmdrill ~]$ db2 restore db ZSHWL continue
DB20000I The RESTORE DATABASE command completed successfully.

当以上恢复操作完成之后，由我们恢复的是在线备份的数据库，所以还需要进行事务日志的前滚操作才可以正常连接数据库，不然，连接数据库时会出现SQL1117N错误。

[db2inst1@db2tsmdrill ~]$ db2 connect to ZSHWL
SQL1117N A connection to or activation of database "ZSHWL" cannot be made
because of ROLL-FORWARD PENDING. SQLSTATE=57019

在~/logretrieve目录可以查看到与在线备份的同时写入TSM的事务日志：S0000286.LOG。由于源数据库的LOGARCH-METH1被配置为TSM，所以它的事务日志已经都归档在TSM中，所以我们可以通过TSM来取回其它需要的事务日志。

我们可以查看当前数据库前滚的状态：

[db2inst1@db2tsmdrill logretrieve]$ db2 rollforward db ZSHWL query status
　　　　　　　　　　　　　　　　 Rollforward Status
Input database alias = ZSHWL
Number of nodes have returned status = 1
Node number = 0
Rollforward status = DB working
Next log file to be read = S0000286.LOG
Log files processed = -
Last committed transaction = 2015-06-04-16.11.39.000000 UTC

从以上输出可以看到，目前数据库处于Rollforward status的DB work-ing状态，需要前滚，否则不能连接;下一个要处理的事务日志是S0000286.LOG，最后的事务在UTC时间6月4日16时11分39秒提交。

我们先查看一下需要从TSM取回哪些事务日志，在目标服务器上的数据库实例用户中执行db2adutl查询源数据库归档的事务日志：

[db2inst1@db2tsmdrill ~]$ db2adutl query logs db ZSHWL nodename PRODDB2 owner db2inst4
Query for database ZSHWL
Retrieving LOG ARCHIVE information.
　 Log file: S0000120.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2015-01-30-23.22.27
……
　 Log file: S0000292.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2015-06-10-00.21.20

我们需要从TSM取回源数据库归档的从S0000287.LOG开始到最后1个S0000292.LOG的所有事务日志，存放到目标节点上：

[db2inst1@db2tsmdrill ~]$ cd logretrieve
[db2inst1@db2tsmdrill logretrieve]$ db2adutl extract logs between S0000287.LOG and S0000292.LOG db ZSHWL nodename PRODDB2 owner db2inst4 without prompting
Query for database ZSHWL
Retrieving LOG ARCHIVE information.
　 LOG ARCHIVE image:
　　　Log file: S0000287.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2015-06-05-23.21.27
　　　　 Writing to file:
　　　　　　./NODE0000/ZSHWL/C0000000/S0000287.LOG
……
　 LOG ARCHIVE image:
　　　Log file: S0000292.LOG, Chain Num: 0, DB Partition Number: 0, Taken at: 2015-06-10-00.21.20
　　　　 Writing to file:
　　　　　　./NODE0000/ZSHWL/C0000000/S0000292.LOG

我们需要的事务日志都已经取回到./logretrieve/NODE0000/ZSHWL/C0000000目录之内了。

[db2inst1@db2tsmdrill ~]$ ls logretrieve/NODE0000/ZSHWL/C0000000/
S0000287.LOG S0000288.LOG S0000289.LOG S0000290.LOG S0000291.LOG S0000292.LOG

现在我们开始为ZSHWL数据库前滚日志。将所有日志文件都移动到~/logretrieve目录中：

[db2inst1@db2tsmdrill logretrieve]$ cd NODE0000/ZSHWL/C0000000/
[db2inst1@db2tsmdrill C0000000]$ mv * ~/logretrieve

使用下面的命令行来执行事务日志前滚：

[db2inst1@db2tsmdrill ~]$ db2 "rollforward db ZSHWL to end of logs overflow log path ('/home/db2inst1/logretrieve')"
　　　　　　　　　　　　　　　　 Rollforward Status
Input database alias = ZSHWL
Number of nodes have returned status = 1
Node number = 0
Rollforward status = DB working
Next log file to be read = S0000292.LOG
Log files processed = S0000286.LOG - S0000292.LOG
Last committed transaction = 2015-06-09-16.11.38.000000 UTC
DB20000I The ROLLFORWARD command completed successfully.

我们看到，所有事务日志都已经被处理完成，最后提交的事务时间是UTC时间6月9日16点11分38秒(在前滚之前，最后的事务在UTC时间6月4日16时11分39秒提交)，从S0000286.LOG到S0000292.LOG的事务日志都已经被处理。

至此，跨节点恢复数据库已经完成。我们还需要做最后一个操作以使目标数据库可以被连接：

[db2inst1@db2tsmdrill ~]$ db2 rollforward db ZSHWL complete
　　　　　　　　　　　　　　　　 Rollforward Status
Input database alias = ZSHWL
Number of nodes have returned status = 1
Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000286.LOG - S0000292.LOG
Last committed transaction = 2015-06-09-16.11.38.000000 UTC
DB20000I The ROLLFORWARD command completed successfully.

现在我们可以正常地连接到目标ZSHWL数据库了：

[db2inst1@db2tsmdrill ~]$ db2 connect to ZSHWL
　 Database Connection Information
Database server = DB2/LINUXX8664 9.7.9
SQL authorization ID = DB2INST1
Local database alias = ZSHWL

八、小结

从本文所举的案例来看，DB2和TSM是在设计上高度融合，集成度很高。采用TSM来保护DB2的数据功能齐全、操作简便。

TSM Client API和DB2结合能够高度自动化地帮助管理员完成各项工作任务。从上面步骤中可以看出，日常的备份和恢复操作实际上是使用DBA所熟悉的DB2命令行来实施的，使用不同的参数就可以执行备份到本地磁盘或者备份到TSM系统中，在这个过程中TSM管理员可以不介入，从而达到管理角色分离的目的，这得益于DB2与TSM的天然的集成。

在实施过程中需要特别注意的是有几处变更是需要重启数据库实例的，比如安装TSM Client API后、修改LOGARCHMETH1和TRACKMOD参数后，都需要重启数据库实例。在生产环境中实施时，需要事先申请停机时间。另外，在能够实施在线备份之前是需要做一次离线备份的，此时数据库不能向任何用户(应用)提供服务，这也需要在停机时间内完成。

采用TSM Client API来备份DB2数据时有一个地方会使人感到困惑。因为DB2有它自己的版本控制机制，同一个数据库的每个备份版本在TSM中都有一个唯一的命名。而正因为这种唯一的命名使TSM把每一个备份版本都认为是一个独立的备份对象，从而每个版本都当作一个ACTIVE的备份对象来看待。只有当使用 db2adutl de-lete命令来“删除”某个版本(备份对象)时，这个备份对象才会被TSM标记为INACTIVE，到达TSM策略域所设定的过期时间后这个对象才会被TSM过期。因此，对于DB2备份对象TSM中的相应策略域中版本数和保持策略需要一些特别的设定。具体可以参考链接： http://www-01.ibm.com/support/docview.wss?uid=swg21263834。

本文描述的场景适用于日常生产数据的备份恢复，也可用于建立一个生产数据库的“影子”数据库来用于开发测试，采用定时任务的方式，可以在每天凌晨更新“影子”数据库，以使开发测试环境尽量接近真实环境。

总之，使用TSM来保护DB2简单易实施，日常的备份和恢复工作非常轻松，还可以采用crontab或者TSM的schedule来实现自动的定时备份任务，是用于DB2备份的最佳选择。

作者简介：

▲方达宏