數(shù)據(jù)庫日志

DB2 數(shù)據(jù)庫支持兩種不同的日志模式：循環(huán)(Circular)和歸檔(Archival)。當(dāng)新數(shù)據(jù)庫創(chuàng)建時，系統(tǒng)默認(rèn)的日志模式為循環(huán)。如果業(yè)務(wù)需求要求更高級的功能，您可以將日志模式從循環(huán)修改為歸檔。

DB2 事務(wù)日志摘要

事務(wù)是邏輯工作單元。每一個事務(wù)在事務(wù)日記文件中都存儲有相應(yīng)的日志記錄。每個事務(wù)都有一個相應(yīng)的 Redo Log 條目。Redo Log 條目將寫入當(dāng)前的活動日志文件。當(dāng)活動日志文件變滿時，它將被標(biāo)記為 unavailable。此時，DB2 將接著此活動日志文件另外創(chuàng)建一個日志文件，并繼續(xù)在其中寫入日志條目。當(dāng)前活動日志文件變滿時，DB2 將重復(fù)這一循環(huán)過程。當(dāng)事務(wù)完成后(發(fā)起 COMMIT 或 ROLLBACK 語句)，相應(yīng)的日志條目將被釋放，因為不再需要將它們用于恢復(fù)數(shù)據(jù)庫。

DB2 將一直嘗試將日志條目寫入主要日志文件集，也就是數(shù)據(jù)庫活動時間自動分配的日志文件。如果某個事務(wù)將所有主要日志文件消耗怠盡(所有主要日志文件都被標(biāo)記為 unavailable)，則數(shù)據(jù)庫管理員將分配一個次要日志文件。當(dāng)這個文件變滿時，數(shù)據(jù)庫管理員將再次檢查主要日志文件的狀態(tài)是否為 unavailable。如果是，則再分配一個次要日志文件并繼續(xù)在其中寫入條目。該過程將不斷重復(fù)，直到所有次要日志文件都分配并寫滿。如果沒有主要日志文件可供寫入 Redo 條目，并且已經(jīng)分配最大數(shù)量的次要日志文件，則應(yīng)用程序?qū)⑹盏揭韵洛e誤消息：

SQL0964C The transaction log for the database is full.

希望您曾經(jīng)遇到過這種錯誤。但是，如果遇到此錯誤，則應(yīng)該根據(jù)需要增加主要和次要日志文件(或者它們的大小)的數(shù)量。在理想情況下，主要日志文件的數(shù)量或大小應(yīng)該足夠保存最大的事務(wù)。分配次要日志文件相當(dāng)消耗資源，因為它將在運(yùn)行時執(zhí)行。因此，我們應(yīng)該將需要在高峰工作負(fù)荷期間分配的次要日志文件數(shù)量降到最低。要更新主要或次要日志文件的數(shù)量，可以發(fā)起以下命令：

UPDATE DB CFG FOR db_name USING LOGPRIMARY value

UPDATE DB CFG FOR db_name USING LOGSECOND value

注意：如果出現(xiàn)此問題，則應(yīng)該分析造成整個日志文件空間變滿的原因是什么。它可能是由失控查詢或用戶錯誤造成的，因此增加日志文件的數(shù)量或大小只能在表面上解決問題。比如說，假設(shè)某個用戶發(fā)起了一個 DELETE FROM tab1 語句，且 TAB1 是一個相當(dāng)大的表。雖然這一語句看上去沒什么問題，每行生成一條刪除日記記錄，但是如果未經(jīng)過配置處理它可以輕易地將日志空間填滿。

循環(huán)日志

當(dāng)循環(huán)日志生效時，事務(wù)數(shù)據(jù)將通過循環(huán)的方式寫入主要日志文件。當(dāng)存儲于某個日志文件中的所有記錄都不再需要用于恢復(fù)時，該日志文件將被重用，并且可以在以后再次成為活動日志文件。這意味著在循環(huán)日志模式中，日志文件的內(nèi)容最終將被新日志條目重寫。由于日志文件的內(nèi)容被重寫覆蓋了，因此我們只能將數(shù)據(jù)庫恢復(fù)到最后一次完整的數(shù)據(jù)庫備份。不能使用循環(huán)日志執(zhí)行時間點(point-in-time)恢復(fù)。

