數據庫日志

DB2 數據庫支持兩種不同的日志模式：循環(Circular)和歸檔(Archival)。當新數據庫創建時，系統默認的日志模式為循環。如果業務需求要求更高級的功能，您可以將日志模式從循環修改為歸檔。

DB2 事務日志摘要

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

DB2 將一直嘗試將日志條目寫入主要日志文件集，也就是數據庫活動時間自動分配的日志文件。如果某個事務將所有主要日志文件消耗怠盡(所有主要日志文件都被標記為 unavailable)，則數據庫管理員將分配一個次要日志文件。當這個文件變滿時，數據庫管理員將再次檢查主要日志文件的狀態是否為 unavailable。如果是，則再分配一個次要日志文件并繼續在其中寫入條目。該過程將不斷重復，直到所有次要日志文件都分配并寫滿。如果沒有主要日志文件可供寫入 Redo 條目，并且已經分配最大數量的次要日志文件，則應用程序將收到以下錯誤消息：

SQL0964C The transaction log for the database is full.

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

UPDATE DB CFG FOR db_name USING LOGPRIMARY value

UPDATE DB CFG FOR db_name USING LOGSECOND value

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

循環日志

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

歸檔日志

在歸檔日志模式中，redo log 條目將寫入主要日志文件。但是，與循環日志不同，這些日志文件永遠都不可重用。當存儲于某個日志文件中的所有記錄都不再需要用于恢復時，該日志文件將被標記為非活動 而不是可重用。這意味著它的內容永遠都不會被覆蓋。當第一個主要日志文件變滿時，系統將分配一個新的日志文件，這樣主要日志文件的配置數量(LOGPRIMARY 數據庫參數)將一直可用。

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

如何修改日志模式

創建新的 DB2 數據庫時，默認的日志模式為循環日志 。如果希望將日志模式從循環修改為歸檔，可以執行以下步驟：

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

終止與數據庫的連接：

TERMINATE

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

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

重新連接到數據庫：

CONNECT TO db_name

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

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

出現錯誤消息的原因是，日志模式已經從循環更改為歸檔，并且需要執行完全數據庫備份。數據庫處于循環日志模式時執行的備份并不充分，因此當切換模式后需要執行新備份。

使用以下命令執行完全數據庫備份：

BACKUP DATABASE db_name TO d:db_namebackup

嘗試再次連接到數據庫。這次應該能夠成功。

CONNECT TO db_name恢復場景

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

場景 1. 整個數據庫意外刪除和損壞

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

表 1. 恢復場景中所使用的配置組件描述操作系統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數據庫名稱TESTDB1步驟 1. 執行完全數據庫備份

要執行完全脫機數據庫備份，可以使用以下命令：

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TO c:testdb1backup

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

步驟 2. 模擬故障

要模擬故障場景，可以完全刪除數據庫：

TERMINATE

FORCE APPLICATION ALL

DROP DATABASE testdb1

現在，嘗試連接數據庫：

CONNECT TO testdb1

將報告以下錯誤，它提示找不到此數據庫：

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

步驟 3. 創建一個新的數據庫

要開始恢復過程，首先創建一個與丟棄數據庫名稱相同的數據庫：

CREATE DATABASE testdb1

查看數據庫目錄的內容，確保數據庫創建成功且目錄正確：

LIST DB DIRECTORY

步驟 4. 恢復數據庫

恢復數據庫備份映像。在本例中，我使用時間戳 20060411154219 恢復備份映像：

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 鍵繼續運行。該操作將把數據庫備份恢復到前一步驟中創建的數據庫。成功恢復映像之后，數據庫將與備份時的數據庫完全一致。

步驟 5. 連接到數據庫

嘗試連接到數據庫：

CONNECT TO testdb1

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

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

出現錯誤的原因可能是，必須使用某些日志文件進行一致性檢查。使用以下命令將數據庫恢復到一致狀態：

ROLLFORWARD DATABASE testdb1 COMPLETE

再次嘗試連接到數據庫：

CONNECT TO testdb1

步驟 6. 數據庫和對象驗證

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

LIST TABLESPACES SHOW DETAIL

LIST TABLES

上一條命令應該會提示，所有表空間均處于正常狀態并且可以訪問容器。所有表及表中的數據集合應該與執行備份時的狀態一致。

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

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

表 2. 場景 2 中所使用的系統配置組件描述操作系統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數據庫名稱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” 是本環境中表空間 TS1 的表空間 ID。它是通過之前 LIST TABLESPACES SHOW DETAIL 命令中的輸出獲得的。所使用的每個表空間 ID 都需要重復這個命令。

步驟 3. 備份表空間

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TABLESPACE ts1 TO c:testdb1backupts1

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

步驟 4. 模擬表空間故障

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

DEL C:TESTDB1TS1C1.DAT

DEL C:TESTDB1TS1C2.DAT

DEL C:TESTDB1TS1C3.DAT

隨后，當我們連接到數據庫并嘗試執行與表空間 TS1 相關的操作時，將返回錯誤。比如說：

CONNECT TO testdb1

CREATE TABLE tab1(c1 INTEGER) IN ts1

返回以下錯誤消息：

SQL0290N Table space access is not allowed.

還可以使用以下命令檢查表空間狀態：

LIST TABLESPACES SHOW DETAIL

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

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

LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL

在結果中，容器 C1、C2 和 C3 的 Accessible 狀態將顯示為 No。

步驟 6. 恢復表空間備份映像

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

TERMINATE

