Db2を本番稼働させる際、アーカイブログ方式での運用は標準的ですが、ストレージ管理のミスはシステム停止に直結します。2026年現在の最新メジャー版である Db2 V12.1 LUW の知見を含め、リカバリー履歴ファイルとアーカイブログ削除の相関関係を再整理します。
構成パラメーターとV12の変遷
履歴ファイルの保持期間を決定する REC_HIS_RETENTN パラメーター。Db2のバージョンアップに伴い、デフォルト値が変更されている点に注意が必要です。V12ではクラウドネイティブ環境を意識し、より短期間で高頻度なサイクルが推奨される傾向にあります。
バージョン別デフォルト保持期間
- Db2 V12.1: 90日（最新：AUTO_DEL_REC_OBJ による自動連動削除が主流）
- Db2 V11.5: 90日（デフォルト値が短縮された世代）
- Db2 V11.1以前: 366日（長期保持によるディスク圧迫リスクに注意）
特に最新の Db2 V12.1 運用においては、履歴の削除に合わせてバックアップイメージやログを物理的に自動削除する AUTO_DEL_REC_OBJ ON の設定がベストプラクティスとなります。
ログ削除失敗を防ぐ「黄金の不等式」
日次ジョブ等で PRUNE HISTORY ... AND DELETE を実行してもアーカイブログが消えないことがあります。その原因の多くは、以下のロジックが崩れていることにあります。
【削除成功の条件】
REC_HIS_RETENTN ＞ PRUNE HISTORY [Timestamp]
履歴ファイルが REC_HIS_RETENTN によって自動整理（自動削除）されてしまうと、Db2はどのログファイルを消すべきかの情報を失います。その結果、履歴に存在しないログは削除対象として認識されず、物理ファイルが残り続けてしまいます。
孤立ログのクリーンアップ（実務推奨版）
履歴ファイルから参照できなくなったログや、設定ミスで残った古いログファイルは、OSコマンドで直接削除します。汎用性が高く、環境を選ばない -exec 形式が現場での標準です。
# <ARCHIVE_PATH> は環境に合わせ、${dbname} は変数で定義
find <ARCHIVE_PATH> -name “*${dbname}*” -mtime +3 -exec rm -f {} \;
いざという時に迷わないためのバックアップ方式の選定とリカバリの手順を、本書 第4章「バックアップ・リカバリの鉄則」で体系化しています。
現場で引ける Db2 の教科書
現場で引ける！Db2実践エンジニア・バイブル
Db2はRDBMS市場でシェア数%。情報が少なく、頼れるのは膨大な公式マニュアルだけ――
そんな現状を変えたくて、「なぜこの値にするのか」「この障害のとき次に何を見るのか」という、マニュアルに載っていない現場の文脈を1冊にまとめました。書いてあることはすべて実際の現場で経験したことです。
アーキテクチャ／構成パラメーター選定／セキュリティ／バックアップ・リカバリ／HADR／pureScale／日常点検の自動化／メモリ・ロック競合／SQLチューニング／RUNSTATS・REORG／MON_GET監視／現場の難題集 ―― 全12章＋運用シェルスクリプト集。
2026年版・運用のアドバイス
最新の Db2 on OpenShift (V12.1) などのコンテナ環境では、ディスクフルがポッドの再起動ループを引き起こします。AUTO_DEL_REC_OBJ パラメーターによる自動制御を基本としつつ、上記 find -exec をメンテナンス用ジョブとして組み込む「二重の防護策」が、現代のSEに求められる堅実な設計です。
コメントを残す