歸檔日志

在歸檔日志模式中，redo log 條目將寫入主要日志文件。但是，與循環(huán)日志不同，這些日志文件永遠(yuǎn)都不可重用。當(dāng)存儲于某個日志文件中的所有記錄都不再需要用于恢復(fù)時，該日志文件將被標(biāo)記為非活動 而不是可重用。這意味著它的內(nèi)容永遠(yuǎn)都不會被覆蓋。當(dāng)?shù)谝粋€主要日志文件變滿時，系統(tǒng)將分配一個新的日志文件，這樣主要日志文件的配置數(shù)量(LOGPRIMARY 數(shù)據(jù)庫參數(shù))將一直可用。

與單個事務(wù)相關(guān)的所有條目必須在活動日志空間中保持一致。如果長時間運(yùn)行的事務(wù)所需要的日志空間大于主要日志文件可以提供的空間，則可能會分配并使用次要日志文件。在歸檔日志模式中，通過結(jié)合使用數(shù)據(jù)庫備份映像和日志文件，我們可以將數(shù)據(jù)庫恢復(fù)到具體的時間點。有關(guān)此流程的詳細(xì)描述請參見下文。

如何修改日志模式

創(chuàng)建新的 DB2 數(shù)據(jù)庫時，默認(rèn)的日志模式為循環(huán)日志 。如果希望將日志模式從循環(huán)修改為歸檔，可以執(zhí)行以下步驟：

在磁盤上創(chuàng)建一個文件夾(比如說 e:db_namearchive)，磁盤上必須有足夠的空間存儲歸檔日志文件。保證歸檔文件目標(biāo)文件夾與活動日志文件目標(biāo)文件夾分開。

終止與數(shù)據(jù)庫的連接：

TERMINATE

更新歸檔日志文件目標(biāo)文件夾(為歸檔日志文件指定路徑可以將歸檔日志模式打開)。

UPDATE DB CFG FOR db_name USING LOGARCHMETH1 'Disk:e:db_namearchive'

重新連接到數(shù)據(jù)庫：

CONNECT TO db_name

連接失敗并顯示以下錯誤消息：

SQL1116N A connection to or activation of database db_name cannot be made because of backup pending: SQLSTATE=57019

出現(xiàn)錯誤消息的原因是，日志模式已經(jīng)從循環(huán)更改為歸檔，并且需要執(zhí)行完全數(shù)據(jù)庫備份。數(shù)據(jù)庫處于循環(huán)日志模式時執(zhí)行的備份并不充分，因此當(dāng)切換模式后需要執(zhí)行新備份。

使用以下命令執(zhí)行完全數(shù)據(jù)庫備份：

BACKUP DATABASE db_name TO d:db_namebackup

嘗試再次連接到數(shù)據(jù)庫。這次應(yīng)該能夠成功。

CONNECT TO db_name恢復(fù)場景

理解故障出現(xiàn)的原因以及如何從故障中恢復(fù)是非常重要的。以下部分將模擬各種不同的故障類型，并介紹如何從故障中恢復(fù)系統(tǒng)。

場景 1. 整個數(shù)據(jù)庫意外刪除和損壞

本場景將展示如何從完全數(shù)據(jù)庫故障中恢復(fù)。遇到這種情況的原因可以是數(shù)據(jù)庫意外刪除或受到破壞，也可以是人為錯誤或硬件故障造成的不一致性。在這些情況中，可以通過應(yīng)用上次完全數(shù)據(jù)庫備份對數(shù)據(jù)庫進(jìn)行恢復(fù)。該場景基于 表 1 中的配置。

