はじめに
Db2を運用するうえで、アーカイブログの管理は避けて通れません。
ログはリカバリーに必要な重要データですが、運用を続ける限り増え続けます。
そのため、
・ディスク容量の逼迫
・ログ領域の枯渇によるDB停止
といった問題につながります。
一方で、ログを誤って削除すると復旧できなくなるため、単純なファイル削除では対応できません。
本記事では、Db2のアーカイブログ削除の仕組みと、実務での運用ポイントを整理します。
なお、トランザクションログ自体の説明は以下の記事にまとめています。
Db2のログと回復管理とは？トランザクションログの仕組みと実務運用を解説
アーカイブログ管理の基本
アーカイブログ削除を理解するには、ログとバックアップの関係を整理する必要があります。
Db2では以下の3つがセットで管理されます。
・アーカイブログ
・リカバリー履歴ファイル
・バックアップ
アーカイブログはロールフォワードリカバリーに使用される更新履歴です。
リカバリー履歴ファイルは、どのバックアップにどのログが必要かを管理しています。
重要なのはログ単体では削除判断できないことです。
削除可能かどうかは、必ずバックアップとの関係で決まります。
そのため、削除方法も以下の3パターンに分かれます。
・履歴を基準に削除する方法
・ポリシーで自動削除する方法
・ログの状態から判断する方法
PRUNE HISTORYによる削除
最も基本となる方法がPRUNE HISTORYです。
リカバリー履歴を基準に、不要なログを安全に削除できます。
実行の流れ
まずバックアップ履歴を確認します。
db2 "list history all for db sample"
次にログのアーカイブ履歴を確認します。
db2 "list history all for db sample" | grep " X "
ここで、残すバックアップを決めます。
そのバックアップより前のログが削除対象になります。
削除は以下のコマンドで実行します。
db2 prune history 20260311191450 and delete
動作のポイント
・履歴ファイルが整理される
・対応するアーカイブログも削除される
また、AND DELETEを付けない場合は履歴のみ削除され、ログファイルは残ります。
考え方として削除基準は日付ではなく、どのバックアップまで戻れる必要があるかを基準に削除範囲を決めます。
自動削除機能 AUTO_DEL_REC_OBJ
運用を自動化する場合は、AUTO_DEL_REC_OBJを利用します。
この機能を有効にすると、バックアップ実行時に古いリカバリーオブジェクトが自動削除されます。
関連パラメータ
・AUTO_DEL_REC_OBJ
・NUM_DB_BACKUPS
・REC_HIS_RETENTN
削除条件は以下の通りです。
・指定したバックアップ世代数を超えている
・保持日数を超えている
この両方を満たした場合に削除されます。
動作イメージ
例えば以下の設定の場合
NUM_DB_BACKUPS = 3
REC_HIS_RETENTN = 5
・最新3世代より古い
・かつ5日以上経過
この条件に該当するログやバックアップが削除されます。
注意点
この機能は便利ですが制御が難しい側面があります。
・削除タイミングはバックアップ依存
・ログ単体での制御ができない
・意図しない削除が発生する可能性がある
そのため、要件が厳しい環境では単独利用は避けるのが基本です。
最初のアクティブログを基準にした削除
Db2では「最初のアクティブログ」という情報を確認できます。
db2 get db cfg for sample
または
db2 "select first_active_log from table(mon_get_transaction_log(-1))"
このログより前のログは、クラッシュリカバリーには不要と判断されます。
そのため削除可能と考えることができます。
注意点
この考え方には大きな注意点があります。
ロールフォワードリカバリーには必要な場合がある
つまり、完全な復旧を前提とした場合は削除してはいけない可能性があります。
この方法は以下の用途に限定します。
・ディスク逼迫時の緊急対応
・検証環境
通常運用ではPRUNE HISTORYを使用するのが基本です。
運用上のポイント
アーカイブログ削除では、いくつか重要な注意点があります。
LOGARCHMETH1の影響
設定されているシステムはあまり見かけませんが、LOGARCHMETH1がLOGRETAINの場合、
・履歴は削除される
・ログファイルは削除されない
このため、PRUNE HISTORYを実行してもディスクは減りません。
バックアップとの整合性
ログ削除で必ず確認することは1つです。
削除しても復旧できるか
これを確認せずに削除すると、障害時に復旧不能になります。
特に世代管理やポイントインタイムリカバリーを要件としている場合は注意が必要です。
古いログが不要とは限りません。
重要なのは経過時間ではなく、復旧に必要かどうかです。
まとめ
Db2のアーカイブログ削除は、ディスク管理とリカバリー設計の両方に関わる重要な運用です。
・ログ削除はバックアップとセットで考える
・基本はPRUNE HISTORYで制御する
・自動削除は便利だが設計が重要
・アクティブログ基準の削除は限定用途
最も重要なのは、
どこまで復旧できる状態を維持するか
を事前に決めることです。
この方針が決まらない限り、適切なログ削除はできません。
具体的な設計や手順書作成の際は、公式情報もあわせて確認することをおすすめします。
コメント