RESTORE DATABASE testdb1 TABLESPACE (ts1) FROM C:TESTDB1BACKUPTS1

步驟 7. 檢查表空間狀態

確保容器可以訪問：

LIST TABLESPACES SHOW DETAIL

LIST TABLESPACE CONTAINERS FOR 1 SHOW DETAIL

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

步驟 8. 驗證恢復是否成功

CREATE TABLE tab1(no INTEGER) IN ts1

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

ROLLFORWARD DATABASE testdb1 COMPLETE

OR

ROLLFORWARD DATABASE testdb1 TO END OF LOGS AND STOP

以上命令將應用所有剩余的日志文件，從而將數據庫恢復到一致狀態。

場景 3. 某個表意外丟失

對于含有上千個表的數據庫環境，難免會錯誤地丟棄某個表。在本場景中，您將看到如何恢復意外丟棄的表。要執行這種類型的恢復，必須將數據庫配置為歸檔日志模式，并且可以使用完全數據庫備份映像。要對丟棄的表執行恢復操作，表所在的表空間必須將 DROPPED TABLE RECOVERY 選項打開?？梢栽趧摻ū砜臻g的過程中設置此選項，也可以直接調用 ALTER TABLESPACE 語句。DROPPED TABLE RECOVERY 選項特定于表空間且局限于常規表空間。

本場景基于 表 3 中的系統配置。

表 3. 場景 3 中所使用的系統配置組件描述操作系統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數據庫名稱TESTDB1表空間名稱TS1表名稱TAB1步驟 1. 執行完全數據庫備份

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TO c:testdb1backup

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

步驟 2. 連接到數據庫并執行生成日志記錄的操作

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. 恢復數據庫

要恢復已被丟棄的表，先恢復數據庫備份，然后執行向前恢復(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 中顯示的示例)復制到某個文本文件中以供未來引用。

清單 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。這一信息對于恢復表非常重要。

步驟 6. 向前恢復數據庫

現在已經獲得了被丟棄表的 ID，下一步需要使用該表的備份 ID RB 數據庫，這樣才能夠導入表的數據。在向前恢復數據庫之前，需要確保有一個目錄可供存儲導入數據，比如說 c:testdb1exporttab1。使用以下命令向前恢復數據庫：

ROLLFORWARD DATABASE testdb1 TO END OF LOGS

AND STOP RECOVER DROPPED TABLE 000000000000892700050108 TO c:testdb1exporttab1

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

步驟 7. 檢查導入的數據文件

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

步驟 8. 連接到數據庫并重新創建被丟棄的表

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

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

步驟 9. 導入數據

重新創建表之后，可以使用以下命令將數據庫重新導入到表中：

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

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

步驟 10. 驗證恢復后的數據

確保 IMPORT 過程中沒有錯誤或報警，并且所有數據都已導回表中：

SELECT * FROM tab1

如果一切運行正常，則意外丟棄點之前的所有數據應該都在表中。

場景 4. 恢復到時間點

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

表 4. 場景 4 中所使用的系統配置組件描述操作系統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數據庫名稱TESTDB1表空間名稱TS1表空間TAB1步驟 1. 執行完全數據庫備份

TERMINATE

FORCE APPLICATION ALL

BACKUP DATABASE testdb1 TO c:testdb1backup

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

步驟 2. 創建一個新的表空間

創建一個新的表空間 TS1，以供本恢復場景使用：

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

EXTENTSIZE 8 PREFETCHSIZE 24

確認表空間和相關容器都已創建：

LIST TABLESPACES

LIST TABLESPACE CONTAINERS FOR n SHOW DETAIL

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

步驟 3. 創建一個表并對它執行一些操作

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

CREATE TABLE tab1 (no INTEGER) IN TS1 INSERT INTO tab1 VALUES(1) INSERT INTO tab1 VALUES(2) COMMIT TERMINATE ARCHIVE LOG FOR DATABASE testdb1 CONNECT TO testdb1 INSERT INTO tab1 VALUES(3) INSERT INTO tab1 VALUES(4) INSERT INTO tab1 VALUES(5) COMMIT SELECT * FROM tab1 TERMINATE ARCHIVE LOG FOR DATABASE testdb1 CONNECT TO testdb1

步驟 4. 模擬表空間故障

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

DROP TABLESPACE ts1SELECT * FROM tab1

將返回以下錯誤消息：

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

步驟 5. 恢復數據庫

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

TERMINATE RESTORE DATABASE testdb1 FROM c:testdb1backup TAKEN AT 20070315150901 INTO testdb1

在執行 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 鍵繼續執行。

步驟 6. 向前恢復數據庫

恢復數據庫之后，嘗試連接到數據庫：

CONNECT TO testdb1

將返回以下消息：

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

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

LIST HISTORY CREATE TABLESPACE ALL FOR DATABASE testdb1

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

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

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

DB2 將應用指定時間戳之前的所有日志，并恢復數據庫的表空間。

步驟 7. 驗證已恢復的表空間和表

CONNECT TO testdb1

LIST TABLESPACES SHOW DETAIL

SELECT * FROM tab1

以上命令的結果允許我們確認表空間和表是否已恢復到指定的時間點。

結束語

本文介紹了可以在 DB2 中執行各種不同的日志。文章還演示了一些關鍵的恢復場景，并提供了從各類故障恢復系統的詳細步驟。

對于任務關鍵型數據庫，理解備份恢復的流程和意外故障的計劃非常重要。同時，強烈建議將經過測試的備份和恢復計劃應用到實踐中。