表 1. 恢復(fù)場景中所使用的配置組件描述操作系統(tǒng)Windows XP Service Pack 2 / RHEL 4.0DB2 版本和等級DB2 UDB Enterprise Server Edition (ESE) V8.2.6 fixpak 13 / DB2 V9.1 ESE fixpak 1數(shù)據(jù)庫名稱TESTDB1步驟 1. 執(zhí)行完全數(shù)據(jù)庫備份

要執(zhí)行完全脫機(jī)數(shù)據(jù)庫備份，可以使用以下命令：

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TO c:testdb1backup

需要注意備份文件名稱中生成的 ID。它類似于：20060411154219。這個 ID 只是備份映像的時間戳，恢復(fù)過程中需要使用它。

步驟 2. 模擬故障

要模擬故障場景，可以完全刪除數(shù)據(jù)庫：

TERMINATE

FORCE APPLICATION ALL

DROP DATABASE testdb1

現(xiàn)在，嘗試連接數(shù)據(jù)庫：

CONNECT TO testdb1

將報告以下錯誤，它提示找不到此數(shù)據(jù)庫：

Error: SQL1013N Database alias name or Database name 'testdb1' could not found.

步驟 3. 創(chuàng)建一個新的數(shù)據(jù)庫

要開始恢復(fù)過程，首先創(chuàng)建一個與丟棄數(shù)據(jù)庫名稱相同的數(shù)據(jù)庫：

CREATE DATABASE testdb1

查看數(shù)據(jù)庫目錄的內(nèi)容，確保數(shù)據(jù)庫創(chuàng)建成功且目錄正確：

LIST DB DIRECTORY

步驟 4. 恢復(fù)數(shù)據(jù)庫

恢復(fù)數(shù)據(jù)庫備份映像。在本例中，我使用時間戳 20060411154219 恢復(fù)備份映像：

RESTORE DATABASE testdb1 FROM c:testdb1backup TAKEN AT 20060411154219 INTO testdb1

將返回以下報警消息

SQL2523W: Restoring to an existing database that is different from the database on the backup image. The target database will be overwritten by the backup version. The roll-forward recovery logs associated with the target database will be overwritten.

按 Y 鍵繼續(xù)運(yùn)行。該操作將把數(shù)據(jù)庫備份恢復(fù)到前一步驟中創(chuàng)建的數(shù)據(jù)庫。成功恢復(fù)映像之后，數(shù)據(jù)庫將與備份時的數(shù)據(jù)庫完全一致。

步驟 5. 連接到數(shù)據(jù)庫

嘗試連接到數(shù)據(jù)庫：

CONNECT TO testdb1

可能會返回以下錯誤消息：

SQL1117N A connection to or activation of database 'testdb1' cannot be made because of Roll-Forward Pending SQLSTATE=57019.

出現(xiàn)錯誤的原因可能是，必須使用某些日志文件進(jìn)行一致性檢查。使用以下命令將數(shù)據(jù)庫恢復(fù)到一致狀態(tài)：

ROLLFORWARD DATABASE testdb1 COMPLETE

再次嘗試連接到數(shù)據(jù)庫：

CONNECT TO testdb1

步驟 6. 數(shù)據(jù)庫和對象驗證

驗證之前的對象仍然存在且可用，比如說：

LIST TABLESPACES SHOW DETAIL

LIST TABLES

上一條命令應(yīng)該會提示，所有表空間均處于正常狀態(tài)并且可以訪問容器。所有表及表中的數(shù)據(jù)集合應(yīng)該與執(zhí)行備份時的狀態(tài)一致。

場景 2. 表空間容器意外丟棄或損壞的表空間容器

本場景將展示當(dāng)一個或多個表空間容器丟失或損壞時如何恢復(fù)數(shù)據(jù)庫系統(tǒng)。出現(xiàn)此情況的原因可以是人為錯誤(比如說，某個用戶刪除了某個目錄或文件)或數(shù)據(jù)文件損壞問題。本場景基于 表 2 中的配置。

