Db2 Transaction Log の内部構造を徹底解説：Circular Logging、Archive Logging、Soft Checkpoint まで

はじめに

この記事では、IBM Db2のTransaction Logの内部実装を深掘りします。

InnoDB、PostgreSQL、Oracle、SQL Serverに続くシリーズ最終回です。Db2のTransaction Logは2つのロギングモード（Circular / Archive）を持つのが特徴的です。Db2 11.5を中心に、以下を解説します：

• Transaction Logの役割
• Log Record（記録の単位）
• ログファイルの物理構造（Primary Log / Secondary Log）
• Circular LoggingとArchive Logging
• Log Bufferと書き込みの仕組み
• Soft Checkpoint

そもそもDb2 Transaction Logって何？

他の4つのDBと同じくWALの原則に従います。データページを変更する前にログをディスクに書き、クラッシュ時にリカバリできるようにします。

Db2の用語で整理すると：

Db2用語                 InnoDB用語        PostgreSQL用語     Oracle用語         SQL Server用語
──────────────────────────────────────────────────────────────────────────────────────────────
Transaction Log        REDO Log          WAL               REDO Log          Transaction Log
LSN (Log Sequence      LSN               LSN               SCN               LSN
  Number)
Log Buffer             Log Buffer        WAL Buffer        Redo Log Buffer   Log Buffer
db2loggw               log_writer        バックエンド自身    LGWR              Log Writer
Primary Log            ib_logfile0/1     WALセグメント       Online Redo Log   .ldfファイル
Archive Log            ―                 WALアーカイブ       Archived Redo Log ログバックアップ

Db2のLSNはInnoDBやPostgreSQLと同様に、ログ内の物理的なバイトオフセットです。

Log Recordの構造

Db2のLog Recordは他のDBと同様に、各操作の変更内容を記録します。

Log Recordの種類

主要なLog Record Type：

SQL Serverと同様に、Db2もREDO情報とUNDO情報を同じTransaction Logに記録します。

Compensation Log Record（CLR）

ロールバック時、Db2はUNDO操作自体もログに記録します。これがCLR（Compensation Log Record）です。ARIESアルゴリズムの標準的な実装です。

正常時:
  LSN 100: BEGIN
  LSN 200: INSERT (row A)    ← REDO: insert, UNDO: delete
  LSN 300: UPDATE (row B)    ← REDO: update, UNDO: old value

ロールバック時:
  LSN 400: CLR for LSN 300   ← row Bを元に戻す（UNDOのREDO）
  LSN 500: CLR for LSN 200   ← row Aを削除（UNDOのREDO）
  LSN 600: ROLLBACK

CLRがあることで、ロールバック中にクラッシュしても、CLRをリプレイするだけで正しい状態に復元できます。

db2readlogで実際に見てみる

$ db2readlog -f logfile.log

LSN: 0x000000001000  Type: Normal  TxnID: 0x0000000003
  Redo: INSERT into TABLE1 ...
  Undo: DELETE from TABLE1 ...

LSN: 0x000000001200  Type: Normal  TxnID: 0x0000000003
  Redo: COMMIT

ログファイルの物理構造

Primary LogとSecondary Log

Db2のログファイルはPrimary LogとSecondary Logの2種類があります。

Primary Log（事前確保）:
  S0000000.LOG  S0000001.LOG  S0000002.LOG  ... S000000N.LOG
  ↑ LOGPRIMARY パラメータで数を指定

Secondary Log（必要時に動的作成）:
  S000000X.LOG  S000000Y.LOG  ...
  ↑ LOGSECOND パラメータで最大数を指定

-- 設定確認
db2 get db cfg for mydb | grep -i log

 Log file size (4KB)                         (LOGFILSIZ) = 1024
 Number of primary log files                (LOGPRIMARY) = 13
 Number of secondary log files               (LOGSECOND) = 12
 Path to log files                                       = /db2/logs/mydb/

• LOGFILSIZ：各ログファイルのサイズ（4KBページ単位）
• LOGPRIMARY：Primary Logの数（DB起動時に事前作成）
• LOGSECOND：Secondary Logの最大数（Primary Logが足りないとき動的作成）

Primary Logが全部使われるとSecondary Logが作られます。Secondary Logも使い切るとログフル（log full）エラーになります。

各DBのファイル管理比較

Circular LoggingとArchive Logging

Db2の最大の特徴は、2つのロギングモードを明確に分けている点です。

