拡張ログ・スペース管理

拡張ログ・スペース管理 (ALSM) は、長期実行トランザクションがアクティブ・ログ・スペースを保持した結果として発生するログ・フル状態のエラー (SQL0964N) によって引き起こされるアプリケーション障害を最小限に抑えるのに役立ちます。 これは特に、長期実行トランザクションが、同時に実行されている他のトランザクションと比較して、トランザクション・ログ・データを多く生成しない場合に効果的です。 他のアプリケーションに影響を与えるログのフル状態を引き起こす可能性のある長期実行トランザクションの例を以下に挙げます。

• LOAD オペレーション (LOAD を使用する ADMIN_MOVE_TABLE を含む)。
• CREATE INDEX オペレーション。
• 未確定トランザクション。
• データベースの変更後に COMMIT または ROLLBACK を発行していないアイドル・アプリケーション。

クラッシュ・リカバリー

このフィーチャーは、クラッシュ・リカバリーを完全にサポートしています。 抽出ファイルが存在するときにデータベースの停止が発生した場合、抽出ファイルは、その後のクラッシュ・リカバリーの REDO フェーズおよび UNDO フェーズで使用されます。 これにより、以前にアーカイブされたログ・ファイルをアクティブなログ・パスに戻す必要がなくなるため、リカバリー・プロセスが加速します。 ディスク・エラーなどが原因で抽出ファイルを使用できない場合、以前にアーカイブされたログ・ファイルは通常どおりに取得され、クラッシュ・リカバリーでは取得されたログ・ファイルが代わりに使用されます。 クラッシュ・リカバリー中の抽出は、ランタイム規則と同様のスロットル規則によって制御されます。 ALSM は、クラッシュ・リカバリー中のトランザクション・ログまたはディスク・フルのエラーが原因で失敗しないようにあらゆる策を講じます。そのため、クラッシュ・リカバリーの REDO および UNDO フェーズでも新しい抽出ファイルが生成される可能性があります。

従来のオンライン・バックアップおよびリストア ( バージョン 11.5.6以降)

BACKUP

ログ・ファイルがバックアップ・イメージに含まれている場合、 Db2 は、バックアップ操作の終了を表すポイント・イン・タイムまでデータベースをリカバリーするのに適した範囲のログを組み込みます。 データベース・レベルのリカバリーの場合、これは、データベースの整合性が保証される最小の時点を表します。

バックアップ時に抽出ログ・ファイルが使用可能な場合、 Db2 は、上記のリカバリー・ポイントの約束を保証するイメージに含める抽出ログ・ファイルとアクティブ・ログ・ファイルの最適な組み合わせを選択します。

バックアップがオフラインの場合、または BACKUP コマンドで EXCLUDE LOGS パラメーターが指定されている場合、抽出ログ・ファイルはバックアップ・イメージに組み込まれません。

抽出ログ・ファイルのバックアップを試行中にエラーが発生した場合、 Db2 は問題のログ・ストリームの抽出ログ・ファイルのバックアップを停止します。 代わりに、失敗した範囲で始まるアクティブなログ・ファイルをバックアップします。

ALSM が構成されると、新しいバックアップ・オブジェクトはオンライン・バックアップ・イメージに含まれることに注意してください。 次の制限が適用されます。

• Db2 11.5.3 以前では、 Db2 11.5.6 以降で作成されたオンライン・バックアップ・イメージをリストアできません。
• Db2 11.5.4 および 11.5.5 は、 Db2 11.5.6 以降で作成されたオンライン・バックアップ・イメージをリストアできます。 復元時に、新しいオブジェクトは無視されます。

RESTORE

データベース・レベルのリストア操作の場合、バックアップ・イメージに抽出ログ・ファイルが含まれていると、 LOGTARGETパラメーターの設定に関係なく、抽出ログはアクティブ・ログ・ディレクトリーにリストアされます。

表スペース・レベルのリストア操作や、データをリストアしないリストア・タイプでは、抽出ログ・ファイルはリストアされません。 これには、RESTORE DB ... LOGS 形式のリストア操作も含まれます。

増分リストアや REBUILDなどのマルチステップ RESTORE 操作の場合、 Db2 は、後続のロールフォワード操作で使用できるように、正しいログ抽出ファイルがリストアされることを確認します。 実際には、これは増分リストアのターゲット・イメージになります。これは通常、データベースの再作成の一環でリストアされる最も古いイメージになります。

