はじめに
Db2のログ管理では「アーカイブ」という言葉が頻繁に登場しますが、実際には2つの異なる動作を指しています。
・ログファイルがクローズされる
・クローズされたログがアーカイブ領域にコピーされる
この2つを区別できていないと、
・ログがいつ増えるのか分からない
・どこまでが削除可能なのか判断できない
といった問題につながります。
本記事では、アーカイブログの基本に加えて、
・ログが切り替わるタイミング
・コピーが実行されるタイミング
・オンラインアーカイブログの状態
を中心に、実務で使える形で整理します。
なお、ここではロギングにフォーカスをあてていますが、リカバリの視点としては以下の記事にまとめています。
Db2のログと回復管理とは？トランザクションログの仕組みと実務運用を解説
アーカイブログの基本構造
Db2では、ある時点で書き込み対象となるログは1つだけです。
このログを「カレントログ」と呼びます。
db2 "select FIRST_ACTIVE_LOG, CURRENT_ACTIVE_LOG from table(mon_get_transaction_log(-1)) as t"
| 項目 | 意味 |
|---|---|
| CURRENT_ACTIVE_LOG | 現在書き込み中のログ |
| FIRST_ACTIVE_LOG | リカバリーに必要な最古のログ |
ログは以下の流れで管理されます。
- カレントログに書き込み
- ログがクローズされる
- アーカイブ対象になる
- アーカイブ領域にコピーされる
ここで重要なのは、クローズとコピーは別のタイミングで発生するという点です。
この違いが、ログ管理の挙動を理解する上でのポイントになります。
カレントログがクローズされるタイミング
ログがアーカイブ対象になる最初の条件は「カレントログのクローズ」です。
主なタイミングは以下の通りです。
| タイミング | 内容 |
|---|---|
| ログ満了 | ファイルサイズ上限に達したとき |
| DB非活動化 | 接続がすべて切断されたとき |
| オンラインバックアップ | バックアップ開始時に切り替え |
| ARCHIVE LOG 実行 | 明示的にログを切り替える |
| WRITE SUSPEND | 書き込み停止時に切り替え |
ここで重要な点があります。
ARCHIVE LOGコマンドは「コピー」ではなく、ログをクローズするためのコマンドです。
つまり、
・クローズされる
・アーカイブ対象になる
までは保証されますが、
・コピーが完了するとは限らない
という動きになります。
アーカイブ領域へコピーされる仕組み
ログファイルはクローズされた後、自動的にアーカイブ対象になります。
しかし、コピーは即時ではありません。
処理の流れは以下の通りです。
| ステップ | 内容 |
|---|---|
| 1 | ログがクローズされる |
| 2 | コピー対象として登録される |
| 3 | 非同期でアーカイブ領域にコピー |
| 4 | コピー完了 |
ここでの重要ポイントは以下です。
コピーは非同期で実行される
そのため、
・クローズ済みでも未コピーのログが存在する
・コピー遅延が発生する
という状態が発生します。
コピー先は以下のパラメータで制御されます。
db2 get db cfg | grep LOGARCHMETH1
例
LOGARCHMETH1 = DISK:/archive/log
この設定により、ログは指定した領域へ順次コピーされます。
なお、コピー後のメンテナンスについては以下の記事で詳しく整理しています。
Db2のアーカイブログ削除とは？PRUNE HISTORYと自動削除の実務設計を解説
オンラインアーカイブログという状態
ログがクローズされてからコピーが完了するまでの間、そのログは「オンラインアーカイブログ」と呼ばれます。
この状態は以下の特徴を持ちます。
| 状態 | 内容 |
|---|---|
| 書き込み終了 | カレントログではない |
| コピー待ち or コピー中 | アーカイブ処理中 |
| 削除不可 | リカバリー対象 |
この状態が重要になる理由は、ログ管理の詰まりに直結するためです。
例えばコピーが遅延すると、
・ログが解放されない
・新しいログが確保できない
といった影響が出ます。
ログの問題はディスク容量ではなく、コピーの遅延によって発生することがあるという点が実務上のポイントです。
アクティブログの範囲とログの再利用
ログファイルは、アーカイブ領域にコピーされた後もすぐに役割が終わるわけではありません。
Db2では、ログは一定範囲が「アクティブログ」として管理され続けます。
この範囲は、以下の値で確認できます。
db2 "select FIRST_ACTIVE_LOG, CURRENT_ACTIVE_LOG from table(mon_get_transaction_log(-1))"
| 項目 | 意味 |
|---|---|
| FIRST_ACTIVE_LOG | リカバリーに必要な最も古いログ |
| CURRENT_ACTIVE_LOG | 現在書き込み中のログ |
例えば、
・FIRST_ACTIVE_LOG = 10
・CURRENT_ACTIVE_LOG = 20
であれば、S0000010.LOG から S0000020.LOG までがアクティブログとして扱われます。
ここで重要なのは、ログの配置場所ではなく「Db2の管理状態」です。
・アーカイブ領域にコピーされている
・クローズされている
この状態であっても、アクティブログの範囲に含まれている限りは、Db2にとっては必要なログです。
ログファイルは役割を終えた後、削除されるのではなく再利用されます。
動きとしては以下の通りです。
| ステップ | 内容 |
|---|---|
| 1 | ログがクローズされる |
| 2 | アーカイブ領域にコピーされる |
| 3 | アクティブログ範囲から外れる |
| 4 | ログファイルがリネームされる |
| 5 | 新しいログとして再利用される |
この仕組みにより、ログファイルは循環的に使用されます。
そのため、ログ管理では
・どのログが現在使用中か
・どこまでがアクティブログか
を把握することが重要になります。
単純に「ファイルが存在しているかどうか」ではなく、
Db2の内部状態で判断する必要があるという点が実務上のポイントです。
まとめ
Db2のアーカイブログは、2つの動作を分けて理解することが重要です。
・ログがクローズされる
・アーカイブ領域へコピーされる
そして、
・コピーは非同期で行われる
・コピー完了前はオンラインアーカイブログになる
という流れで管理されています。
さらに、
・アクティブログの範囲で管理される
・ログは再利用される
という仕組みを理解することで、ロギングの全体像が明確になります。
トランザクションログは単なる履歴ではなく、リカバリーの前提となるデータです。
バックアップとリカバリーについては、以下の記事も参考になります。
コメント