Db2「SQL0964C トランザクションログがいっぱいです」の原因を切り分ける

夜間バッチや大きめの一括更新の途中で処理が止まり、次のエラーが返ることがあります。

SQL0964C  The transaction log for the database is full.  SQLSTATE=57011

SQL0964C はアクティブログの領域を使い切った状態です。反射的に LOGSECOND を増やして凌ぐ対応をしがちですが、原因が設定サイズでない場合は次にもっと大きなログを食い潰すだけです。この記事ではまず見る値と、症状からの逆引きを最短でまとめます。実機での確認ログや手順の詳細は末尾のZenn記事にあります。

まず見る（結論）

先に「総容量に対して今どれだけ使ったか」を掴みます。障害後であれば高水位 TOT_LOG_USED_TOP が空き容量に張り付いているかどうかで、本当に使い切ったのかが分かります。

SELECT MEMBER, TOTAL_LOG_USED, TOTAL_LOG_AVAILABLE,
       TOT_LOG_USED_TOP, SEC_LOGS_ALLOCATED
  FROM TABLE(MON_GET_TRANSACTION_LOG(-2)) AS T;

使い切っていたことが確認できたら、次は誰が食ったかです。作業単位を消費ログ量の多い順に並べます。

SELECT APPLICATION_HANDLE, UOW_LOG_SPACE_USED, WORKLOAD_OCCURRENCE_STATE
  FROM TABLE(MON_GET_UNIT_OF_WORK(NULL, -2)) AS T
 ORDER BY UOW_LOG_SPACE_USED DESC
 FETCH FIRST 5 ROWS ONLY;

ここで突出した接続がいるかいないかで、原因の経路が二手に分かれます。

症状 → 原因 → 対処（逆引き）

今まさに詰まっている処理を終わらせたいときは、LOGSECOND だけがオンラインで即時反映されます。LOGPRIMARY と LOGFILSIZ の変更はデータベースの再活性化が必要なので、障害中には効きません。

なお、犯人アプリを見つけてもFORCE APPLICATION で即切るのは危険です。巨大トランザクションのロールバックはそれ自体がログを消費します。空間を確保してから判断します。

それでも切り分からないとき（実機ログつきの詳解）

ログ総容量の計算、db2pd -logs の読み方、MAX_LOG / NUM_LOG_SPAN によるガード、無限ログ（LOGSECOND -1）の副作用まで含めた詳しい解説は、Zennのフル記事にまとめています。

関連: SQL0289N 表スペースに新しいページを割り当てられません ／ Db2 リカバリー履歴ファイルとアーカイブログ削除 ／ SQL0911N デッドロックとタイムアウトの切り分け

いざという時に迷わないためのバックアップ方式の選定とリカバリの手順を、本書 第4章「バックアップ・リカバリの鉄則」で体系化しています。