抽出ログ・ファイルをリストアできない場合は、リストア操作が続行されます。 ただし、 Db2 は、後続の ROLLFORWARD 操作の開始時に正しい範囲の抽出ログ・ファイルが存在することを検証できないため、問題のログ・ストリーム上のすべての抽出ログ・ファイルを削除します。 このため、ロールフォワード・ユーティリティーがデータベースのログ・アーカイブを使用できることを確認して、アクティブなログ・ファイルを使用できるようにすることが必要となります。 ログ・アーカイブが使用できない場合、またはNORETRIEVEオプションを使用してロールフォワード操作が実行される場合は、リカバリー・ログを手動で取得する必要があります。

オンラインの従来のバックアップおよびリストア ( バージョン 11.5.6より前)

従来のオンライン・バックアップでは、抽出ログ・ファイルはバックアップ・イメージに含まれません。 INCLUDE LOGSパラメーターでは、ログがバックアップ・イメージで必要な場合、ローカルで見つからなければアーカイブから取得されます。 抽出を使用すると、これにより、バックアップ・イメージに含める必要があるアクティブなログ・ファイルの範囲が拡大し、バックアップ・イメージのサイズが大きくなる可能性があります。

リストア後、ロールフォワードのためにログ・ファイルが必要であるにもかかわらず、ローカルで見つからないときには、必要なログ・ファイルが通常どおりアーカイブから取得されます。

オンラインのネイティブ・スナップショット・バックアップおよび復元

BACKUP コマンドで INCLUDE LOGS パラメーターを指定すると、抽出ログ・ファイルを含むアクティブ・ログ・パスがターゲット・スナップショット・イメージに組み込まれます。

データベースのロールフォワード

このフィーチャーは、データベースのロールフォワードを完全にサポートしています。 データベースのロールフォワード操作の開始時に抽出ファイルが存在する場合、それらの抽出ファイルは、データベースのロールフォワード操作の REDO および UNDO フェーズ中に使用されます。 これにより、以前にアーカイブされたログ・ファイルをアクティブなログ・パスに戻す必要がなくなるため、リカバリー・プロセスが加速します。 抽出ファイルが使用できない場合 (例えば、ディスク・エラーが原因で)、以前にアーカイブされたログ・ファイルは通常どおりに取得され (NORETRIEVEオプションが指定されていない場合)、データベースのロールフォワードでは、取得されたログ・ファイルが代わりに使用されます。 NORETRIEVEオプションが指定されている場合、データベース・ロールフォワード操作はアーカイブからログ・ファイルを取得しません。

データベースのロールフォワード中の抽出は、ランタイム規則と同様のスロットル規則によって制御されます。 ALSM は、データベースのロールフォワード中のトランザクション・ログまたはディスク・フルのエラーが原因で失敗しないようにあらゆる策を講じます。そのため、データベースのロールフォワードの REDO および UNDO フェーズでも新しい抽出ファイルが生成される可能性があります。 データベースのロールフォワード・オペレーション中にアクティブなログ・パスに存在するログ・ファイルと抽出ファイルの数は、ロールフォワード・ログ・ファイルの取得要件がランタイムの要件と異なるため、ランタイムの場合とは異なる可能性があります。

高可用性災害時リカバリー (HADR)

Db2 11.5.6以降、データベース・ロールフォワード・フィーチャーは HADR を使用するデータベースを完全にサポートします。 1 次データベースでは、ログの抽出は、スロットルと、抽出ログ・ファイルにアクセスできなくなった場合とで、同じランタイム規則に従います。 1 次データベースが ALSM 用に設定されている場合、スタンバイはこれと一致するように、ALSM を使用するように構成されている必要があります。

スタンバイ・データベースの場合、ログの抽出は 1 次データベースとは独立して動作します。 スタンバイ・ログの抽出の動作は、それが実行される構成済みの物理環境に基づいています。 ログの抽出は、スロットルと、抽出ログ・ファイルにアクセスできなくなった場合とで、同じデータベースのロールフォワード規則に従います。

ログ・スプーリングは、スタンバイ・データベースでは別の方法で処理されます。 hadr_spool_limitデータベース構成パラメーターに基づいて、ログ・スプーリング用のディスク・スペースを保護するためにログ抽出がスロットルされます。 hadr_spool_limitが固定値に設定されている場合、この規則により、ログ・スプーリングに必要なディスク・スペースが抽出によって使用されなくなります。 hadr_spool_limitが AUTOMATIC に設定され、ディスク・スペースが制限されている場合、この規則により、それ自体とログ・スプーリングの間でディスク・スペースを共有するように抽出が強制されます。 hadr_spool_limitが -1 に設定されている場合、この規則は抽出をスロットルしません。