表 2. 場景 2 中所使用的系統(tǒng)配置組件描述操作系統(tǒng)Windows XP Service Pack 2 / RHEL 4.0DB2 版本和等級DB2 UDB Enterprise Server Edition (ESE) V8.2.6 fixpak 13 / DB2 V9.1 ESE fixpak 1數(shù)據(jù)庫名稱TESTDB1表空間名稱TS1TS1 中的容器c1.dat, c2.dat, c3.dat, c4.dat步驟 1. 獲取定義的所有表空間的目錄

CONNECT TO testdb1

LIST TABLESPACES SHOW DETAIL

步驟 2. 獲取所有表空間容器信息的目錄

LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL

注意：上面命令中的 “1” 是本環(huán)境中表空間 TS1 的表空間 ID。它是通過之前 LIST TABLESPACES SHOW DETAIL 命令中的輸出獲得的。所使用的每個表空間 ID 都需要重復(fù)這個命令。

步驟 3. 備份表空間

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TABLESPACE ts1 TO c:testdb1backupts1

如您所見。本場景假定用戶對大多數(shù)重要的表空間都執(zhí)行了備份(供恢復(fù)使用)。

步驟 4. 模擬表空間故障

手動模擬此場景，即表空間容器文件被某個用戶意外刪除：

DEL C:TESTDB1TS1C1.DAT

DEL C:TESTDB1TS1C2.DAT

DEL C:TESTDB1TS1C3.DAT

隨后，當(dāng)我們連接到數(shù)據(jù)庫并嘗試執(zhí)行與表空間 TS1 相關(guān)的操作時，將返回錯誤。比如說：

CONNECT TO testdb1

CREATE TABLE tab1(c1 INTEGER) IN ts1

返回以下錯誤消息：

SQL0290N Table space access is not allowed.

還可以使用以下命令檢查表空間狀態(tài)：

LIST TABLESPACES SHOW DETAIL

刪除容器后，上面的命令將顯示 TS1 的狀態(tài)為 0x400 ，該代碼表示脫機(jī)且不可訪問狀態(tài)。由于刪除了三個容器，因此表空間不再處于正常狀態(tài)(0x000)。

如果再次執(zhí)行 LIST TABLESPACE CONTAINERS 命令，可以驗證哪些容器丟失或不可用：

LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL

在結(jié)果中，容器 C1、C2 和 C3 的 Accessible 狀態(tài)將顯示為 No。

步驟 6. 恢復(fù)表空間備份映像

要恢復(fù)備份映像，可以使用以下命令：

TERMINATE

RESTORE DATABASE testdb1 TABLESPACE (ts1) FROM C:TESTDB1BACKUPTS1

步驟 7. 檢查表空間狀態(tài)

確保容器可以訪問：

LIST TABLESPACES SHOW DETAIL

LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL

如果恢復(fù)成功，表空間 TS1 的狀態(tài)應(yīng)該為正常(0x000)并且所有容器應(yīng)該都可以訪問。

步驟 8. 驗證恢復(fù)是否成功

CREATE TABLE tab1(no INTEGER) IN ts1

注意：您可能會遇到以下這種情況：恢復(fù)表空間之后仍然需要進(jìn)一步恢復(fù)操作。如果有任何日志文件修改未被應(yīng)用(以確保數(shù)據(jù)庫的一致性)，都有可能出現(xiàn)這種情況。在這種情況下，使用以下任一命令完成恢復(fù)：

ROLLFORWARD DATABASE testdb1 COMPLETE

OR

ROLLFORWARD DATABASE testdb1 TO END OF LOGS AND STOP

以上命令將應(yīng)用所有剩余的日志文件，從而將數(shù)據(jù)庫恢復(fù)到一致狀態(tài)。

場景 3. 某個表意外丟失

