您曾多少次碰到過錯誤消息“SQL0946C The transaction log for the database is full”？
在盡力解決該問題時，您是否停下來思考為何存在事務日志以及事務日志記錄服務的目的是什麼呢？
若沒有事務，多個用戶和應用程序同時與一個數據庫進行交互時就必然會破壞數據。而如果沒有事務日志記錄，DB2 UDB 中的一些據庫恢復方法就不會存在。
如果您還沒有完全理解這些概念，也不必擔憂。我將解釋事務是什麼以及事務日志記錄背後的機制。然後，我將展示在系統崩潰或程序故障之後，如何使用數據庫事務日志文件中所存儲的信息來使數據庫回歸到一致、可用的狀態。
但您還可以通過這些重要的日志做更多事情。在今後的專欄中，我將展示如何使用事務日志文件重現操作，以將數據庫恰好恢復到給定時間點所處的狀態。
事務
事務（也稱作工作單元）是指一個或多個 SQL 操作的序列，這些操作組合成一個單元且通常位於一個應用程序進程內。該單元通常稱作是“原子的”，因為它是不可分的 — 它的所有工作要麼全都執行，要麼全都不執行。一個給定的事務可以執行任何數目的 SQL 操作（從一個到幾千個，取決於業務邏輯裡對於“一步”的定義）。
一個事務的開始和終止定義了數據庫裡數據一致性的點；要麼將事務裡所執行的所有操作的結果應用到數據庫上，並使之成為永久的（已提交），要麼將之都撤銷（回滾），使數據庫返回到啟動該事務之前的狀態。
事務是在建立到數據庫的連接之後第一次執行 SQL 語句時或在現有事務終止時立即啟動。一旦啟動，就可以使用名為原子提交的功能隱式地終止該事務。通過原子提交，會將每條可執行的 SQL 語句當作一個事務。如果該語句執行成功，那它所做的任何修改都將應用到數據庫上，但如果語句失敗，那修改將被丟棄。
還可以通過執行 COMMIT 或 ROLLBACK SQL 語句顯式地終止事務。
這些語句的基本語法是：
COMMIT <WORK>
和
ROLLBACK <WORK>
在 COMMIT 終止事務時，會將該事務從開始時對數據庫所做的所有修改變成永久性的。使用 ROLLBACK，所有修改都將撤銷。
事務所做的未提交的修改對其他用戶和應用程序來說是無法訪問的，除非那些用戶和應用程序使用的是未提交讀（UR）隔離。然而，一旦提交了事務所做的修改，它們對於所有其他用戶和應用程序來說就都是可以訪問的了，並且只能通過執行新事務中的新 SQL 語句來刪除。
事務日志記錄
在向一個基表進行 INSERT 時，首先在緩沖池中創建一條記錄，該緩沖池與指定該表的數據存儲於何處的表空間相關聯。每次更新或刪除一條記錄時，就從存儲器中檢索包含該記錄的頁面，並復制到適當的緩沖池中，然後由 UPDATE/DELETE 進行修改。一旦進行了這一修改，就會向日志緩沖器寫入一條反映該動作的記錄，日志緩沖器是內存中的另一指定存儲區。（為日志緩沖器預留的真正存儲大小是由 logbufsiz 數據庫配置參數控制的。）如果執行 INSERT，就會寫入一條包含了新行數據值的記錄。當出現刪除時，就寫入一條包含了該行原始值的記錄。如果執行 UPDATE，就寫入一條包含了該行原始值和新值的記錄。（在大多數情況下，通過用該行的更新值在原始值上執行 EXCLUSIVE OR，為更新操作生成日志記錄。）最終，當執行 INSERT、UPDATE 或 DELETE 的事務終止時，就將相應的 COMMIT 或 ROLLBACK 記錄寫入日志緩沖器。
每當激活緩沖池 I/O 頁面清理器，日志緩沖器本身已滿，或者提交或回滾事務時，就立即將日志緩沖器中所存儲的所有記錄寫入磁盤上所存儲的一個或多個事務日志文件中。如果發生系統故障，日志緩沖器的不斷刷新將最小化可能丟失的日志記錄數目。一旦將與特定事務相關聯的所有日志記錄（包括相應的 COMMIT 或 ROLLBACK 記錄）成功具體化（externalize）為一個或多個日志文件，就會將事務本身的結果復制到適當的表空間容器以永久存儲。（已修改的數據頁本身仍保留在內存中，在必要時可以快速進行訪問；它們最終將被改寫。）該過程稱作寫前日志記錄（write-ahead logging），保證對數據所做的修改在記錄到數據庫之前，總是被具體化為日志文件。（見圖 1）
因為多個事務可以在任何時候使用一個數據庫，所以一個日志文件可能包含屬於幾個不同事務的日志記錄。為了追蹤哪一條日志記錄屬於哪個事務，要給每條日志記錄分配一個特殊的事務 ID，將之綁定到創建它的事務。通過使用事務 ID，可以隨時將與特定事務相關聯的日志記錄寫入一個或多個日志文件，而不影響數據一致性 — 最終，對於終止該事務的操作的 COMMIT 或 ROLLBACK 記錄也將進行日志記錄。
崩潰恢復
在還未提交事務的修改之前，如果發生問題 — 例如，發生停電或應用程序異常終止 — 會發生什麼事情呢？事務所做的任何未提交或已回滾的工作都將丟失。此外，如果正在將其數據具體化（externalize）到數據庫的已提交事務遭到破壞，該數據庫將處於不一致、不可用的狀態。（每當嘗試建立連接時，不一致的數據庫將生成返回代碼和錯誤消息。）您無法恢復內存中所存儲的事務記錄，但是可以通過執行名為崩潰恢復的操作，將不一致的數據庫恢復為一致、可用的狀態。
啟動崩潰恢復的最常用方法就是從 DB2 命令行處理器（DB2 Command Line Processor，CLP）執行 RESTART 命令。該命令的基本語法是：
RESTART [DATABASE | DB]
[DatabaseName]
USER [UserName] < USING
[PassWord] > >
< DROP PENDING TABLESPACES
( [TS_Name] , ... ) >
< WRITE RESUME >
其中：
DatabaseName 指示分配給嘗試進行恢復的數據庫的名稱。
UserName 指示分配給用戶的名稱，崩潰恢復將在該用戶的權限下執行。
PassWord 指示與用戶名稱相對應的密碼，崩潰恢復將在該用戶的權限下執行。
TS_Name 指示分配給一個或多個表空間的名稱，如果在嘗試將表空間恢復為一致狀態時碰到錯誤，那麼這些表空間將被禁用或置為 Drop Pending 模式。
注意：尖括號（< >）中顯示的參數是可選的；方括號（[ ]）中顯示的參數是必需的；逗號後面加省略號（, ...）表示前面的參數可以重復多次。關於 RESTART 命令的完整語法，請參閱參考資料中所列的 IBM DB2 Universal Database, Version 8 Command Reference。
如果需要在名為 SAMPLE 的數據庫上執行崩潰恢復操作，就執行 RESTART DATABASE SAMPLE 命令。
您還可以配置數據庫，以便每當用戶或應用程序嘗試連接處於不一致狀態的它時，它就會自動啟動崩潰恢復。僅僅需要將值 ON 分配給數據庫的 AUTORESTART 配置參數。（每當激活數據庫或嘗試建立連接時，DB2 Database Manager 就檢查數據庫的狀態。當 autorestart 配置參數設置為 ON 時，如果數據庫處於不一致的狀態，Database Manager 就自動執行 RESTART 命令。）
在進行崩潰恢復時，將分析數據庫事務日志文件中存儲的記錄，並將每條具有相應 COMMIT 記錄的事務記錄重新應用到數據庫。重現然後撤銷沒有相應 COMMIT 記錄的所有記錄（這就是為何要為所有更新操作記錄前後信息的原因）。因為日志記錄頻繁進行具體化，且由特定事務所做的修改只有當事務本身成功終止時才進行具體化，所以在故障之後將數據庫恢復到一致性狀態的能力總是能得到保證。
崩潰恢復只是事務日志所提供的功能中的一種。在處理前滾恢復時，我將展示如何可以使用事務日志文件中所存儲的記錄將數據庫恢復到任何指定時間點所處的狀態。但是您首先需要理解備份映像和版本恢復等概念，我將在下一專欄中介紹這兩個主題。
