作者在實踐基于TSM的DB2備份的時候發(fā)現(xiàn)，已有的資料不是側(cè)重于介紹TSM就是側(cè)重于介紹DB2備份方法，而介紹基于TSM的DB2備份、恢復(fù)方法以及DB2的跨節(jié)點恢復(fù)方法的資料分散于各處，由于沒有比較系統(tǒng)的資料以及介紹最佳實踐操作方法的文章，作者在實踐過程中十分不便，因此萌發(fā)了寫一個全面系統(tǒng)介紹這方面內(nèi)容的文章的想法。本文通過具體案例詳細介紹了使用TSM進行DB2備份和恢復(fù)的方法，同時也介紹了如何跨節(jié)點進行DB2數(shù)據(jù)庫恢復(fù)的步驟。讀者可以通過這個案例了解到DB2如何結(jié)合TSM API實現(xiàn)便捷的數(shù)據(jù)庫備份和恢復(fù)所需要的所有配置步驟和操作步驟，也可以了解到如何將一個數(shù)據(jù)庫恢復(fù)到與原始服務(wù)器不同的服務(wù)器中去。在本文中，讀者可以了解到基本的原理，也可以按照文章介紹的步驟，跟隨作者一步一步地去實現(xiàn)基于TSM的DB2備份、恢復(fù)，以及跨節(jié)點恢復(fù)。

IBM DB2是廣泛應(yīng)用的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)產(chǎn)品，其上包含了關(guān)鍵數(shù)據(jù)。IBM DB2結(jié)合IBM Tivoli Storage Manager(本文后稱TSM)可以實現(xiàn)便捷地數(shù)據(jù)備份和恢復(fù)，以保護這些關(guān)鍵數(shù)據(jù)。

作者在協(xié)助一家IT公司管理其IDC的過程中，遇到需要定期備份指定的生產(chǎn)DB2數(shù)據(jù)的需求，而且這些備份的數(shù)據(jù)需要被定期恢復(fù)到其它DB2服務(wù)器中以用于檢查備份的有效性，同時，這些備份的生產(chǎn)數(shù)據(jù)要求在每天晚上被恢復(fù)到用于開發(fā)測試的DB2服務(wù)器中以用于使開發(fā)測試環(huán)境盡量保持于實際生產(chǎn)環(huán)境的數(shù)據(jù)一致。

目前，這套機制已經(jīng)運行2年，5個生產(chǎn)數(shù)據(jù)庫每周末進行在線全量備份，每日深夜進行增量備份;部分生產(chǎn)數(shù)據(jù)庫在每天晚上在備份結(jié)束后跨節(jié)點恢復(fù)到開發(fā)測試用的DB2服務(wù)器中;其它生產(chǎn)數(shù)據(jù)庫每月進行一次跨節(jié)點的恢復(fù)演練，將備份的數(shù)據(jù)恢復(fù)到在臺用于檢查備份數(shù)據(jù)有效性的DB2服務(wù)器中(后稱“恢復(fù)演練DB2服務(wù)器”)。

由于有良好的備份機制以及備份數(shù)據(jù)有效性驗證的機制，在一次生產(chǎn)事故中，一臺生產(chǎn)DB2服務(wù)器的磁盤邏輯分區(qū)損壞，導(dǎo)致1個生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)遭受永久的損壞。通過從TSM中成功恢復(fù)數(shù)據(jù)，結(jié)合從TSM中進行事務(wù)日志的恢復(fù)操作，只丟失事故前幾分鐘的數(shù)據(jù)，從而保障了該IT公司的重要數(shù)字資產(chǎn)。

作者在當初實施這個項目時發(fā)現(xiàn)，雖然有海量的參考資料，包括IBM的紅皮書，以及其它用戶的使用經(jīng)驗。但是，已有的資料不是側(cè)重于介紹TSM就是側(cè)重于介紹DB2備份方法，而介紹基于TSM的DB2備份、恢復(fù)方法以及DB2的跨節(jié)點恢復(fù)方法的資料分散于各處，由于沒有比較全面的資料以及實際的最佳實踐操作方法，作者在實踐過程中十分不便。在整個項目實施運行并且證實有效之后，萌發(fā)了寫一個全面介紹這方面內(nèi)容的文章的想法。希望可以在文中，可以全面介紹相關(guān)的原理，讀者也可以按照文章介紹的步驟，跟隨作者一步一步地去實現(xiàn)基于TSM的DB2備份、恢復(fù)，以及跨節(jié)點恢復(fù)，而不需要每做一步都需要到浩瀚的資料大洋中搜索相關(guān)的內(nèi)容。