對于含有上千個表的數(shù)據(jù)庫環(huán)境，難免會錯誤地丟棄某個表。在本場景中，您將看到如何恢復(fù)意外丟棄的表。要執(zhí)行這種類型的恢復(fù)，必須將數(shù)據(jù)庫配置為歸檔日志模式，并且可以使用完全數(shù)據(jù)庫備份映像。要對丟棄的表執(zhí)行恢復(fù)操作，表所在的表空間必須將 DROPPED TABLE RECOVERY 選項打開。可以在創(chuàng)建表空間的過程中設(shè)置此選項，也可以直接調(diào)用 ALTER TABLESPACE 語句。DROPPED TABLE RECOVERY 選項特定于表空間且局限于常規(guī)表空間。

本場景基于 表 3 中的系統(tǒng)配置。

表 3. 場景 3 中所使用的系統(tǒng)配置組件描述操作系統(tǒng)Windows XP Service Pack 2 / RHEL 4.0DB2 版本和等級DB2 UDB Enterprise Server Edition (ESE) 8.2.6 fixpak 13 / DB2 9.1 ESE fixpak 1數(shù)據(jù)庫名稱TESTDB1表空間名稱TS1表名稱TAB1步驟 1. 執(zhí)行完全數(shù)據(jù)庫備份

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TO c:testdb1backup

需要注意備份映像的時間戳。

步驟 2. 連接到數(shù)據(jù)庫并執(zhí)行生成日志記錄的操作

CONNECT TO testdb1

CREATE TABLE tab1(no INTEGER) IN ts1

TERMINATE

ARCHIVE LOG FOR DATABASE testdb1

CONNECT TO testdb1

INSERT INTO tab1 VALUES(1)

INSERT INTO tab1 VALUES(2)

INSERT INTO tab1 VALUES(3)

COMMIT

TERMINATE

ARCHIVE LOG FOR DATABASE testdb1

CONNECT TO testdb1

INSERT INTO tab1 VALUES(4)

INSERT INTO tab1 VALUES(5)

COMMIT

TERMINATE

ARCHIVE LOG FOR DATABASE testdb1

CONNECT TO testdb1

SELECT * FROM tab1 /* check the 5 committed values from TAB */

步驟 3. 模擬意外丟棄表的場景

DROP TABLE tab1

COMMIT

SELECT * FROM tab1

將返回以下錯誤消息：

Error: SQL0204N 'Administrator.TAB1' is an undefined name

步驟 4. 恢復(fù)數(shù)據(jù)庫

要恢復(fù)已被丟棄的表，先恢復(fù)數(shù)據(jù)庫備份，然后執(zhí)行向前恢復(fù)(rollforward)操作：

TERMINATE

FORCE APPLICATION ALL

RESTORE DATABASE testdb1 FROM c:testdb1backup TAKEN AT 20070314144204 INTO testdb1

將返回以下消息：

SQL2539W Warning! Restoring to an existing database that is the same as the Backup image database.

The database files will be deleted.

Do you want to continue? (Y/N)

按 Y 鍵完成此過程。

步驟 5. 檢索已丟棄表的對象 ID

使用以下命令檢索意外丟棄的表的對象 ID：

LIST HISTORY DROPPED TABLE ALL FOR DATABASE testdb1

可以將返回的信息(比如說 清單 1 中顯示的示例)復(fù)制到某個文本文件中以供未來引用。

清單 1. LIST HISTORY 命令返回的信息

Op Obi Timestamp Sequence Type Dev Earliest Log Current Log; Backup ID-- --- ------------------ ---- --- ------------ ------------ -----------------------------D; T; 20070314142913;;;;;;000000000000892700050108------------------------------------------------------------------------------------------'ADMINISTRATOR'.'TAB1' resides in 1 table space(s):00001 TS1----------------------------------------------------------------------------Comment: DROP TABLEStart Time: 20070314142913End Time: 20070314142913Status: A----------------------------------------------------------------------------EID: 37DDL: CREATE TABLE 'ADMINISTRATOR'.'TAB1' ( 'NO' INTEGER ); IN 'TS1' ;清單 1 中的 Backup ID 欄顯示被丟棄表的 ID 為 000000000000892700050108。這一信息對于恢復(fù)表非常重要。

