SQL0964Cとは何か？なぜ発生すると業務が止まるのか
Db2で発生する代表的な障害の1つが、SQL0964Cです。
これは単なる容量不足ではなく、ログに書き込めない状態を意味します。
ログは更新処理のたびに書き込まれるため、この状態になると以下が起きます。
・INSERT / UPDATE / DELETE がすべて失敗
・トランザクションが進まない
・結果として業務処理が停止する
つまり、ログフルは「性能問題」ではなく「サービス停止系の障害」です。
このため、原因と対処を理解していないと、復旧に時間がかかります。
トランザクションログがフルになる仕組み
ログフルは、単純にログファイルを使い切っただけでは発生しません。
ここでいう「ログ」とは、アクティブログ領域のことを指します。
Db2ではログは大きく以下の2つに分かれます。
・アクティブログ
・アーカイブログ
このうち、SQL0964Cに直接関係するのはアクティブログです。
ポイントは「アクティブログとして保持され続ける範囲」です。
Db2では以下の仕組みでログが管理されています。
・更新内容はアクティブログに書き込まれる
・コミットまたはロールバックで不要になったログが解放される
・最も古い未コミットトランザクション以降のログは保持され続ける
ここで重要なのは、ログは「未コミットの影響範囲」で解放可否が決まるという点です。
さらに内部的には、以下の2つのうち古い方で決まります。
・未コミットトランザクションの位置
・バッファープール上の未書き込みページ
結果として、
・長時間コミットしない処理
・大量更新を一括で実行する処理
があると、アクティブログは解放されず増え続けます。
そして、アクティブログ領域を使い切ったときにSQL0964Cが発生します。
原因① 長時間未コミットのトランザクション
最も多い原因はこれです。
長時間コミットされないトランザクションが存在すると、その時点より前のログはすべて保持されます。
結果として、
・ログが再利用されない
・新しいログが増え続ける
・最終的にログ領域が枯渇する
確認方法
まずは該当アプリケーションを特定します。
db2diag -g msg:=ADM1823E
出力例：
ADM1823E The active log is full and is held by application handle "504"
この「504」が原因のアプリケーションです。
補足として、スナップショットでも確認できます。
db2 get snapshot for database on <DB名>
原因② ログ容量そのものが不足している
もう1つの原因は、単純にログ容量が足りていないケースです。
特に以下のような処理で発生します。
・バッチで大量更新を行う
・一括INSERTを実行する
・REORGやLOADの実行
この場合はログ設定を確認します。
db2 get db cfg for <DB名>
確認ポイント：
| パラメータ | 内容 |
|---|---|
| LOGPRIMARY | 常時確保されるログ数 |
| LOGSECOND | 追加で生成されるログ数 |
| LOGFILSIZ | ログ1ファイルのサイズ |
ログ総容量 = (LOGPRIMARY + LOGSECOND) × LOGFILSIZ × 4KB
対応方法（即時対応と恒久対応）
ログフル対応は「即時対応」と「恒久対応」で分けて考える必要があります。
即時対応
まずはログを解放します。
・対象アプリケーションでコミット
・ロールバック
・強制終了
db2 "force application (504)"
これによりログが解放され、処理が再開できます。
ただし、業務影響があるため最後の手段です。
恒久対応① アプリケーション設計の見直し
根本対策はここです。
・一定件数ごとにコミットする
・長時間トランザクションを避ける
これは運用ではなく設計の問題です。
恒久対応② ログ容量の拡張
ログ容量を増やす方法です。
db2 update db cfg for <DB名> using LOGPRIMARY 20
db2 update db cfg for <DB名> using LOGFILSIZ 8192
また、即時回避としては以下が有効です。
db2 update db cfg using LOGSECOND 50 IMMEDIATE
ポイント：
・LOGSECONDは即時反映される
・LOGPRIMARYとLOGFILSIZは再活動化が必要
運用で重要なパラメータ（ログ暴走の防止）
ログフルは事前に防ぐことが重要です。
そのための制御パラメータがあります。
num_log_span
長時間コミットしない処理を強制終了します。
・指定ログ数を超えたらロールバック
・バッチ暴走対策として有効
max_log
1トランザクションあたりのログ使用量を制限します。
・異常に大きい処理を防止
・アプリ単位で制御できる
これらは「事故を止める仕組み」です。
実運用での判断ポイント
ログフルは原因によって対応が変わります。
| 状況 | 対応 |
|---|---|
| 特定アプリが原因 | コミット・強制終了 |
| バッチ処理で発生 | 分割・コミット頻度見直し |
| 常時発生 | ログ容量不足 |
| 突発的に発生 | 異常トランザクション |
重要なのは、ログを増やす前に原因を特定することです。
未コミットが原因の場合、容量を増やしても再発します。
他の運用との関係
ログフルは単体の問題ではありません。
以下とも密接に関係します。
・ログ管理
・バックアップ運用
・アーカイブログ設計
特にログの仕組みについては以下で整理しています。
・Db2のログと回復管理とは？トランザクションログの仕組みと実務運用を解説
・Db2のアーカイブログとは？切り替わるタイミングとコピーの仕組みを解説
ログの動きが理解できていないと、対応は場当たりになります。
まとめ
SQL0964Cは、Db2運用で避けて通れない障害です。
ポイントは以下です。
・原因の多くは未コミットトランザクション
・ログはコミットされるまで解放されない
・容量不足と設計不備を切り分けることが重要
対応としては、
・即時はアプリ停止やコミットで回避
・恒久は設計とログ容量の見直し
さらに、
・num_log_span
・max_log
を活用することで、再発防止が可能になります。
詳細仕様については、IBM公式情報もあわせて確認してください。
コメント