如何進行DB2數(shù)據(jù)庫指定時間點恢復的分析

今天就跟大家聊聊有關如何進行DB2數(shù)據(jù)庫指定時間點恢復的分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

公司一生產(chǎn)環(huán)境AIX主機上的DB2數(shù)據(jù)庫，由于開發(fā)人員的誤操作，造成一個重要表的被刪除，需要進行恢復。為了安全，不能在生產(chǎn)環(huán)境的數(shù)據(jù)庫上進行操作，需要放到測試環(huán)境進行恢復。

問了一下開發(fā)人員，表被刪除的時間為5月31日下午8點30分左右，現(xiàn)在已是晚間10點50分了，距離事故發(fā)生時間點已過去兩個多小時，根據(jù)安全等級規(guī)定需要在一個小時內(nèi)進行恢復。這種狀況的恢復是典型的前滾恢復，需要使用完整的數(shù)據(jù)庫備份和日志相結(jié)合，然后將數(shù)據(jù)庫或者被選擇的表空間恢復到某個特定時間點。如果從備份時刻起到發(fā)生故障時的所有日志文件都可以獲得的話，則可以恢復到日志上涵蓋到的任意時間點。

首先檢查了一下數(shù)據(jù)庫的備份情況，上周日有一個完整備份，從完整備份到故障點的所有日志都完好的存在，心里總算松了一口氣。

接下來在測試環(huán)境找一臺與生產(chǎn)環(huán)境DB2數(shù)據(jù)庫版本一致的AIX小機，把完整數(shù)據(jù)庫備份和相應日志傳輸過來。（注：不同的數(shù)據(jù)庫版本，物理日志格式不一樣，在做恢復的時候容易報SQL2547錯誤，從而不能前滾日志）從生產(chǎn)環(huán)境傳輸?shù)綔y試環(huán)境的完整備份和日志，大家要注意修改文件的屬主和權限，以避免無法讀取的錯誤。

一、進行完整備份的恢復

使用SECURE CRT進入測試環(huán)境的AIX小機

$ db2 connect to banoab      (測試環(huán)境和生產(chǎn)環(huán)境的數(shù)據(jù)庫名是一樣的)

  Database Connection Information

Database server        = DB2/AIX64 9.1.7

SQL authorization ID   = DB2INST1

Local database alias   = BANOAB

$ db2 force applications all     （殺掉所有應用的連接）

DB20000I  The FORCE APPLICATION command completed successfully.

DB21024I  This command is asynchronous and may not be effective immediately.

$ db2 drop db banoab     (刪除測試環(huán)境的庫)

DB20000I  The DROP DATABASE command completed successfully.

（從生產(chǎn)庫存放的位置進行完整備份庫的還原）

$ db2 restore db banoab from /backup taken at 20130526190620 to /home/db2inst1

DB20000I  The RESTORE DATABASE command completed successfully.

二、前滾日志到指定時間點

$ db2 connect to banoab

SQL1117N  A connection to or activation of database "BANOAB" cannot be made

because of ROLL-FORWARD PENDING.  SQLSTATE=57019

連接還原后的庫，提示需要前滾日志，接下來將數(shù)據(jù)庫前滾至刪除前的那個時間點

/backup/logs為生產(chǎn)庫日志的存放目錄

$ db2 "rollforward db banoab to 2013-05-31-20.00.00.000000 using local time and complete overflow log path (/backup/logs)"

                                Rollforward Status

Input database alias                   = banoab

Number of nodes have returned status   = 1

Node number                            = 0

Rollforward status                     = not pending

Next log file to be read               =

Log files processed                    = S0001593.LOG - S0001683.LOG

Last committed transaction             = 2013-05-31-20.00.00.000000 Local

DB20000I  The ROLLFORWARD command completed successfully.

前滾日志成功，告知開發(fā)人員進行檢查

過了一會，開發(fā)人員反饋說沒有查到數(shù)據(jù)，仍然是刪除后的狀態(tài)。

這回有點納悶了，怎么可能會沒有，時間已過去了半個小時，真是讓人著急啊

心里有點懷疑，會不會是兩個小機的時間不一致啊，因為前滾時用的是local time

立即檢查兩個小機的時間

Sun Jun  4 15:43:47 BEIST 2013  （生產(chǎn)機時間）

Sun Jun  4 15:44:01 CDT 2013     （測試機時間）

注意紅色部分，BEIST和CDT并不是同一個時區(qū)，BEIST與CDT之間相差8個小時。因為時區(qū)的不一致導致時間不統(tǒng)一，所以出現(xiàn)了問題。

那么怎么把AIX的CDT時間顯示方法改為BEIST呢？方法如下

smitty => System Environments => Change / Show Date and Time

=> Change Time Zone Using User Inputted Values

然后修改成這樣：

Standard Time ID(only alpahabets)                  [BEIST]

* Standard Time Offset from CUT([+|-]HH:MM:SS)       [-8]

  Day Light Savings Time ID(only alpahabets)         []         --注意這里為空

然后再重新恢復一次

$ db2 force applications all

DB20000I  The FORCE APPLICATION command completed successfully.

DB21024I  This command is asynchronous and may not be effective immediately.

$ db2 drop db banoab

DB20000I  The DROP DATABASE command completed successfully.

$ db2 restore db banzub from /backup taken at 20130526190620 to /home/db2inst1

DB20000I  The RESTORE DATABASE command completed successfully.

$ id - db2inst

uid=301(db2inst1) gid=301(db2grp1) groups=1(staff)

$ db2 connect to banoab

SQL1117N  A connection to or activation of database "BANOAB" cannot be made

because of ROLL-FORWARD PENDING.  SQLSTATE=57019

$ db2 "rollforward db banoab to 2013-05-31-20.00.00.000000 using local time and complete overflow log path (/backup/logs)"

                                Rollforward Status

Input database alias                   = banoab

Number of nodes have returned status   = 1

Node number                            = 0

Rollforward status                     = not pending

Next log file to be read               =

Log files processed                    = S0001593.LOG - S0001679.LOG

Last committed transaction             = 2013-05-31-20.00.00.000000 Local

DB20000I  The ROLLFORWARD command completed successfully.

再檢查，果然數(shù)據(jù)有了，表也恢復了，一切OK

總結(jié)：做數(shù)據(jù)恢復時，一定要冷靜沉著，遇到問題要會分析，懂技術并分析到位才能力克困難。

附：DB2數(shù)據(jù)庫備份恢復的概念和知識點

備份類型：脫機備份（也稱冷備份或離線備份）、聯(lián)機備份（也稱熱備份或在線備份）、完全備份、增量備份（也稱累積備份）、差異備份

數(shù)據(jù)庫備份文件結(jié)構(gòu)

恢復類型：崩潰恢復、版本恢復、前滾恢復（任意時間點恢復，恢復到最近時間點）

恢復情形：完全恢復、不完全恢復

手動恢復數(shù)據(jù)庫的順序

日志類型：循環(huán)日志（默認）、歸檔日志（活動日志、在線歸檔日志、離線歸檔日志）

日志類型與恢復類型：循環(huán)日志只支持崩潰恢復和版本恢復，歸檔日志支持所有類型的恢復

凡是聯(lián)機備份產(chǎn)生的備份集在恢復時都需要使用歸檔日志，歸檔日志方式是是允許用戶執(zhí)行前滾（rollforward）恢復的唯一方法。

前滾的時間要在最小恢復時間點之后，最后的事務提交時間點之前。

看完上述內(nèi)容，你們對如何進行DB2數(shù)據(jù)庫指定時間點恢復的分析有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注億速云行業(yè)資訊頻道，感謝大家的支持。