本文通過具體案例，詳細地介紹數(shù)據(jù)備份、備份計劃以及數(shù)據(jù)恢復(fù)的步驟和方法。同時，本文也介紹了將一個數(shù)據(jù)庫恢復(fù)到其它數(shù)據(jù)庫服務(wù)器中去的步驟和方法。

一、原理簡介

使用TSM進行數(shù)據(jù)備份有多種方式，本文介紹的是讓DB2調(diào)用TSM API所提供的函數(shù)直接將數(shù)據(jù)庫和表空間備份發(fā)送到TSM服務(wù)器的方式，這種方式經(jīng)過2年的運行以來，證實是便捷和可靠的。圖1表示了這種方法的架構(gòu)。

▲圖1

 

二、實驗環(huán)境介紹

本案例以實際生產(chǎn)環(huán)境為例，包含了TSM系統(tǒng)(服務(wù)器、存儲和帶庫)、DB2服務(wù)器 和恢復(fù)演練用的DB2服務(wù)器。

▲圖2

 

圖2說明了整個實驗環(huán)境相關(guān)的設(shè)備之間的關(guān)系，生產(chǎn)DB2服務(wù)器和恢復(fù)演練DB2服務(wù)器都由IP網(wǎng)絡(luò)與TSM Server連接;TSM Server與存儲設(shè)備之間以SAN Fab-ric連接，為了說明的方便，不展開TSM多級存儲的說明和討論。我們將在后面的步驟操作中把一臺DB2服務(wù)器上的數(shù)據(jù)備份到TSM系統(tǒng)中，隨后再把數(shù)據(jù)從TSM系統(tǒng)中恢復(fù)到同一臺DB2服務(wù)器上;在之后，我們再說明將數(shù)據(jù)從一臺DB2服務(wù)器上備份到TSM系統(tǒng)之后再恢復(fù)到另一臺DB2服務(wù)器上。

▲圖3

 

圖3說明了TSM系統(tǒng)內(nèi)的NODE配置以及與2臺DB2 Serv-er的實例和數(shù)據(jù)庫之間的關(guān)系。在TSM系統(tǒng)上為生產(chǎn)DB2服務(wù)器創(chuàng)建了1個NODE，名為PRODDB2;為恢復(fù)演練DB2服務(wù)器創(chuàng)建了1個NODE，名為DRILLDB2， 這2個NODE都屬于策略域DB2DOMAIN。在DB2DOMAIN策略域中，創(chuàng)建了一個名為DB2MGMTCLASS的管理類，在這個管理類中可以定義諸如備份版本數(shù)量、備份保持時長等等備份和歸檔策略，2個NODE都與該管理類關(guān)聯(lián)。在生產(chǎn)DB2服務(wù)器上有實例db2inst1，在該實例內(nèi)運行了一個數(shù)據(jù)庫ZSHWL，在之后的步驟中，我們將在生產(chǎn)DB2服務(wù)器上安裝TSM Client API，并且在這個API上配置登錄到TSM系統(tǒng)的PRODDB2節(jié)點中。相類似的，恢復(fù)演練DB2服務(wù)器上的TSM Client API將登錄到TSM系統(tǒng)的DRILLDB2節(jié)點中。

▲圖4

 

三、TSM Client API安裝和配置

要采用圖1的架構(gòu)進行數(shù)據(jù)庫備份或者恢復(fù)都需要在DB2服務(wù)器上安裝TSM Client API。首先要在DB2實例用戶下運行db2level來確定DB2是32位的還是64位的，如下粗體部分顯示本案例中的生產(chǎn)DB2服務(wù)器安裝的是64位版本的DB2服務(wù)器：