1 次データベースとスタンバイ・データベース間で共有アーカイブを使用することをお勧めします。 まれに、ディスク・エラーなどが原因で抽出ログ・ファイルが使用できない場合は、以前にアーカイブされたログ・ファイルがアーカイブから取得され、テークオーバーに使用されます。 アーカイブされたログ・ファイルにアクセスできない場合、操作は失敗し、手動によるユーザー介入が必要になります。

表スペースのロールフォワード

表スペースのロールフォワード操作に必要なログ・レコードは、通常、ログのヘッドを含むログ・ファイル (例えば、 HeadExtentID) よりも古いため、ALSM は表スペースのロールフォワード操作には利点がありません。 ALSM はこの時点より前のデータを抽出しません。 表スペースのロールフォワード・オペレーションにアーカイブ・ログ・ファイルが必要な場合、ログ・ファイルは通常どおりアーカイブから取得されます。

ミラーリングされたデータベース (db2inidb)

このフィーチャーは、ミラーリングされたデータベースを完全にサポートしています。 AS SNAPSHOT オプションを指定して db2inidb コマンドを発行した場合、データベースはクラッシュ・リカバリーを受ける必要があります。 クラッシュ・リカバリーが開始される前に、ディスク上の抽出ファイルの完全性と正確性が検証されます。 これは、正しい数の抽出ファイルが存在し、それらが読み取り可能であり、一貫性を持っており、クラッシュ・リカバリーの目的で使用可能である点を確認します。 同様に、データベースをロールフォワード・ペンディング状態にする AS STANDBY または AS MIRROR オプションを指定して db2inidb コマンドを発行すると、同じ抽出ファイル検証が実行されます。

現在コミット済み

ALSM は、現在コミットされているフィーチャーを完全にサポートしています。 コミットされたバージョンの行がログ・バッファーに存在しない場合は、対応するログ・ファイルから行データを取得する必要があります。 目的のデータを含む抽出ログ・ファイルがある場合、データは抽出ログ・ファイルから読み取られます。 ディスクの問題などが原因で、抽出ログからの読み取りエラーが発生した場合、親アクティブ・ログ・ファイルは取得されません。 その場合は、行または表のロックを待機するデフォルトの動作に戻ります。

SET WRITE SUSPEND

ログ抽出の実行中に INCLUDE LOGS パラメーターを指定した SET WRITE SUSPEND コマンドを発行すると、ログ抽出は一時停止します。 データベースに対する I/O 書き込みが一時停止している間は、既存の抽出ファイルへの書き込み、抽出ファイルの新規作成、および既存の抽出ファイルの削除は行われません。 SET WRITE RESUME コマンドを発行した後、抽出が再開されます。 EXCLUDE LOGS パラメーターを使用して SET WRITE SUSPEND を発行しても、ログ抽出に影響はありません。これは、両方の機能が共存できるためです。

MIRRORLOGPATH を指定して構成されたデータベース

Db2 11.5.5以降、拡張ログ・スペース管理は、 MIRRORLOGPATHで構成されたデータベースの基本サポートを備えています。 このようなデータベースでは、アクティブ・ログ・パスまたはミラー・ログ・パスのいずれかにあるアクティブ・ログ・ファイルからログ・データを読み取ることができ、抽出されたログ・データをアクティブ・ログ・パスの下にある抽出ログ・ファイルに書き込むことができる限り、ログ抽出が行われます。

アクティブ・ログ・パスがアクセス不能になると、 SCAN_ERROR 状態が原因でログ抽出スキャンがスロットルされ、トランザクション・ログ・フル・エラーが発生する可能性があります。 アクティブ・ログ・パス・エラーが修正され、ログ抽出ゾーンが上に移動すると、ログ抽出スキャンが再開されます (「前の抽出エラー」セクションを参照)。 ロールバック、クラッシュ・リカバリー、またはデータベース・ロールフォワードが、アクセス不能なアクティブ・ログ・パスの下にある抽出ログ・ファイルから読み取る必要がある場合、親ログ・ファイルはアーカイブから取得され、ログ・データの読み取りに使用されます。 現在コミットされているスキャナーが、アクセス不能なアクティブ・ログ・パスの下にある抽出ログ・ファイルから読み取る必要がある場合、親ログ・ファイルは取得されません。 その場合は、行または表のロックを待機するデフォルトの動作に戻ります。

無限ロギング