步驟 6. 向前恢復(fù)數(shù)據(jù)庫

現(xiàn)在已經(jīng)獲得了被丟棄表的 ID，下一步需要使用該表的備份 ID RB 數(shù)據(jù)庫，這樣才能夠?qū)氡淼臄?shù)據(jù)。在向前恢復(fù)數(shù)據(jù)庫之前，需要確保有一個目錄可供存儲導(dǎo)入數(shù)據(jù)，比如說 c:testdb1exporttab1。使用以下命令向前恢復(fù)數(shù)據(jù)庫：

ROLLFORWARD DATABASE testdb1 TO END OF LOGS

AND STOP RECOVER DROPPED TABLE 000000000000892700050108 TO c:testdb1exporttab1

使用 END OF LOGS 選項的作用是讓 DB2 在執(zhí)行備份操作后應(yīng)用所有可用日記文件。

步驟 7. 檢查導(dǎo)入的數(shù)據(jù)文件

完成數(shù)據(jù)庫向前恢復(fù)之后，需要檢查在 ROLLFORWARD 命令中指定路徑。應(yīng)該能夠找到一個 .TXT 文件，打開該文件并驗證其中包含的數(shù)據(jù)與意外丟棄表之前的數(shù)據(jù)相同。

步驟 8. 連接到數(shù)據(jù)庫并重新創(chuàng)建被丟棄的表

驗證導(dǎo)出文件之后，我們需要重新創(chuàng)建被丟棄的表并重新填入數(shù)據(jù)。被丟棄表的定義包含在步驟 5 的 LIST HISTORY 命令的輸出中。連接到數(shù)據(jù)庫并執(zhí)行 CREATE TABLE 語句：

CONNECT TO testdb1CREATE TABLE 'ADMINISTRATOR'.'TAB1' ( 'NO' INTEGER ) IN 'TS1'

步驟 9. 導(dǎo)入數(shù)據(jù)

重新創(chuàng)建表之后，可以使用以下命令將數(shù)據(jù)庫重新導(dǎo)入到表中：

IMPORT FROM c:testdb1exporttab1Node0000data.txt OF DEL INSERT INTO administrator.tab1

IMPORT 工具將導(dǎo)出文件中的所有數(shù)據(jù)導(dǎo)回到表中并在成功后發(fā)送報告(未顯示)。

步驟 10. 驗證恢復(fù)后的數(shù)據(jù)

確保 IMPORT 過程中沒有錯誤或報警，并且所有數(shù)據(jù)都已導(dǎo)回表中：

SELECT * FROM tab1

如果一切運(yùn)行正常，則意外丟棄點之前的所有數(shù)據(jù)應(yīng)該都在表中。

場景 4. 恢復(fù)到時間點

如果某個表空間被丟棄或受到破壞，則定義在其中的表及數(shù)據(jù)將不可訪問。要從此場景中恢復(fù)系統(tǒng)，需要一個可用的完全數(shù)據(jù)庫備份映像并且需要將數(shù)據(jù)庫配置為歸檔日志模式。本場景基于 表 4 中的系統(tǒng)配置。

表 4. 場景 4 中所使用的系統(tǒng)配置組件描述操作系統(tǒng)Windows XP Service Pack 2 / RHEL 4.0DB2 版本和等級DB2 UDB Enterprise Server Edition (ESE) 8.2.6 fixpak 13 / DB2 9.1 ESE fixpak 1數(shù)據(jù)庫名稱TESTDB1表空間名稱TS1表空間TAB1步驟 1. 執(zhí)行完全數(shù)據(jù)庫備份

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TO c:testdb1backup

務(wù)必記錄下備份映像文件接收到的時間戳，因為恢復(fù)過程需要使用它。

