七、跨节点进行数据库恢复
实际应用中，经常会有跨节点进行数据库恢复的需求。比如，验证生产数据库备份的正确性，或者，要将生产数据库恢复到预生产或者测试的数据库服务器中以供测试和开发使用。使用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备份的非常好的选择。
作者简介：
▲方达宏
任职于某大型外资IT企业，长期从事IT基础架构运维。实践经验丰富，熟悉TSM系统的维护。