ALSM は、無限ロギング (LOGSECOND = -1) で構成されたデータベースを完全にサポートします。 処理中のトランザクションに必要なログ・データはローカルで検出されるため、アーカイブからログ・ファイルを取得する必要のない、高速で信頼性の高いロールバックとクラッシュ・リカバリーが保証されます。 これは、ALSM より前の無限ロギングの動作に加えられた改善です。

無限ロギングは、トランザクション・ログがフル状態にならないように保証します。 スロットル (抽出率など) が原因で抽出スキャンが低速やアイドル状態になっている場合は、アクティブ・ログ・ファイルを新しいログ・データ用に再利用しないと、ログを抽出できないことがあります。 これは、構成されたログ・ファイル数に達した場合に生じます。 この場合、処理中のトランザクションに必要なログ・データがローカルで見つからない可能性があるため、ロールバックまたはクラッシュ・リカバリー用に、ログ・ファイルをアーカイブから取得しなければならないことがあります。 これを回避するには、 LOG_DISK_CAPを -1 または十分な大きさの値に設定して、追加のアクティブ・ログ・ファイルを作成できるようにします。 詳しくは、 log_disk_cap-アクティブ・ログ・スペース・ディスク容量構成パラメーターを参照してください。

MAX_LOG

MAX_LOGデータベース構成パラメーターは、トランザクションが消費できる 1 次ログ・スペースのパーセンテージに制限があるかどうか、およびその制限が何であるかを指定します。 ALSM をオンにすると、このパラメーターは以前と同様に動作します。

NUM_LOG_SPAN

NUM_LOG_SPANデータベース構成パラメーターは、1 つのトランザクションがスパンできるログ・ファイルの数に制限があるかどうか、およびその制限が何であるかを指定します。 このパラメーターを再検討し、対象トランザクションがロールバックされてからでなければ抽出を行えない値に設定されていないことを確認してください。

db2ReadLog API

db2ReadLog API は、指定された開始 LRI からすべてのログ・レコードを読み取る必要があるため、抽出ログ・ファイルはサポートされません。

オンライン索引作成

オンライン索引作成 (OLIC) 操作では、すべてのログ・レコードを読み取る必要があるため、抽出ログ・ファイルはサポートされません。

db2flsn

db2flsn ツールでは、抽出ログ・ファイルを使用して LSN をログ・ファイル番号にマップできます。 アクティブ・ログ・ファイルがローカルに存在しないものの抽出ログ・ファイルが存在する場合には、抽出ログ・ファイルの情報がマッピングに使用されます。

db2fmtlog

db2fmtlog ツールが更新され、抽出ログ・ファイルの内容が表示されるようになりました。 db2fmtlog -ログ・ファイル情報のフォーマット設定および表示コマンドを参照してください。

ディスク容量

ALSM は、抽出ログ・ファイルを格納するためにディスク・スペースを追加で消費します。 ALSM は、構成されたアクティブ・ログ・スペース (LOGPRIMARY、 LOGSECOND、およびLOGFILSIZデータベース構成パラメーター) で必要とされるスペースよりも多くの物理ディスク・スペースがある場合に最適です。 構成された量より 20% 以上多いディスク・スペースを確保することをお勧めします。 時間の経過とともに、このトピックで後述するモニター・ツールを使用して、LOGPRIMARY、LOGSECOND、および標準的なワークロードに最適なディスク・スペースの物理量を調整します。

ALSM では、以下の構成はサポートされません。

• 循環保存ロギングまたはログ保存ロギングを使用して構成されたデータベース (logarchmeth1 またはlogarchmeth2データベース構成パラメーターの少なくとも 1 つが OFF または LOGRETAIN 以外の値に設定されている必要があります)。
• IBM Db2 pureScale® 環境のデータベース。
• Db2 11.5.6より前のバージョンでは、データベースは高可用性災害時リカバリー (HADR) フィーチャーを使用して構成されていました。

新しいモニター・エレメントはすべて、SQL および db2pd -logs を介して使用できます。 以下のモニタリング・インターフェースが更新されました。詳しくは、各リンクをクリックしてください。

• MON_GET_TRANSACTION_LOG
• MON_GET_UNIT_OF_WORK
• MON_GET_UNIT_OF_WORK_DETAILS
• db2pd -logs
  次の 2 つの新しいフィールドを使用して、抽出の状態をモニターします。
  • Extraction Status
  • Current Log to Extract

ALSM が有効になっているかどうかを確認するには、次のコマンドを実行します。

db2pd -db sample -logs