Circular Logging（デフォルト）

ログファイルを循環的に再利用します。不要になったログは自動的に上書きされます。

S0000000.LOG → S0000001.LOG → S0000002.LOG → S0000000.LOG → ...
   (上書き)                                      ↑ 循環

• PITR（Point-in-Time Recovery）は不可
• クラッシュリカバリのみ可能
• ログファイルが肥大化しない
• 開発/テスト環境向け

SQL ServerのSIMPLE Recovery Modelに相当します。

Archive Logging

ログファイルを上書きせず、アーカイブ先に保存します。

-- Archive Loggingに切り替え
db2 update db cfg for mydb using LOGARCHMETH1 DISK:/db2/archlog/
-- DB再起動が必要
db2 deactivate db mydb
db2 activate db mydb

Active Log:
  S0000000.LOG → S0000001.LOG → S0000002.LOG
                                      ↓ 不要になったらアーカイブ
Archive Log:
  /db2/archlog/S0000000.LOG
  /db2/archlog/S0000001.LOG

• PITRが可能
• オンラインバックアップが可能
• 本番環境向け
• ログの管理（削除）は運用者の責任

各DBのログ保持方針比較

Log Bufferと書き込み

Log Buffer

Db2のLog Bufferはデータベース共有メモリ内にあります。

-- Log Bufferサイズの確認・設定
db2 get db cfg for mydb | grep LOGBUFSZ
 Log buffer size (4KB)                       (LOGBUFSZ) = 256
-- デフォルト256ページ = 1MB

書き込みの流れ

Db2はOracleやSQL Serverと同様に、専用プロセス（db2loggw）がディスクへの書き込みを担当します：

1. エージェントスレッド
   ├─ Log Recordを生成
   ├─ Log Bufferにコピー
   └─ コミット時にdb2loggwに通知

2. db2loggw（Log Writer）
   ├─ Log Bufferからログファイルにwrite + fsync
   └─ 以下のタイミングで起動：
       ├─ コミット時
       ├─ Log Bufferが一定量埋まったとき
       └─ 定期的

MINCOMMIT：Group Commitの制御

Db2にはMINCOMMITというユニークなパラメータがあります：

db2 get db cfg for mydb | grep MINCOMMIT
 Number of commits to group                 (MINCOMMIT) = 1

MINCOMMIT = 1（デフォルト）では、コミットごとにすぐfsyncします。値を大きくすると、指定数のコミットが溜まるまでfsyncを遅延させ、Group Commitの効果を高めます。

Soft Checkpoint

Db2のCheckpoint方式

Db2のCheckpointはSoft Checkpointと呼ばれます。OracleのIncremental CheckpointやSQL ServerのIndirect Checkpointに近い考え方です。

Soft Checkpointでは： 1. Checkpoint開始時点のLSNを記録 2. ダーティページのフラッシュはPage Cleanerが非同期で常時実行 3. Checkpointは「ここまでのダーティページはフラッシュ済み（または進行中）」という位置を記録

-- Checkpointの間隔（デフォルト: 自動）
db2 get db cfg for mydb | grep SOFTMAX
 Percent log file reclaimed before soft chkpt (SOFTMAX) = 520

SOFTMAXはPrimary Logの何%が消費されたらSoft Checkpointを発行するかを制御します。

各DBのCheckpoint比較（最終版）

まとめ：REDO/WALシリーズ全体比較

5つのDBを比較すると、WALの基本原則（変更前にログを書く）は共通ですが、実装のアプローチは多様です：

• InnoDB：MySQL 8.0のLock-free設計が最も先進的。ただしUNDOは別管理
• PostgreSQL：シンプルな設計。Full Page WriteでWALだけで完結する潔さ
• Oracle：最も成熟した運用機能（グループ/メンバー、アーカイブ）
• SQL Server：REDO/UNDOの統合とVLFが独特。Recovery Modelが明快
• Db2：Circular/Archiveの明確な分離。Primary/Secondaryの2段構えが堅実

どのDBも「ディスクの順次書き込み性能を最大限活用しつつ、クラッシュからデータを守る」という同じゴールに向かって、それぞれの歴史と設計思想を反映した実装になっています。

参考文献

• Db2 Documentation: Transaction Logging
• Db2 Documentation: Log Files
• Db2 Documentation: Circular Logging and Archive Logging
• Db2 Documentation: Database Configuration Parameters
• Db2 Documentation: db2readlog