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) の古いほうで決定されます。
この文書では lowtranLSN によるログフルを念頭においていますが、大きな page_age_trgt_mcr もしくは softmax や、ページクリーナーの遅延でログフルが発生することもあります。

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

Answer

トランザクションのアクティブ・ログがフルになったときの対応として、(1) 最も古い未コミットのトランザクションをコミットまたはロールバックする、(2) ログ領域を拡張する、の 2 つの方法があります。
  1. 特定のトランザクションが長期間未コミットのままであり、アクティブ・ログを保持し続けている場合
    一時対応策として、最も古いアクティブ・ログを保留しているトランザクションを特定し、コミットによる確定またはロールバックによる変更の取り消しにより、アクティブ・ログを解放します。
    1. 最も古いアクティブ・ログを使用しているトランザクションを特定する
      db2diag.log 内で ADM1823E メッセージを探し、アプリケーション・ハンドル (番号) を確認します。
      $ db2diag -g msg:=ADM1823E
      
      2020-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.200610035141
      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 を参照してください。
    2. 対応方法
      • 一時策
        上記手順 1 で確認したアプリケーション ID を元に、以下のいずれかの方法で未コミット状態から復旧します。
        1. 該当アプリケーションでコミットを行う
        2. 該当アプリケーションでロールバックを行う
        3. force application コマンドで該当アプリケーションを強制終了する
          例としてアプリケーション・ハンドル 504 (0-504 の場合でも 504を指定します) を終了する場合
          db2 "force application (504)"
          注: 最初のログを保持しているアプリケーションが db2reorg や db2acd などのシステム・アプリケーションの場合、force application は有効になりません。この場合、システム・アプリケーションがロック待機によりログを解放できないことが原因の場合があるため、db2pd -wlock -alldbs を実行してロック待機の原因になっているアプリケーションを特定し、これを force application してください。
      • 恒久策(1)
        より頻繁にコミットまたはロールバックを行うようアプリケーションを改修してください。
      • 恒久策(2)
        (Db2 11.5.4 以降のみ) 拡張ログ・スペース管理 (ALSM) を有効にすると長期間コミットしないアプリケーションが保持するアクティブ・ログを切り離してログ・フルを回避できます。
        ALSM は以下の設定で有効化できます。設定の反映にデータベースの再活動化が必要です。
        db2set DB2_ADVANCED_LOG_SPACE_MGMT=ON
  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. 対応方法
      • ログ・ファイル・サイズ (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 テクニカル・サポートへお問い合わせください。
Db2 テクニカル・サポート

[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[{"code":"a8m500000008PmcAAE","label":"Recovery-\u003ELogging"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Historical Number

F5086ACC4565317D492577D80019C028

Document Information

Modified date:
15 August 2023

UID

jpn1J1003917