IBM Support

[Db2] トランザクション・ログがフル (SQL0964C) になったときの対応 (IM-10-00W)

Question & Answer


Question

「トランザクション・ログがいっぱいです」というエラーが表示され SQL 処理が失敗します。対応方法について教えてください。
[メッセージ出力例]
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドではないため、SQLステートメントとして処理されました。
SQL処理中に、そのコマンドが返されました。
SQL0964C データベースのトランザクション・ログがいっぱいです。 SQLSTATE=57011
[db2diag.log 出力例 (抜粋)]
MESSAGE: ADM1823E The active log is full and is held by application handle "番号".
Terminate this application by COMMIT, ROLLBACK or FORCE APPLICATION.
RETCODE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
"Log file has reached its saturation point" DIA8309C Log file was full.

Cause

DB2では、データベース毎にトランザクション・ログと呼ばれる復旧用のログを保持しています。

ログにはアクティブ・ログとアーカイブ・ログの2種類が存在します。
トランザクションの実行中、現行トランザクションのロールバックまたはリカバリーに必要な情報として、データベースへの更新がアクティブ・ログに記録されていきます。
このとき、最も古い未コミットのトランザクション以降のログが、アクティブ・ログとして保持されます。コミットもしくはロールバックが実行されてログが解放されるまで、アクティブ・ログは増加し続けます。

注:最も古いアクティブログは、最も古い未コミットのトランザクション (lowtranLSN) もしくは、バッファープール上の最も古いダーティ・ページ (minbufLSN) の古いほうで決定されます。
この FAQ では lowtranLSN によるログフルを念頭においていますが、大きな SOFTMAX やページクリーナーの遅延でログフルが発生することもあります。

メッセージ ADM1823E は、アクティブ・ログの領域を使い尽くし、これ以上更新情報を書き込めない状態を表しています。
新たにログを書き込めないため、更新 SQL は実行できません。

Answer

トランザクションのアクティブ・ログがフルになったときの対応として、(1) 最も古い未コミットのトランザクションをコミットまたはロールバックする、(2) ログ領域を拡張する、の 2 つの方法があります。

1. 特定のトランザクションが長期間未コミットのままであり、アクティブ・ログを保持し続けている場合

一時対応策として、最も古いアクティブ・ログを保留しているトランザクションを特定し、コミットによる確定またはロールバックによる変更の取り消しにより、アクティブ・ログを解放します。

1.1. 最も古いアクティブ・ログを使用しているトランザクションを特定する

db2diag.log 内で ADM1823E メッセージを探し、アプリケーション・ハンドル (番号) を確認します。
2010-06-10-12.51.38.458559+540 E1722296A538     LEVEL: Error
PID     : 4391056              TID  : 1         PROC : db2agent (SAMPLE) 0
INSTANCE: db2inst1             NODE : 000       DB   : SAMPLE
APPHDL  : 0-123                APPID: *LOCAL.db2inst1.100610035141
AUTHID  : DB2INST1
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:2860
MESSAGE : ADM1823E  The active log is full and is held by application handle
          "504".  Terminate this application by COMMIT, ROLLBACK or FORCE
          APPLICATION.
上記の例では "504" が最も古いアクティブ・ログを使用しているトランザクションのアプリケーション・ハンドルです。
0-504 のようにパーティション番号とアプリケーション・ハンドルがセットで出力されることがあります。
ADM1823E メッセージが多数記録されていて、かつ、継続して同じアプリケーション・ハンドルである場合、このトランザクションが未コミットのまま長期間完了しないことが原因です。

注: APPHDL の番号と、ADM1823E で表示されるアプリケーション・ハンドルが同一の場合、このアプリケーション自身が大量のトランザクション・ログを生成していることになります。

長期間コミットしないアプリケーションや、大量のログを生成するアプリケーションによるログフルが発生は、
num_log_span および max_log データベース構成パラメーターで抑制できます。
詳細は「運用上の考慮点」を参照してください。

最も古いトランザクションを保留しているアプリケーション ID は、データベース・スナップショットからも確認できます。
  • db2 GET SNAPSHOT FOR DATABASE ON DB名

    最も古いトランザクションを保留しているアプリケーション ID = 504

    最初のアクティブ・ログのファイル番号                     = 0
    最後のアクティブ・ログのファイル番号                     = 2
    現在のアクティブ・ログのファイル番号                     = 0

注: ADM1823E にアプリケーション・ハンドルの番号が記録されていない場合、未確定トランザクションによるログ・フルの可能性があります。その場合は以下の FAQ を参照してください。
[DB2 LUW] 未確定トランザクション (indoubt transaction) の回復方法