步驟 2. 創(chuàng)建一個新的表空間

創(chuàng)建一個新的表空間 TS1，以供本恢復(fù)場景使用：

CREATE TABLESPACE TS1 MANAGED BY DATABASE USING (FILE 'c:testdb1s4C1.dat' 1000 )

EXTENTSIZE 8 PREFETCHSIZE 24

確認(rèn)表空間和相關(guān)容器都已創(chuàng)建：

LIST TABLESPACES

LIST TABLESPACE CONTAINERS FOR n SHOW DETAIL

其中，n 是 LIST TABLESPACES 輸出中顯示的表空間 ID。

步驟 3. 創(chuàng)建一個表并對它執(zhí)行一些操作

創(chuàng)建表空間之后，創(chuàng)建一個名為 TAB1 的表并將它放到表空間中。在表中插入一些數(shù)據(jù)。為了讓此場景更接近現(xiàn)實，使用一些命令強(qiáng)制 DB2 打開歸檔文件：

步驟 4. 模擬表空間故障

要在此場景中模擬一個故障，需丟棄表空間：

DROP TABLESPACE ts1SELECT * FROM tab1

將返回以下錯誤消息：

SQL0204N Error table does not exist 'Administrator.Tab1' is an Undefined Name.

步驟 5. 恢復(fù)數(shù)據(jù)庫

丟棄表空間之后，這個表空間的所有內(nèi)容也被丟棄。要恢復(fù)表空間，恢復(fù)上一次可用備份映像：

在執(zhí)行 RESTORE 命令時，需要使用在步驟 1 中記錄的備份時間戳。將接收到以下報警消息：

SQL 2539W Warning! Restoring to an existing database that is same as the backup image database.

The database files will be deleted.

Do you want to continue? (Y/N)

按 Y 鍵繼續(xù)執(zhí)行。

步驟 6. 向前恢復(fù)數(shù)據(jù)庫

恢復(fù)數(shù)據(jù)庫之后，嘗試連接到數(shù)據(jù)庫：

CONNECT TO testdb1

將返回以下消息：

SQL 111N A connection to or activation of database cannot be made because of Roll-forward Pending. SQLSTATE=57019

在 RB 數(shù)據(jù)庫之后，我們需要計算出丟棄表空間的時間戳。為此，使用 LIST HISTORY 命令：

LIST HISTORY CREATE TABLESPACE ALL FOR DATABASE testdb1

我們可以看到被丟棄表空間的準(zhǔn)確時間戳。但是，不應(yīng)該使用這個時間戳，因為需要使用在它之前的時間戳值恢復(fù)最近一次提交的值。

本示例將使用 20070315151500 作為時間戳來進(jìn)行恢復(fù)。需要將該數(shù)據(jù)格式化為 ROLLFORWARD 工具可識別的形式，即 2007-03-15.15.15.00

ROLLFORWARD DATABASE testdb1 TO 2007-03-15.15.15.00 USING LOCAL TIME AND STOP

DB2 將應(yīng)用指定時間戳之前的所有日志，并恢復(fù)數(shù)據(jù)庫的表空間。

步驟 7. 驗證已恢復(fù)的表空間和表

CONNECT TO testdb1

LIST TABLESPACES SHOW DETAIL

SELECT * FROM tab1

以上命令的結(jié)果允許我們確認(rèn)表空間和表是否已恢復(fù)到指定的時間點。

結(jié)束語

本文介紹了可以在 DB2 中執(zhí)行各種不同的日志。文章還演示了一些關(guān)鍵的恢復(fù)場景，并提供了從各類故障恢復(fù)系統(tǒng)的詳細(xì)步驟。

對于任務(wù)關(guān)鍵型數(shù)據(jù)庫，理解備份恢復(fù)的流程和意外故障的計劃非常重要。同時，強(qiáng)烈建議將經(jīng)過測試的備份和恢復(fù)計劃應(yīng)用到實踐中。