Extraction Status             Active
Current Log to Extract        1038

以下は、ALSM が有効になっていないことを示しています。

Extraction Status            n/a
Current Log to Extract       n/a

抽出率によって、データベースのワークロードが、ALSM のメリットを享受できる理想的なモデルに適合するかどうかが決まります。 このモデルは、長時間実行されておりログ量の少ないいくつかのトランザクションと、短時間実行されている多数のトランザクションで構成されています。 抽出が有効化されて機能している場合、これは、分析されたログ・データの量を抽出されたログ・データの量と比較した結果に基づいて判別できます。

                SELECT log_extraction_written_bytes,
                       log_extraction_processed_bytes 
                FROM TABLE(MON_GET_TRANSACTION_LOG(-1)) as t

LOG_EXTRACTION_WRITTEN_BYTES LOG_EXTRACTION_PROCESSED_BYTES
---------------------------- ------------------------------
                       16589                         647632

前回のデータベースの活動化以降の、抽出ログの現在のディスク・スペース使用量と最高水準点を確認するには、次のようにします。

      SELECT log_extraction_processed_bytes AS processed_bytes,
      log_extraction_written_bytes AS written_bytes,
      log_extraction_disk_space_used_total AS disk_space_used_total,
      log_extraction_disk_space_used_total_top AS disk_space_used_total_top
      FROM TABLE(MON_GET_TRANSACTION_LOG(-1)) as t

PROCESSED_BYTES WRITTEN_BYTES DISK_SPACE_USED_TOTAL DISK_SPACE_USED_TOTAL_TOP
--------------- ------------- --------------------- -------------------------
         266882           165                 35165                     54461

抽出ログ・ファイルからの読み取り中にエラーが発生した場合、 Db2 は対応するアクティブ・ログ・ファイルからの読み取りを検索します。このログ・ファイルはローカルで検出されるか、アーカイブから取得されます。 このようなエラーでは、次の ADM メッセージが書き込まれます。

ADM1560W  Unable to read from extraction log file "<log-file-name>".

Explanation:

  Not able to read transaction log data from this file, either
  because the file is missing, or its content is not correct.
  This may result in retrieving of active log file(s) from archive.

User response:

  Investigate the cause of the failure by reviewing the Db2 diagnostic (db2diag) log file.

これが発生した場合は、 Db2 診断ログを db2pd -logs と組み合わせて使用すると、ログ抽出の詳細を判別するのに役立ちます。 ほとんどの場合、抽出スキャンは特定の理由でスロットルされます。 以下にいくつかの例を示します。

理由: ログのアーカイブの失敗

トランザクション・ログのフル・エラーが発生した時点で、Db2 診断ログが表示されます。

Active log S0001038.LOG has not been archived yet.
Active log S0001038.LOG has not been extracted from yet.

Current log extraction information:
          loggxLastProcessedLsn = 0000000000072FEE
          loggxLastProcessedLso = 78454802
     logExtractionCurrentExtNum = 1038
             logExtractionState = IDLE
          logExtractionFlushLsn = 0000000000000000
                 throttleReason = LOG_ARCHIVING

db2pd -logs コマンドを実行すると、「Extraction Status」が「Active」に設定されていることが示されますが、ログ・アーカイブ・メソッド 1 は、トランザクション・ログ・ファイル 1038 でエラー状態になっています。 これと同じファイルからの抽出が試行中でもあります。

Logs:
Current Log Number            1047
Pages Written                 0
Cur Commit Disk Log Reads     0
Cur Commit Total Log Reads    0
Method 1 Archive Status       Failure
Method 1 Next Log to Archive  1047
Method 1 First Failure        1038
Method 2 Archive Status       n/a
Method 2 Next Log to Archive  n/a
Method 2 First Failure        n/a
Extraction Status             Active
Current Log to Extract        1038
Log Chain ID                  0
Current LSO                   78605624
Current LSN                   0x00000000000735A6

Db2 診断ログのトランザクション・ログ・フル・エラーから逆方向に検索すると、ログ・アーカイブが失敗した理由が分かります。 アーカイブの問題を調べて解決すると、抽出が再開されます。

理由: ディスクがフル状態

トランザクション・ログのフル・エラーが発生した時点で、Db2 診断ログが表示されます。

Active log S0001051.LOG has not been extracted from yet.

Current log extraction information:
          loggxLastProcessedLsn = 0000000000073801
          loggxLastProcessedLso = 78666799
     logExtractionCurrentExtNum = 1051
             logExtractionState = IDLE
          logExtractionFlushLsn = 0000000000000000
                 throttleReason = DISK_FULL