[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".

到官網(wǎng)網(wǎng)址：http://www-01.ibm.com/support/docview.wss?uid=swg21239415去下載相應(yīng)的軟件，解包后依次運行下述命令行即可完成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。

在生產(chǎn)DB2服務(wù)器上配置如下：

[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

在恢復(fù)演練DB2服務(wù)器上配置如下：

[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

然后，在生產(chǎn)DB2服務(wù)器和恢復(fù)演練DB2服務(wù)器中的dsm.opt中啟用TSM Server配置：

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

在完成以上配置后，為TSM Client API設(shè)置TSM NODE的帳號密碼，用root權(quán)限在其中一個實例用戶的sqllib/adsm目錄內(nèi)執(zhí)行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服務(wù)器上做1次就可以，做完以上操作之后，需要為每個DB2實例進行與TSM Client API相關(guān)的環(huán)境變量的配置，在每個需要進行備份和恢復(fù)操作的DB2實例上都要做一次。

以下是生產(chǎn)DB2服務(wù)器上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之后，需要重新登錄實例用戶，這些環(huán)境變量才能生效。在這些環(huán)境變量生效時，重新啟動DB2實例才可以使用TSM Client API進行數(shù)據(jù)庫備份和恢復(fù)。

注意：在生產(chǎn)環(huán)境進行數(shù)據(jù)庫TSM備份變更時，有3個地方要重啟DB2實例：

1.安裝TSM Client API需要在 DSMI_CONFIG、 DSMI_LOG、 DSMI_DIR這3個環(huán)境變量配置正確時重啟DB2實例。

2.為在線備份修改LOGARCHMETH1參數(shù)后，要重啟數(shù)據(jù)庫實例。

3.為增量備份修改TRACKMOD參數(shù)后，要重啟數(shù)據(jù)庫實例。

建議完成以上3處變更后一并重啟數(shù)據(jù)庫實例，可以減少停機時間。

[page]

七、跨節(jié)點進行數(shù)據(jù)庫恢復(fù)

實際應(yīng)用中，經(jīng)常會有跨節(jié)點進行數(shù)據(jù)庫恢復(fù)的需求。比如，驗證生產(chǎn)數(shù)據(jù)庫備份的正確性，或者，要將生產(chǎn)數(shù)據(jù)庫恢復(fù)到預(yù)生產(chǎn)或者測試的數(shù)據(jù)庫服務(wù)器中以供測試和開發(fā)使用。使用TSM Client API可以非常方便地實現(xiàn)這種跨節(jié)點的恢復(fù)。

在進行跨節(jié)點數(shù)據(jù)庫恢復(fù)時，要注意目標節(jié)點的DB2與源節(jié)點的DB2的版本要一致。可以使用db2level來查看詳細的版本信息。

以下將以把數(shù)據(jù)庫ZSHWL從生產(chǎn)DB2服務(wù)器的db2inst4實例恢復(fù)到恢復(fù)演練DB2服務(wù)器的db2inst1實例中為例，說明如何實現(xiàn)數(shù)據(jù)庫的跨節(jié)點和跨實例名恢復(fù)。

要實現(xiàn)跨節(jié)點數(shù)據(jù)庫恢復(fù)，首先要在源節(jié)點實例用戶上對目標節(jié)點的實例用戶進行TSM備份訪問授權(quán)。本示例中需要將在生產(chǎn)DB2服務(wù)器的db2inst4實例中的ZSHWL數(shù)據(jù)庫的備份訪問權(quán)授權(quán)給恢復(fù)演練DB2服務(wù)器(TSM NODE: DRILLDB2)上的db2inst1實例用戶。

登錄源節(jié)點上的實例用戶，即生產(chǎn)DB2服務(wù)器的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.

在源節(jié)點實例中，可以查詢已經(jīng)對哪些數(shù)據(jù)庫向哪些節(jié)點進行了授權(quán)：

[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

此時，在目標節(jié)點用實例用戶，即恢復(fù)演練DB2服務(wù)器的db2inst1用戶中，已經(jīng)可以查詢到源節(jié)點中的ZSHWL的備份信息了。登錄到目標節(jié)點的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
……

如果源節(jié)點沒有對目標節(jié)點進行授權(quán)，在目標節(jié)點上是無法查詢到源節(jié)點的備份信息的。

下面，我們來在恢復(fù)演練DB2服務(wù)器上恢復(fù)源節(jié)點上(生產(chǎn)DB2服務(wù)器上)時間標簽為20150605001133的ZSHWL數(shù)據(jù)庫備份。

由于20150605001133是一個增量備份，所以我們使用incremental automat-ic選項來實現(xiàn)自動的增量恢復(fù);由于要將數(shù)據(jù)庫恢復(fù)到與源數(shù)據(jù)庫不同的目錄，所以使用了redirect選項;由于是在線備份，所以我們使用logtarget將在線備份的同時備份到TSM的事務(wù)日志取到~/logretrieve目錄中。本例中，我們將數(shù)據(jù)庫恢復(fù)到目標服務(wù)器的實例home目錄，即/home/db2inst1;同時將事務(wù)日志取回到/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選項，所以恢復(fù)中途會停頓以便用戶配置Table space，本例中，我們不需要對Table space進行配置，可以直接使用continue選項繼續(xù)恢復(fù)：

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

當以上恢復(fù)操作完成之后，由我們恢復(fù)的是在線備份的數(shù)據(jù)庫，所以還需要進行事務(wù)日志的前滾操作才可以正常連接數(shù)據(jù)庫，不然，連接數(shù)據(jù)庫時會出現(xiàn)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的事務(wù)日志：S0000286.LOG。由于源數(shù)據(jù)庫的LOGARCH-METH1被配置為TSM，所以它的事務(wù)日志已經(jīng)都歸檔在TSM中，所以我們可以通過TSM來取回其它需要的事務(wù)日志。

我們可以查看當前數(shù)據(jù)庫前滾的狀態(tài)：

[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

從以上輸出可以看到，目前數(shù)據(jù)庫處于Rollforward status的DB work-ing狀態(tài)，需要前滾，否則不能連接;下一個要處理的事務(wù)日志是S0000286.LOG，最后的事務(wù)在UTC時間6月4日16時11分39秒提交。

我們先查看一下需要從TSM取回哪些事務(wù)日志，在目標服務(wù)器上的數(shù)據(jù)庫實例用戶中執(zhí)行db2adutl查詢源數(shù)據(jù)庫歸檔的事務(wù)日志：

[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取回源數(shù)據(jù)庫歸檔的從S0000287.LOG開始到最后1個S0000292.LOG的所有事務(wù)日志，存放到目標節(jié)點上：

[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

我們需要的事務(wù)日志都已經(jīng)取回到./logretrieve/NODE0000/ZSHWL/C0000000目錄之內(nèi)了。

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

現(xiàn)在我們開始為ZSHWL數(shù)據(jù)庫前滾日志。將所有日志文件都移動到~/logretrieve目錄中：

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

使用下面的命令行來執(zhí)行事務(wù)日志前滾：

[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.

我們看到，所有事務(wù)日志都已經(jīng)被處理完成，最后提交的事務(wù)時間是UTC時間6月9日16點11分38秒(在前滾之前，最后的事務(wù)在UTC時間6月4日16時11分39秒提交)，從S0000286.LOG到S0000292.LOG的事務(wù)日志都已經(jīng)被處理。

至此，跨節(jié)點恢復(fù)數(shù)據(jù)庫已經(jīng)完成。我們還需要做最后一個操作以使目標數(shù)據(jù)庫可以被連接：

[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.

現(xiàn)在我們可以正常地連接到目標ZSHWL數(shù)據(jù)庫了：

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

八、小結(jié)

從本文所舉的案例來看，DB2和TSM是在設(shè)計上高度融合，集成度很高。采用TSM來保護DB2的數(shù)據(jù)功能齊全、操作簡便。

TSM Client API和DB2結(jié)合能夠高度自動化地幫助管理員完成各項工作任務(wù)。從上面步驟中可以看出，日常的備份和恢復(fù)操作實際上是使用DBA所熟悉的DB2命令行來實施的，使用不同的參數(shù)就可以執(zhí)行備份到本地磁盤或者備份到TSM系統(tǒng)中，在這個過程中TSM管理員可以不介入，從而達到管理角色分離的目的，這得益于DB2與TSM的天然的集成。

在實施過程中需要特別注意的是有幾處變更是需要重啟數(shù)據(jù)庫實例的，比如安裝TSM Client API后、修改LOGARCHMETH1和TRACKMOD參數(shù)后，都需要重啟數(shù)據(jù)庫實例。在生產(chǎn)環(huán)境中實施時，需要事先申請停機時間。另外，在能夠?qū)嵤┰诰€備份之前是需要做一次離線備份的，此時數(shù)據(jù)庫不能向任何用戶(應(yīng)用)提供服務(wù)，這也需要在停機時間內(nèi)完成。

采用TSM Client API來備份DB2數(shù)據(jù)時有一個地方會使人感到困惑。因為DB2有它自己的版本控制機制，同一個數(shù)據(jù)庫的每個備份版本在TSM中都有一個唯一的命名。而正因為這種唯一的命名使TSM把每一個備份版本都認為是一個獨立的備份對象，從而每個版本都當作一個ACTIVE的備份對象來看待。只有當使用 db2adutl de-lete命令來“刪除”某個版本(備份對象)時，這個備份對象才會被TSM標記為INACTIVE，到達TSM策略域所設(shè)定的過期時間后這個對象才會被TSM過期。因此，對于DB2備份對象TSM中的相應(yīng)策略域中版本數(shù)和保持策略需要一些特別的設(shè)定。具體可以參考鏈接： http://www-01.ibm.com/support/docview.wss?uid=swg21263834。

本文描述的場景適用于日常生產(chǎn)數(shù)據(jù)的備份恢復(fù)，也可用于建立一個生產(chǎn)數(shù)據(jù)庫的“影子”數(shù)據(jù)庫來用于開發(fā)測試，采用定時任務(wù)的方式，可以在每天凌晨更新“影子”數(shù)據(jù)庫，以使開發(fā)測試環(huán)境盡量接近真實環(huán)境。

總之，使用TSM來保護DB2簡單易實施，日常的備份和恢復(fù)工作非常輕松，還可以采用crontab或者TSM的schedule來實現(xiàn)自動的定時備份任務(wù)，是用于DB2備份的最佳選擇。

作者簡介：

▲方達宏