今天像大家描述的是DB2數據庫恢復的一些實際操作經驗的總結，前幾天我們剛進行DB2數據庫恢復測試，想不到這麼快就用到了。所以說每當你發現某個技術可能會用到，但是還沒動過手，必須立即動下手。說不定那天就要用到。
那天下午突然收到項目經理電話，說生產庫某個表被工程人員刪錯了數據了，希望能在測試環境對生產庫進行恢復。我當時第一感覺就是測試環境的空間不夠。生產庫表空間分配的空間一共是200g不到。但是使用的空間不到50g。當時我懷疑DB2的這個恢復應該是類似於oracle的rman恢復，直接進行物理恢復。直接將表空間恢復出來。因此需要200g左右的空間。
測試環境肯定是沒有這麼大的空間了，但是不完全肯定，嘗試做下恢復。有報錯，看了下，是說某個路徑沒有權限讀寫，仔細看了下，那個路徑是生產庫表空間文件存放的路徑。原來DB2恢復只能恢復在原路徑上。建立好相應的文件系統。再看還是有報錯，原來是日志的目錄不存在，再建文件系統，恢復。還報錯，這次是歸檔日志的目錄，再建，恢復。
- DB2 RESTORE db abc FROM /DB2/data/bk taken at 20100517000001
結果顯示，有部分表空間沒有恢復成功，但是整體DB2數據庫恢復是成功了。
將需要的歸檔日志拷貝到(/DB2/data/bk/log/)目錄，做前滾
- DB2 "rollforward db abc to end of logs and stop overflow log path(/DB2/data/bk/log/)"
報錯
- SQL1218N There are no pages currently available in bufferpool "".
覺得應該是恢復過程中出現問題，查看DB2的日志。日志太大，感覺不方便看，因此再做一次恢復，然後實時監控日志輸出。發現在恢復一些表空間的時候，一直抱一個disk full的錯誤。問題應該定位到，就是磁盤空間不夠。但是測試環境的磁盤空間是絕對不可能騰出200g出來。咋辦？
最後實在沒辦法，就在生產庫的磁陣上，建了一個200g的nfs給測試環境用，再進行DB2數據庫恢復。過程有報錯，是說表空間的使用率超過閥值，因為有些表空間的使用率是100%，不知道那些表空間是否有用的.......。
200g的恢復果然很花時間，用了差不多一個多小時。再做一次前滾，仍然報錯
- SQL1218N There are no pages currently available in bufferpool "".
奇了怪了！上網搜了下，也有人碰到一樣的問題。建議修改參數
- DB2set DB2_OVERRIDE_BPF=1000，
然後重啟DB2，
果然，能夠成功前滾，DB2也能成功登錄。
總結:
1.在進行DB2異地DB2數據庫恢復的時候，已經要先建好相應的目錄，數據文件目錄，日志目錄，歸檔日志目錄。
2.在操作失敗需要查看日志時候，盡量想辦法去看老日志，因為重新操作，再實時看日志，雖然比較明朗，但是需要花費更多的時間。
