基于TSM的DB2备份和跨节点恢复

黑狼

    【IT168 技术】作者在实践基于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
nodename           DRILLDB2
然后，在生产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处变更后一并重启数据库实例，可以减少停机时间。
正在努力加载文档，请稍等…
四、数据库的备份
本节介绍使用TSM进行DB2的离线备份、在线备份、在线增量备份。
安装了TSM API并且正确配置之后，就可以进行离线备份了，本例在恢复演练DB2服务器上离线备份db2inst1中的ZSHWL数据库。
注意:由于离线备份需要断开应用的数据库连接，所以在生产环境除非申请停机时间否则不要尝试，本例是在恢复演练DB2服务器上做的。
以实例用户登录，要进行数据库的离线备份，需要确认没有应用或者用户连接到这个数据库。使用DB2 LIST APPLICATIONS命令来查看是不是有应用连接到数据库:
[db2inst1@db2tsmdrill ~]$ db2 list applications for db ZSHWL
Auth Id  Application   Appl.      Application Id                            DB       # of
Name          Handle                                               Name    Agents
-------- -------------- ---------- ---------------------------------------- -------- -----
DB2INST1 db2bp          17         *LOCAL.db2inst1.150616022445             ZSHWL    1
要进行离线备份，需要把所有连接到数据库的应用都断开。可以到应用一侧去登出数据库，也可以在数据库一侧使用db2 force application all命令，但是需要注意这个命令会把连接到当前实例下的所有数据库的所有应用都断开，一般可以使用指定Handle号的方式来断开特定数据库的连接，多个Handle号之间可以用逗号分开。本例中我们要断开Handle为17的连接:
[db2inst1@db2tsmdrill ~]$ db2 "force application (17)"
DB20000I  The FORCE APPLICATION command completed successfully.
DB21024I  This command is asynchronous and may not be effective immediately.
再确认一下数据库的连接，现在已经没有应用连接在ZSHWL数据库上了:
SQL1611W  No data was returned by Database System Monitor.
这时，使用带有USE TSM选项的BACKUP DB命令就可以备份这个数据库了:
[db2inst1@db2tsmdrill ~]$ db2 backup db ZSHWL use tsm
Backup successful. The timestamp for this backup image is : 20150616104649
数据库在线备份不需要断开应用连接，所以一般情况下是都是采用在线备份的方法。
显然，在数据库仍旧被连接使用的时候进行备份会引起一致性问题，因为，当数据库被备份的同时，数据也在被更新。DB2采用在恢复数据库的时候应用事务日志前滚操作来解决因为在线备份而导致的数据一致性问题，显然，要实现这个方法，就需要收集备份开始到备份结束之间的事务日志。在线备份结束的时候，当前的事务日志会被归档并且包含在备份映像内。在线备份会自动收集恢复数据库时需要用到的事务日志。
下面仍旧以恢复演练DB2服务器上db2inst1实例内的ZSHWL数据库为例，来进行在线备份。登录数据库实例用户，使用带有ONLINE和USE TSM选项的BACKUP DB命令:
[db2inst1@db2tsmdrill ~]$ db2 backup db ZSHWL online use tsm
SQL2413N  Online backup is not allowed because the database is not recoverable
or a backup pending condition is in effect.
此时，我们得到一个SQL2413N错误，原因就是DB2的事务日志在默认情况下是循环日志模式，这种模式下无法进行日志归档，因此就不能收集到备份期间的事务日志以用于恢复，所以就不能进行在线备份。可以通过GET DB CFG来查看到数据库的日志归档模式:
[db2inst1@db2tsmdrill ~]$ db2 get db cfg for ZSHWL | grep LOGARCHMETH1
First log archive method                 (LOGARCHMETH1) = OFF
LOGARCHMETH1 配置为OFF意味着当前数据库使用的是默认的循环日志模式，可以为LOGARCHMETH1指定DISK参数来将事务日志归档到本地路径，或者指定TSM参数来将事务日志归档到TSM中，不论归档到本地路径还是TSM，都可以进行在线备份。
本例中将事务日志归档到TSM中:
[db2inst1@db2tsmdrill ~]$ db2 update db cfg for ZSHWL using LOGARCHMETH1 tsm
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
注意:修改数据库的LOGARCHMETH1参数之后需要重启数据库才能生效。
修改LOGARCHMETH1并且重启之后，数据库会处于BACKUP PEND-ING状态而不能连接，需要进行一次离线备份才能解除这个状态:
[db2inst1@db2tsmdrill ~]$ db2 connect to zshwl
SQL1116N  A connection to or activation of database "ZSHWL" cannot be made
because of BACKUP PENDING.  SQLSTATE=57019
执行一次离线备份后，即可正常连接使用此数据库了:
[db2inst1@db2tsmdrill ~]$ db2 backup db ZSHWL use TSM
Backup successful. The timestamp for this backup image is : 20150616131903
Database Connection Information
Database server        = DB2/LINUXX8664 9.7.9
SQL authorization ID   = DB2INST1
Local database alias   = ZSHWL
现在我们再来尝试使用带有ONLINE和USE TSM选项的BACKUP DB命令来进行在线备份:
Backup successful. The timestamp for this backup image is : 20150616132313
可以看到在线备份成功了。
在做在线备份时，可以使用incremental选项来实施增量备份，为了能够实现增量备份，需要将数据库的TRACKMOD配置为yes，不然会得到以下错误:
[db2inst1@db2tsmdrill ~]$ db2 backup db ZSHWL online incremental use tsm
SQL2426N  The database has not been configured to allow the incremental backup
operation. Reason code = "1".
检查TRACKMOD的配置:
[db2inst1@db2tsmdrill ~]$ db2 get db cfg for ZSHWL | grep TRACKMOD
Track modified pages                         (TRACKMOD) = NO
我们看到TRACKMOD的配置是NO，需要修改TRACKMOD的配置:
[db2inst1@db2tsmdrill ~]$ db2 update db cfg for ZSHWL using TRACKMOD YES
注意:修改数据库的TRACKMOD配置后需要重启数据库才能生效。
在重启数据库之后，首先要进行一次在线全量备份，然后即可正常对此数据库进行在线增量备份了:
[db2inst1@db2tsmdrill ~]$ db2 restart db ZSHWL
DB20000I  The RESTART DATABASE command completed successfully.
Backup successful. The timestamp for this backup image is : 20150616134107
Backup successful. The timestamp for this backup image is : 20150616134147
五、数据库备份的查询和验证
对数据库进行了备份之后，我们需要查询有哪些数据库已经被备份在TSM上。同时，对这些备份进行有效性验证也是必要的。
我们可以使用带有BACKUP选项的LIST HISTORY命令来查询有哪些备份映像:
[db2inst1@db2tsmdrill ~]$ db2 list history backup all for ZSHWL
List History File for ZSHWL
Number of matching file entries = 146
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
-- --- ------------------ ---- --- ------------ ------------ --------------
B  D  20150616131903001   F    D  S0000000.LOG S0000000.LOG
----------------------------------------------------------------------------
Contains 3 tablespace(s):
00001 SYSCATSPACE
00002 USERSPACE1
00003 SYSTOOLSPACE
Comment: DB2 BACKUP ZSHWL OFFLINE
Start Time: 20150616131903
End Time: 20150616131944
Status: A
EID: 751 Location: /home/db2inst1
……
DB2还提供了一个工具db2adutl用来管理TSM上的数据库备份映像以及事务日志归档，这个工具会通过TSM Client API来访问TSM上的备份数据。db2adutl可以用来完成查询、取回、验证和删除数据库在TSM上的备份映像、事务日志归档等对象，也可以完成特定对象对指定节点的指定用户进行访问授权。
可以通过db2adutl que-ry命令来查询当前数据库在TSM上的备份，登录到数据库实例用户，发起以下命令来查询:
[db2inst1@db2tsmdrill ~]$ db2adutl query FULL db ZSHWL
Query for database ZSHWL
Retrieving FULL DATABASE BACKUP information.
1 Time: 20150616134107  Oldest log: S0000001.LOG  DB Partition Number: 0    Sessions: 2
2 Time: 20150616132313  Oldest log: S0000000.LOG  DB Partition Number: 0    Sessions: 2
3 Time: 20150616112801  Oldest log: S0000000.LOG  DB Partition Number: 0    Sessions: 2
4 Time: 20150616112700  Oldest log: S0000000.LOG  DB Partition Number: 0    Sessions: 1
5 Time: 20150616104649  Oldest log: S0000000.LOG  DB Partition Number: 0    Sessions: 1
Retrieving INCREMENTAL DATABASE BACKUP information.
1 Time: 20150616134147  Oldest log: S0000002.LOG  DB Partition Number: 0    Sessions: 2
Retrieving DELTA DATABASE BACKUP information.
No DELTA DATABASE BACKUP images found for ZSHWL
从上面命令的输出我们可以看到，对于恢复演练DB2服务器上db2inst1实例内的ZSHWL数据库，在TSM上存在5个全量备份，1个增量备份。
可以使用db2adutl的verify选项来对TSM上备份的数据库映像进行验证:
[db2inst1@db2tsmdrill ~]$ db2adutl verify full taken at 20150616112700 db ZSHWL
Retrieving FULL DATABASE BACKUP information.  Please wait.
FULL DATABASE BACKUP image:
./ZSHWL.0.db2inst1.NODE0000.CATN0000.20150616112700.001, DB Partition Number: 0
Do you wish to verify this image? (Y/N) Y
Verifying file: ./ZSHWL.0.db2inst1.NODE0000.CATN0000.20150616112700.001
#######################
Warning: only partial image read, bytes read: 16384 of 16781312
Read 0 bytes, assuming we are at the end of the image
Image Verification Complete - successful.
No INCREMENTAL DATABASE BACKUP images found for ZSHWL
我们可以看到，db2adutl从TSM上把相应时间备份的数据库映像取回到本地，并且读取了部分数据进行正确性验证。
六、数据库的恢复
本节在恢复演练DB2服务器上演示其中db2inst1实例上的ZSHWL数据库的恢复。分别进行离线全量备份、在线全量备份和在线增量备份这3种不同备份的恢复。
首先，我们来尝试将备份时间为20150616104649的离线全量备份恢复到db2inst1实例上。
先将原有数据库删除:
[db2inst1@db2tsmdrill ~]$ db2 drop db ZSHWL
DB20000I  The DROP DATABASE command completed successfully.
[db2inst1@db2tsmdrill ~]$ db2 list db directory
SQL1057W  The system database directory is empty.  SQLSTATE=01606
使用带use tsm选项的db2 restore命令进行恢复:
[db2inst1@db2tsmdrill ~]$ db2 restore db ZSHWL use tsm taken at 20150616104649
DB20000I  The RESTORE DATABASE command completed successfully.
由于是离线全量备份，所以没有事务日志前滚的问题，一旦恢复成功就可以直接连接数据库进行使用了:
[db2inst1@db2tsmdrill ~]$ db2 connect to ZSHWL
第二，我们来恢复在线全量备份。我们来尝试将备份时间为20150616134107的在线全量备份恢复到db2inst1实例上。
[db2inst1@db2tsmdrill ~]$ db2 restore db ZSHWL use tsm taken at 20150616134107
由于我们恢复的是一个在线的全量备份，所以当恢复成功后，还不能直接连接和使用数据库，因为还需要进行事务日志的前滚操作。此时去连接数据库会得到以下的错误提示:
SQL1117N  A connection to or activation of database "ZSHWL" cannot be made
because of ROLL-FORWARD PENDING.  SQLSTATE=57019
这个提示告诉我们，数据库处于ROLL-FORWARD PENDING状态，不能使用。
使用db2 rollforward命令进行事务日志前滚操作:
[db2inst1@db2tsmdrill ~]$ db2 rollforward db ZSHWL to end of logs and stop
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                    = S0000001.LOG - S0000002.LOG
Last committed transaction             = 2015-06-16-05.41.52.000000 UTC
DB20000I  The ROLLFORWARD command completed successfully.
现在，可以数据库可以正常被连接和使用了:
DB2和TSM Client API对事务日志到底是怎么处理的呢?DB2 ROLLFOR-WARD会按顺序在以下位置查找所需要的事务日志:
1.事务日志目录
[db2inst1@db2tsmdrill SQL00001]$ db2 get db cfg for ZSHWL | grep "Path to log files"
Path to log files = /home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/
2.事务日志镜像目录
[db2inst1@db2tsmdrill SQL00001]$ db2 get db cfg for ZSHWL | grep MIRRORLOGPATH
Mirror log path                         (MIRRORLOGPATH) =
3.事务日志溢出目录
[db2inst1@db2tsmdrill SQL00001]$ db2 get db cfg for ZSHWL | grep OVERFLOWLOGPATH
Overflow log path                     (OVERFLOWLOGPATH) =
4.事务日志归档方式1(LOGARCHMETH1)
[db2inst1@db2tsmdrill SQL00001]$ db2 get db cfg for ZSHWL | grep LOGARCHMETH1
First log archive method                 (LOGARCHMETH1) = TSM
5.事务日志归档方式2(LOGARCHMETH2)
[db2inst1@db2tsmdrill SQL00001]$ db2 get db cfg for ZSHWL | grep LOGARCHMETH2
Second log archive method                (LOGARCHMETH2) = OFF
6.事务日志归档故障备用目录(FAILARCHPATH)
[db2inst1@db2tsmdrill SQL00001]$ db2 get db cfg for ZSHWL | grep FAILARCHPATH
Failover log archive path                (FAILARCHPATH) =
以上所有位置都无法找到需要的日志时，DB2 ROLLFORWARD会报错误。本例中由于 LOG-ARCHMETH1设置为TSM，而且DB2 ROLLFOR-WARD所需要的事务日志全部都已经归档到TSM中，所以DB2可以从TSM中把事务日志取回到事务日志目录/home/db2inst1/db2inst1/NODE0000 /SQL00001/SQLOGDIR/中，然后再进行前滚操作。
那么如果事务日志没有归档，或者事务日志损坏了应该怎么对在线备份进行恢复呢?由于在线备份时，默认会将备份期间归档的事务日志包含到备份映像中，所以我们可以使用logtarget选项，从备份映像中将事务日志取到指定的位置。下面我们再次恢复这个在线备份，不同的是在恢复在线备份同时，取出事务日志放到指定的路径~/logretrieve下以便前滚操作时使用:
[db2inst1@db2tsmdrill ~]$ rmdir logretrieve/
[db2inst1@db2tsmdrill ~]$ db2 restore db ZSHWL use tsm taken at 20150616134107 logtarget ~/logretrieve
我们可以看到备份期间产生的事务日志已经放置到~/logretrieve路径下:
[db2inst1@db2tsmdrill ~]$ ls logretrieve/
S0000001.LOG
注意，这里仅包括在线备份期间产生的事务日志，如果需要前滚到备份之后更接近当前的时间，就需要更多的事务日志，如果事务日志已经归档到TSM，则可以用db2adutl extract logs命令将后续的事务日志取回并且前滚，在第6节有详细的步骤说明。
在这个例子里，我们只前滚在线备份期间产生的事务日志，以使数据库恢复到在线备份完成那一刻的状态:
[db2inst1@db2tsmdrill ~]$ db2 "rollforward db ZSHWL to end of logs and stop overflow log path ('/home/db2inst1/logretrieve')"
这里我们用了overflow log path选项来指定了前滚时所需要的事务日志的路径。
最后，我们进行在线增量备份的恢复，在db2 restore中使用选项incremental automat-ic可以让db2从TSM备份序列中自动按顺序恢复所有必须的备份，包括最近一次的全量备份以及后续直到被恢复的增量备份之间的所有增量备份，下面我们进行这种操作来恢复20150616134147这个在线增量备份:
[db2inst1@db2tsmdrill ~]$ db2 restore db ZSHWL incremental automatic use tsm taken at 20150616134147
Log files processed                    = S0000002.LOG - S0000002.LOG
至此，我们已经完成在相同节点上的3种类型的数据库恢复。
七、跨节点进行数据库恢复
实际应用中，经常会有跨节点进行数据库恢复的需求。比如，验证生产数据库备份的正确性，或者，要将生产数据库恢复到预生产或者测试的数据库服务器中以供测试和开发使用。使用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
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
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 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.
由于使用了redirect选项，所以恢复中途会停顿以便用户配置Table space，本例中，我们不需要对Table space进行配置，可以直接使用continue选项继续恢复:
[db2inst1@db2tsmdrill ~]$ db2 restore db ZSHWL continue
当以上恢复操作完成之后，由我们恢复的是在线备份的数据库，所以还需要进行事务日志的前滚操作才可以正常连接数据库，不然，连接数据库时会出现SQL1117N错误。
在~/logretrieve目录可以查看到与在线备份的同时写入TSM的事务日志:S0000286.LOG。由于源数据库的LOGARCH-METH1被配置为TSM，所以它的事务日志已经都归档在TSM中，所以我们可以通过TSM来取回其它需要的事务日志。
我们可以查看当前数据库前滚的状态:
[db2inst1@db2tsmdrill logretrieve]$ db2 rollforward db ZSHWL query status
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
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
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
./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')"
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
我们看到，所有事务日志都已经被处理完成，最后提交的事务时间是UTC时间6月9日16点11分38秒(在前滚之前，最后的事务在UTC时间6月4日16时11分39秒提交)，从S0000286.LOG到S0000292.LOG的事务日志都已经被处理。
至此，跨节点恢复数据库已经完成。我们还需要做最后一个操作以使目标数据库可以被连接:
[db2inst1@db2tsmdrill ~]$ db2 rollforward db ZSHWL complete
现在我们可以正常地连接到目标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备份的最佳选择。
作者简介:
▲方达宏
任职于某大型外资IT企业，长期从事IT基础架构运维。实践经验丰富，熟悉TSM系统的维护。