1.2. 対応方法
  • 一時策
    上記手順 1.1 で確認したアプリケーション ID を元に、以下のいずれかの方法で未コミット状態から復旧します。
    1. コミット処理
    2. ロールバック処理
    3. force application による強制終了
      例としてアプリケーション・ハンドル 504 (0-504 の場合でも 504を指定します) を終了する場合
      db2 "force application (504)"
      注: 最初のログを保持しているアプリケーションが db2reorg や db2acd などのシステム・アプリケーションの場合、force application は有効になりません。この場合、システム・アプリケーションがロック待機によりログを解放できないことが原因の場合があるため、db2pd -wlock -alldbs を実行してロック待機の原因になっているアプリケーションを特定し、これを force application してください。
       
  • 恒久策
    もっと頻繁にコミット処理を行うようアプリケーションを見直してください。

2. 大量のトランザクションが実行中であり、ログの領域が不足している場合

ログファイル・サイズまたはファイル数を増やすことにより、アクティブ・ログの領域を拡張します。
注:永遠にコミットしないアプリケーションが存在する場合、この対応は意味がありません。

2.1. 現在のログ設定を確認する
db2 get db cfg for [DB名]
以下の構成パラメーターを確認します。
ログ・ファイルのサイズ (4KB) (LOGFILSIZ) 
1 次ログ・ファイルの数      (LOGPRIMARY)
2 次ログ・ファイル数        (LOGSECOND)
  :
ログ・ファイルのパス
各パラメーターの意味は以下の通りです。
  • 1 次ログ・ファイルの数: LOGPRIMARY
    1 次ログ・ファイルの数です。
    データベースの活動化 (activate) 時に一括して用意されます。
    通常稼働時は、この 1 次ログにおさまるよう設定しておくことが推奨されます。
  • 2 次ログ・ファイル数: LOGSECOND
    2 次ログ・ファイルの数です。
    1 次ログがすべてアプリケーションによって使用され再利用できない時、必要になる度に 1 つずつ生成されます。
    コミットされていない処理が一時的に大量発生するときに備えた値を設定しておきます。
    この 2 次ログファイルも使い尽くしたときにトランザクションログ・フルとして検知されます。
  • ログファイル・サイズ: LOGFILSIZ
    1 次ログおよび 2 次ログの 1 ファイルのサイズをページ数で指定します。1 ページは 4 KB です。
  • ログ・ファイルのパス
    1 次ログ・ファイルおよび 2 次ログ・ファイルが保管されるディレクトリー名です。
    データベースが使用できるトランザクション・ログのスペースは、以下の式で算出できます。
    「ログ・ファイルのパス」に配置されますので、ディスクに空きスペースがあるかご確認ください。
    	(LOGPRIMARY + LOGSECOND) * LOGFILSIZ * 4KB
2.2. 対応方法
  • ログ・ファイル・サイズ (LOGFILSIZ) を大きくする場合
     db2 update db cfg for [DB名] using LOGFILSIZ [新しい値]
  • ログ・ファイルの数 (LOGPRIMARY / LOGSECOND) を増やす場合
    • 1 次ログ・ファイルの個数を増やす場合
      db2 update db cfg for [DB名] using LOGPRIMARY [新しい値]
    • 2 次ログ・ファイルの個数を増やす場合 (即時反映)
      db2 connect to [DB名]
      db2 update db cfg using LOGSECOND [新しい値] IMMEDIATE

      補足:
      LOGSECOND は変更後に即時反映されます。LOGPRIMARY および LOGFILSIZ は、変更を反映するためには該当のデータベースの再活動化が必要となります。
      このため、既存のアプリケーションに極力影響を与えずにログフルを回避したい場合は LOGSECOND を増やしてください。

運用上の考慮点

長期間コミットしないアプリケーションによるログフルを未然に防止するには、num_log_span データベース構成パラメーターの設定を検討してください。num_log_span で指定されたログ数にわたってコミットを行わないアプリケーションは、データベース・マネージャーによってロールバックと切断が行われます。
num_log_span - ログ・スパンの数構成パラメーター

単一のアプリケーションが大量のログを生成することによるログフルを未然に防止するには max_log データベース構成パラメーターの設定を検討してください。
max_log で指定された量を超えるログを生成したアプリケーションは、データベース・マネージャーによってロールバックと切断が行われます。
max_log - トランザクション当たりの最大ログ構成パラメーター

パフォーマンスの観点から、通常稼働中に 2 次ログ・ファイルを生成させないよう、1 次ログ・ファイル数を増やしておくことが推奨されます。
なお、1 次ログはデータベースの活動化時に一括してファイルを用意するため、活動化にかかる時間が増えることに注意してください。

関連情報
パスポート・アドバンテージによく寄せられる質問
[DB2 LUW] トランザクション・ログの使用量を見積もる方法
[DB2 LUW] 大量の行を削除する時のログ量を減らす方法

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Component":"Not Applicable","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.5;9.7;10.1;10.5;11.1;11.5","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Historical Number

F5086ACC4565317D492577D80019C028

Document Information

Modified date:
06 August 2020

UID

jpn1J1003917