この記事はLudovico CaldaraによるAuto Redo Prioritization: helping manage redo generation spikesを日本語に翻訳したものです。

2026年8月17日

ビジネスクリティカルなアプリケーションでは、予測可能なデータベース応答時間と、データ損失のリスクを最小限に抑えたData Guardによる保護が不可欠です。Redo生成量が突然急増すると、プライマリ・データベースでログ・バッファ領域の逼迫が発生し、顧客向けセッションに影響を及ぼす可能性があります。また、非同期スタンバイ・データベースへの転送ラグが増加し、目標とするリカバリ要件に影響する可能性もあります。

このような状況に自動的に対応するため、Oracle AI Database 26ai Release Update 23.26.3では、Auto Redo Prioritization機能が導入されました。ログ・バッファの空き領域が逼迫した場合に、この機能により負荷を軽減します。また、非同期REDO転送のラグ(遅延)が設定された目標値を超えた場合には、ラグを低減し、スタンバイをプライマリにより近い状態に維持します。

この仕組みを実現するため、Oracle AI Database 26aiでは、問題となる状態が継続している間、バッチ処理のような挙動を示すセッションからのRedo生成量を削減することで、Redoの優先順位付けを行います。OLTPセッションはこの優先制御による直接的な影響を受けません。また、バッチ処理によるRedo生成量が削減されることで、その副次的な効果としてOLTPセッションのパフォーマンスが最終的に改善される可能性があります。

Auto Redo Prioritizationが重要な理由

既存のResource Manager の機能では、管理者が定義したワークロード分類やポリシーに基づいてワークロードの動作を制御できます。しかし、変化するRedo生成状況に応じて自動的に適応することはできません。多くの環境では、事前にワークロードを明確に分離することが現実的ではない、あるいは不可能な場合があります。これは、エンタープライズ・アプリケーションでは、オンライン・トランザクション処理（OLTP）、バッチ処理、データ取り込み（Data Ingestion）、メンテナンス処理などで、同じサービスやデータベース・ユーザーを共有する場合があるためです。

Auto Redo Prioritizationは、このように複数の種類が混在し、かつ状況が変化するワークロードを想定して設計されています。管理者がRedo生成元をすべて事前に特定・分類する必要はありません。現在のRedoの状況に応じて動作し、必要な場合にのみRedoの優先制御を適用します。

ログ・バッファ領域の逼迫時にOLTPの応答性を保護

Auto Redo Prioritizationの機能の1つは、REDOログ・バッファ領域の逼迫に対応するものです。

セッションがlog bugger space wait イベントで待機し始めると、OLTPアプリケーションの応答時間に影響する可能性があります。ログ・バッファ領域に対するRedo Prioritizationを有効にすると、Oracle AI DatabaseはRedoログ・バッファの使用状況を継続的に監視します。空き領域がしきい値を下回ると、Redo Prioritizationが適用され、Redo関連リソースをOLTPワークロードがより利用しやすい状態にします。非OLTP REDO生成がログ・バッファ領域不足の原因となっている場合、これにより、オンライン・トランザクションがREDO要求の増加期間中の一貫した進行を実現できます。潜在的な利点には、OLTPスループットの向上と、より予測可能なレスポンス時間が含まれます。

この機能は、動的初期化パラメータLOG_REDO_PRIORITIZATIONを使用して有効にします。

ALTER SYSTEM SET LOG_REDO_PRIORITIZATION = TRUE;

このパラメータのデフォルト値はFALSEです。設定値の有効化にインスタンスの再起動は不要で、Oracle RAC環境では各インスタンスに対して個別に設定できます。

Auto Redo Prioritizationは、通常のRedoのチューニングに代わるものではありません。Redoログのサイジング、ストレージ性能、ログ・バッファの構成、ワークロード・デザインなどは、引き続き重要です。この機能は、それらに代わるものではなく、混在ワークロードにおいて一時的なログ・バッファの競合が発生した際に利用できる追加の保護メカニズムとして提供されます。

非同期スタンバイをプライマリに近い状態に維持する

Auto Redo Prioritizationは、これと密接に関連するData Guardの問題にも対応します。それが、非同期フィジカル・スタンバイ・データベースにおける転送ラグです。

非同期Redo転送は、リモート・スタンバイへの通信レイテンシにプライマリ・データベースのコミット・レイテンシを依存させず、アプリケーション側でプライマリ・データベースの性能を確保する必要がある場合に、適切な選択となることがよくあります。しかし、Redo生成量が突然増加すると、一時的にRedo転送のスループットを上回る可能性があります。転送ラグが増加すると、スタンバイ・データベースの状態はプライマリ・データベースの最新状態からさらに遅れることになり、潜在的なデータ損失のリスクも増加します。

転送ラグベースのRedoの優先順位付けでは、非同期フィジカル・スタンバイの宛先に対して、しきい値となる転送ラグを定義します。転送ラグがそのしきい値を超えると、REDO転送がResource Managerに通知し、Resource ManagerがRedoの優先順位を適用します。

しきい値は、LOG_ARCHIVE_DEST_nのREDO_PRIORITIZATION_WHEN_TRANSPORT_LAGS_BY_SEC属性を使用して設定します。

ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 =
  'SERVICE=boston ASYNC NOAFFIRM
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=boston
   REDO_PRIORITIZATION_WHEN_TRANSPORT_LAGS_BY_SEC=20';

0以外の値を指定すると、非同期フィジカル・スタンバイの宛先に対してこの機能が有効になります。デフォルト値である0を指定した場合、この機能は無効になります。

Oracle Data Guard Broker構成の場合は、新しいメンバー・プロパティであるAdditionalLadAttributesを使用して、ログ・アーカイブ宛先属性を追加します。

EDIT DATABASE newyork SET PROPERTY
   AdditionalLadAttributes='REDO_PRIORITIZATION_WHEN_TRANSPORT_LAGS_BY_SEC=20';

これにより、非OLTPワークロードによってREDO生成量が急増した場合でも、非同期スタンバイをプライマリに近づけた状態を維持することができます。重要な点として、Auto Redo Prioritizationは、OLTP挙動を示すセッションには影響を与えず、バッチ挙動を示すセッションにのみ影響します。したがって、OLTPセッションによって発生するREDOの急増は、依然として転送遅延を増加させる可能性があります。

転送ラグをFastStartFailoverLagLimitとして使用しているFast-Start Failover (FSFO)環境では、Auto Redo Prioritizationの転送ラグのしきい値をFSFO Lag Limitよりも低い値に設定することができます。こうすることで、転送ラグがFSFO Limitに到達する前に、プライマリ・データベース側でRedo生成量を削減する機会が得られます。

まとめ

Auto Redo Prioritization 機能は、Oracle AI Database 26aiリリース更新23.26.3以降で使用可能であり、2つの独立した保護手段が提供されます。

  • LOG_REDO_PRIORITIZATIONを有効にすることで、REDOログ・バッファの負荷が発生したときにOLTPの応答性を保護するのに役立ちます。
  • ASYNC(非同期) フィジカル・スタンバイの宛先にREDO_PRIORITIZATION_WHEN_TRANSPORT_LAGS_BY_SECを構成することで、非同期Data Guardトランスポート・ラグを削減できます。