Db2 で障害が起きたとき、最初に開くことになるのが db2diag.log です。中身は次のようなエントリの積み重ねになっています。
2026-07-29-10.09.26.346076+540 E3002262E1488 LEVEL: Severe
PID : 8951 TID : 140137912592064 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000
HOSTNAME: db2node1
EDUID : 1 EDUNAME: db2sysc 0
FUNCTION: DB2 UDB, oper system services, sqloEDUCodeTrapHandler, probe:90
MESSAGE : ADM14011C A critical failure has caused the following type of error:
"Trap". The database manager cannot recover from the failure. First
Occurrence Data Capture (FODC) was invoked in the following mode:
"Automatic". FODC diagnostic information is located in the following
directory:
"/home/db2inst1/sqllib/db2dump/DIAG0000/FODC_Trap_2026-07-29-10.09.20
.163063_0000/".実際に読むのは時刻・LEVEL・MESSAGE・EDUID の4つだけです。FUNCTION に出ている内部関数名は IBM サポートに提示するための情報で、自分で読み解く必要はありません。
db2diag.log はDb2 インスタンスの診断ログです。全部読む前提のファイルではありません。この記事では見る順番と、目的からの逆引きを最短でまとめます。実機ログつきの詳しい解説は末尾のZenn記事にあります。
まず見る（結論）
db2diag.log を開く前に、ログの実体がどこにあるかを確認します。DIAGPATH の設定値には $m トークンが付いているため、そのパスに cd しても存在しません。見るのは Current member resolved DIAGPATH の行です。
# ログの場所・サイズ上限・出力レベルを確認する
db2 get dbm cfg | grep -iE "DIAGPATH|DIAGSIZE|DIAGLEVEL"
# 今日の重大なエラーだけを切り出す
db2diag -readfile -level Critical,Severe,Error -t "$(date +%Y-%m-%d)"やりたいこと → 原因 → 対処（逆引き）
| やりたいこと / 症状 | よくある原因 | まず打つ手 |
|---|---|---|
| db2diag.log が見つからない | DIAGPATH の設定値に $m トークンが付いており、そのままでは存在しないパスになる |
db2 get dbm cfg の Current member resolved DIAGPATH の行を見る |
| 巨大でどこを見ればいいか分からない | 全期間・全レベルが1ファイルに入っている | grep ではなく db2diag でレベルと時間を絞る。1レコードが複数行なので行単位の grep は前後が切れる |
| エラーを絞ったのに0件になる | -lastrecords がフィルタより先に効く。直近N件を切り出してから、その中を探している |
N を増やす。of total N records の分母が「見ている窓」の大きさ |
| 重大なエラーを監視しているのに見落とす | -level はしきい値ではなく列挙。-level Error は Severe も Critical も含まない |
-level Critical,Severe,Error と列挙する |
| cron やスクリプトに入れると常に0件 | ファイル名を省くと標準入力を読みに行く。端末が無い環境では0件になる | -readfile を付ける。該当0件でも終了コードは1なので $? や set -e で判定しない |
| 検索しているのに引っかからない | -g は検索値の大文字小文字を区別する。ログの実値は Severe や hdrSend のようなキャメルケース |
-gi を使う。演算子は完全語一致が =、部分一致が :=（: 単独は構文エラー） |
| 危険な兆候だけ拾いたい | grep ADM では無関係な行が混ざる。ADM[0-9]{4}C は桁数もサフィックスも外れていて拾えない |
grep -E "ADM[0-9]{4,5}[CE]"。番号は5桁もあり（ADM14011C）、実際のサフィックスは I／W／E／C |
| Db2 が異常終了した原因を追いたい | 重大な障害では FODC ディレクトリが作られ、ADM14011C の本文にそのパスが書かれる |
ADM14011C を探し、本文中の FODC_* ディレクトリを見る |
まずログの実体の場所を確認してから絞り込みます。設定値のパスを見て「ログが無い」と判断してしまうのが、いちばん時間を無駄にする形です。
-level Error は「Error 以上」ではない
-level は重大度のしきい値ではなく、レベル名の列挙です。検証機では -level Error が368件、-level Severe が13件、-level Error,Severe が381件でした。368＋13＝381 で、Error が Severe を含んでいないことが数字に出ています。さらに上位に Critical もあるため、監視では -level Critical,Severe,Error と列挙します。
db2 "? ADM1823C" はサフィックスを無視して、製品が持つ正規のサフィックス付きの本文を返します（この例では ADM1823E が返ります）。存在しない番号を指定すると SQL10007N で落ちます。ネット上の情報を探すより確実です。
それでも切り分からないとき（実機ログつきの詳解）
db2diag のフィルタの組み合わせ、ADMメッセージの拾い方、FODC ディレクトリから障害を追う手順まで含めた詳しい解説は、Zennのフル記事にまとめています。
関連: SQL0964C トランザクションログ満杯 ／ SQL1032N インスタンス未起動 ／ MON_GET 表関数による常駐監視
この記事のような現場のTIPSを、Db2運用の全体像として12章に体系化しました。公式マニュアルには載らない「あのとき知っていれば」を減らすための1冊です。
現場で引ける Db2 の教科書
現場で引ける！Db2実践エンジニア・バイブル
Db2はRDBMS市場でシェア数%。情報が少なく、頼れるのは膨大な公式マニュアルだけ―― そんな現状を変えたくて、「なぜこの値にするのか」「この障害のとき次に何を見るのか」という、マニュアルに載っていない現場の文脈を1冊にまとめました。書いてあることはすべて実際の現場で経験したことです。
アーキテクチャ／構成パラメーター選定／セキュリティ／バックアップ・リカバリ／HADR／pureScale／日常点検の自動化／メモリ・ロック競合／SQLチューニング／RUNSTATS・REORG／MON_GET監視／現場の難題集 ―― 全12章＋運用シェルスクリプト集。
