以下的文章主要向大家講述的是正確利用表空間的備份來對IBM DB2數據庫進行快速的恢復的實際操作步驟，以下就是對IBM DB2數據庫恢復的實際操作步驟的介紹，希望會給你帶來一些幫助在此方面。
IBM DB2 數據庫
在DB2 V9版本中，提供了一個重要的新特性，即利用DB2表空間的備份來快速恢復數據庫，甚至可以根據數據的重要性選擇恢復一部分重要數據，達到快速恢復的目的。本文結合實例對DB2 V9的該重要技術特性做了詳細介紹，希望對用戶規劃系統備份/恢復策略有所幫助。
關於DB2數據庫的恢復(Rebuild)
當我們的DB2數據庫由於一些嚴重錯誤 ( 如存儲損壞等 ) 而導致數據庫庫損壞時，我們通常需要在修復相關錯誤後，通過Restore命令來進行數據庫的恢復(DB2目前也支持通過 HADR 等多機容錯機制實現系統高可用，本文僅對單機數據庫損壞，需要進行數據庫恢復的情況進行探討 )。
一般的做法是通過以前的數據庫全備份來進行整庫恢復，然後通過日志對數據庫進行前滾(RollForward)，從而使數據庫恢復到接近災難點的時間。但當我們數據庫的數據量較大時，數據庫的全備份和整庫恢復都會很是非常消耗時間的。
在DB2 V9版本中，提供了一個重要的新特性，即利用DB2表空間的備份來快速恢復IBM DB2數據庫，甚至可以根據數據的重要性選擇恢復一部分重要數據，達到快速恢復的目的。本文結合實例對DB2 V9的該重要技術特性做了詳細介紹，希望對用戶規劃系統備份 / 恢復策略有所幫助。
場景1：利用表空間備份來重建整個DB2數據庫
在進行數據庫重建時，DB2 V9現在能夠支持通過表空間一級的備份來重建整個數據庫，而不需要整個數據庫的全備份。DB2的此項能力使得我們對核心系統的重要數據進行快速備份和恢復成為可能。讓我們首先看以下的一個例子：
假設我們有一個數據庫TEST，該數據庫采用歸檔日志。某天，系統突然掉電，導致數據庫存放的磁盤損壞了。這時，數據庫將處於不可用的狀態，作為 DBA，我們需要迅速對數據庫進行恢復。假如該數據庫有以下的表空間：
SYSCATSPACE ( 系統表空間 )
USERSPACE1 ( 用戶數據表空間 1)
USERSPACE2 ( 用戶數據表空間 2)
USERSPACE3 ( 用戶數據表空間 3)
你手頭可用於進行IBM DB2數據庫恢復的數據包括 :
所有數據庫日志文件由於日志被存放在另外的磁盤上(而且很多時，我們還會對日志進行鏡像，因為它們實在太重要了)，因此它們沒有損壞。
你沒有數據庫的全備份，但是你有以下的表空間備份：
TEST.3.DB2.NODE0000.CATN0000.20060515135047.001 - SYSCATSPACE 和 USERSPACE 1 表空間在 2006051513504 7 時間點的備份；
TEST.3.DB2.NODE0000.CATN0000.20060516135136.001 - USERSPACE 2 和 USERSPACE 3 表空間在 2006051613513 6 時間點的備份；
TEST.3.DB2.NODE0000.CATN0000.20060517135208.001 - USERSPACE 3 表空間在 2006051713520 8 時間點的備份。
對於傳統的Restore和Rollforward的DB2恢復策略，我們需要一個數據庫的全備份影像來進行數據庫恢復然後利用日志來進行數據庫的前滾(Rollforward)操作，但不幸的是，在本例中，我們並沒有數據庫的全備份，而只有不同時間做的表空間備份。
錯誤的數據庫恢復方法
如果我們試圖直接用表空間備份來恢復整個數據庫，我們會得到以下的錯誤提示：
清單1 ：直接用表空間備份來恢復整個數據庫的錯誤提示
- db2 restore db test taken at 20060517135208
- SQL2560N The target database is not identical to the source database
- for a restore from a table space level backup.
上述命令支持完整數據庫備份的數據庫恢復，不支持表空間級別的數據庫恢復。
利用表空間備份恢復數據庫
在DB2 V9中，提供了一個新的功能，就是通過表空間備份和日志來快速重建整個 IBM DB2數據庫，這個功能是通過在RESTORE DATABASE命令中加入REBUILD選項來實現的。
以下的步驟幫助我們通過REBUILD選項來利用表空間備份恢復TEST數據庫：
第一步，我們利用表空間備份執行帶REBUILD選項的RESTORE DATABASE命令恢復數據庫。
清單2：通過REBUILD選項來利用表空間備份恢復TEST數據庫
- db2 restore db test rebuild with all tablespaces in database taken at 20060517135208
這一步我們是從已有的幾個表空間備份影像中選取一個備份來進行數據庫恢復。一般，我們會選取最近備份的表空間影像，這個備份影像我們稱之為“目標影像”(Target Image)，因為它包含了我們用於恢復 TEST 數據庫所需的最新的表空間備份、數據庫配置參數、日志序列等重要信息。實際上，這個“目標影像”可以是任何一種備份 ( 全備份、表空間備份、增量備份、在線或離線的備份 )。在本例中，最近的一個備份影像是TEST.3.DB2.NODE0000.CATN0000.20060517135208.001，因此我們就選取它作為我們進行數據庫恢復的“目標影像”。
當我們執行完上述RESTORE命令之後，TEST數據庫的結構將被重建和恢復。我們可以得到IBM DB2數據庫的參數和其備份歷史之類的信息。如果我們發出LIST HISTORY命令 ( 如：LIST HISTORY ALL FOR TEST)，我們將得到以下的輸出參照清單 3） 。
清單3 ：使用 LIST HISTORY查詢數據庫備份歷史信息
- Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
- R D 20060519121107001 F 20060517135208
- Contains 1 tablespace(s):
- 00001 USERSPACE3
- Comment: RESTORE TEST WITH RF
- Start Time: 20060519121107
- End Time: 20060519121108
- Status: A
- EID: 7 Location:
- Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
- R P 20060519121108001 F 20060515135047
- Contains 2 tablespace(s):
- 00001 USERSPACE1
- 00002 SYSCATSPACE
- Comment: RESTORE TEST WITH RF
- Start Time: 20060519121108
- End Time: 20060519121113
- Status: A
- EID: 8 Location:
- Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
- R P 20060519121113001 F 20060516135136
- Contains 1 tablespace(s):
- 00001 USERSPACE2
- Comment: RESTORE TEST WITH RF
- Start Time: 20060519121113
- End Time: 20060519121114
- Status: A
- EID: 9 Location:
- Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
- R D 20060519121107 R S0000001.LOG S0000003.LOG 20060518135208
- Contains 4 tablespace(s):
- 00001 USERSPACE3
- 00002 USERSPACE2
- 00003 USERSPACE1
- 00004 SYSCATSPACE
- Comment: REBUILD TEST WITH RF
- Start Time: 20060519121107
- End Time: 20060519121115
- Status: A
- EID: 10 Location:
如上，LIST HISTORY 命令產生了 4 條輸出條目 (EID 7 – EID 10)，它們都和我們數據庫的恢復有關。第一個條目，EID 7，包含了在 20060517135208 時間點做的備份影像，該備份影像中我們只對 USERSPACE3 做了備份。然而，回顧我們進行數據庫恢復時發出的命令，參照清單 4。
清單4:使用ALL TABLESPACES參數恢復數據庫
- db2 restore db test rebuild with all tablespaces in database taken at 20060517135208
我們使用了ALL TABLESPACES參數要求恢復所有的表空間，所以DB2會利用LIST HISTORY中所看到的其它備份影像來恢復數據庫其它的表空間( 注意，在使用 TEST.3.DB2.NODE0000.CATN0000.20060516135136.001備份影像進行恢復時EID=9，雖然該影像包括 USERSPACE2 和 USERSPACE3 的備份，但 DB2只恢復了USERSPACE2，因為 USERSPACE3 已經通過更新的備份影像 TEST.3.DB2.NODE0000.CATN0000.20060517135208.001完成恢復了 )。
在完成上述恢復後，表空間將處於 ROLL-FORWARD 狀態。通過LIST HISTORY命令，我們可以看到表空間都被置成了 WITH RF 標志，表明這些表空間處於ROLL-FORWARD 狀態。另外，為了使該恢復順利完成，所有備份影像都需要放在 HISTORY FILE所表明的備份路徑下，否則 DB2將會給出一個無法找到備份影像的錯誤提示。
第二步，通過ROLLFORWARD DATABASE命令及TO END OF LOGS選項來前滾IBM DB2數據庫TEST，使其恢復到最近的一個同步時間點(Point in Time)。
清單5：前滾數據庫到最近的一個同步時間點
- db2 rollforward db test to end of logs
當所有表空間恢復完畢，它們將處於rollforward pending的狀態，我們需要通過數據庫日志和 rollforward 命令來對數據庫進行前滾操作，從而將數據庫置為正常(Normal)狀態。
為了順利完成前滾操作，從上述備份影像最早一個時間點到最近一個時間點之間的數據庫日志必須存在，以用於將上述通過不同時間點備份影像進行恢復的表空間前滾到同一時間點上。本例中，從 20060515135047 到 20060517135208 時間點的日志必須存在，我們才可以將表空間同步到同一個時間點。如果我們還想繼續前滾數據庫，則我們還需要從 20060517135208 時間點往後的日志文件。
在本例中，我們假設這些日志文件都能夠在LOGPATH數據庫配置參數所指定的目錄中找到，如果它們被移動了位置，則我們還需要在 ROLLFORWARD 命令中通過OVERFLOW LOG PATH選項來指定這些日志文件的新位置。
第三步，通過執行ROLLFORWARD DATABASE命令來結束數據庫前滾的狀態。
清單6：結束IBM DB2數據庫前滾的命令
- db2 rollforward db test stop
該命令執行完畢後，TEST數據庫就恢復到NORMAL狀態，這樣您就可以正常使用它了。