db2pd -logs コマンドを実行すると、「Extraction Status」が「Active」に設定されていることが示されますが、「Current Log to Extract」は、アクティブ・ログ・パスの最初のアクティブ・ログと同じ値です。これは通常、抽出が停止していることを示します。

Logs:
Current Log Number            1060
Method 1 Archive Status       Success
Method 1 Next Log to Archive  1060
Method 1 First Failure        n/a
Extraction Status             Active
Current Log to Extract        1051
Current LSO                   78818610
Current LSN                   0x0000000000073E38

StartLSN         StartLSO  State      Filename
0000000000073802 78666801  0x00000000 S0001051.LOG

ディスク・スペースの問題が解決された時点で、抽出が再開されます。

理由: スキャン・エラー

トランザクション・ログ・フル・エラーの時点で、 Db2 診断ログは以下のように表示されます。

Active log S0001079.LOG has not been extracted from yet.

Current log extraction information:
          loggxScanStartExtNum = 1079
                       loggxScanStartLsn = 0000000000074AC5
               loggxMinLsnToStartOnError = 0000000000074AF3
              logExtractionCurrentExtNum = 1079
                      logExtractionState = ERROR
                   logExtractionFlushLsn = 0000000000000000
                          throttleReason = SCAN_ERROR

Db2 診断ログのトランザクション・ログ・フル・エラーから逆方向に検索すると、エラー戻りコードにリストされているスキャン・エラーの理由が分かります。

MESSAGE :ZRC=0xFFFFFFFF=-1

Log extraction scan error.
                   Function = sqlpshrScanNext
       File Array Element 0 = 1073
                Head Extent = 1050
          Group Head Extent = 1050
       loggxScanStartExtNum = 1079
          loggxScanStartLsn = 0000000000074AC5
  loggxMinLsnToStartOnError = 0000000000074AF3
   loggxLastProcessedExtNum = 1079
      loggxLastProcessedLsn = 0000000000074AF1
      loggxLastProcessedLso = 79139424
     loggxLastProcessedByte = 79139471
 logExtractionCurrentExtNum = 1079
logExtractionPendingReadLso = 79139471
       logExtractionReadLso = 79123332

スキャン・エラーがアクティブ・ログ・パスからの読み取りまたは書き込みによって引き起こされている場合は、1 つ以上のアクティブ・ログ・パスにアクセスでき、十分なストレージがあることを確認する必要があります。

ただしこのエラーが、解決できずに問題化している状況に関連している場合は、IBM サポートに連絡してください。 スキャン・エラーが解決されると、スキャンが再開されます。

理由: バッファー・プールのフラッシュの低速化

トランザクション・ログ・フル・エラーの時点で、 Db2 診断ログは以下のように表示されます。

Active log S0001060.LOG has not been extracted from yet.

Current log extraction information:
          loggxLastProcessedLsn = 0000000000073801
          loggxLastProcessedLso = 78666799
     logExtractionCurrentExtNum = 1060
             logExtractionState = IDLE
          logExtractionFlushLsn = 0000000000074801
                 throttleReason = SLOW_BP_FLUSH

db2pd -logs コマンドを実行すると、「抽出状況」が「アクティブ」に設定されているが、「抽出する現行ログ」がアクティブ・ログ・パス内の最初のアクティブ・ログと等しいことが示されます。これは通常、抽出が停止していることを示します。

スロットルの理由に、バッファー・プールのフラッシュの低速化が示されているため、次のコマンドを実行して、バッファー・プール内の最も古いダーティー・ページに属するログ・レコードの LSN を取得します。

db2pd -db sample -dirtypages | grep minbuflsn
minbuflsn               : 0000000000073802

この LSN を db2flsn に指定すると、このログ・レコードを含むログ・ファイルが判別されます。

db2flsn -db sample 0000000000073802
Given LSN is in log file S0001060.LOG

返されたログ・ファイルは、引き続き抽出する必要があるログ・ファイルと一致します。

低速バッファー・プール・フラッシュは、例えば、データベースの構成の誤り (PAGE_AGE_TRGT_MCRおよびPAGE_AGE_TRGT_GCRデータベース構成パラメーター)、またはデータベースにページをフラッシュするための呼吸ポイントを与えずに同じページに頻繁にアクセスして更新するトランザクションが原因で発生する可能性があります。 このような場合、手動の FLUSH BUFFERPOOLS ステートメントが役立つことがあります。