5.8 索引に対する自動メンテナンスの使用

索引の同期タスクを手動で管理するかわりに、自動メンテナンスを使用してCTX_DDL.SYNC_INDEX操作を自動化できます。

5.8.1 自動メンテナンスについて

自動メンテナンスを使用した索引は、ユーザーによる操作なしでバックグラウンドで同期されます。

概要

索引メンテナンスとは、DML操作の実行の結果として索引データ構造(インメモリーおよびディスク)を更新するプロセスです。

自動メンテナンスは、Oracle Database 23ai以降のリリースで作成されたOracle Text CONTEXTおよび検索索引(Oracle Text、JSONおよびXML検索索引)を同期するためのデフォルトの方法です。

自動メンテナンスと同期(SYNC)のどちらの方法でも、元表に対する保留中の更新、挿入および削除の処理を伴います。ただし、自動メンテナンスとSYNCの仕様は直交的です。自動メンテナンスでは、非同期メンテナンス・フレームワークを使用してバックグラウンドでSYNC操作が実行され、次の機能が提供されます:

  • 時間ベースまたは手動のSYNC操作がなくなる:

    自動メンテナンス・モードでは、IRnnバックグラウンド・プロセスにより、最適な方法で自動的に索引メンテナンス操作が実行されます。この機能では、最適な同期間隔が内部的に決定され(DML到着に基づく)、必要に応じてバックグラウンドのSYNC操作が自動的にスケジュールされます。自動決定された間隔はオーバーライドできません。

    このバックグラウンド・メカニズム・プロセスの詳細は、「非同期メンテナンス・フレームワーク」を参照してください。

  • バックグラウンド・ジョブの頻度を削減:

    データベース・スケジューラではなく、バックグラウンド・プロセスによって索引がメンテナンスされます。このバックグラウンド・メカニズムでは、各CTX_DDL.SYNC_INDEX操作が別々のイベント(同期ステージ)に分割され、必要な場合のみ各イベントが開始されます。

  • デフォルトのメンテナンス構成を提供します:

    これらの索引には、SYNCタイプの構成や同期間隔の設定は必要はありません。デフォルトでは、索引は自動メンテナンスとSYNC (MANUAL)の組合せで構成されます。これらの索引と互換性がある他のSYNC設定はありません。

    このモードではSYNC (MANUAL)の動作が異なることに注意してください。通常のSYNC (MANUAL)タイプ(索引を手動で同期する必要がある)とは異なり、ここではCTX_DDL.SYNC_INDEXは最適な間隔で自動的にバックグラウンドでコールされます。

自動メンテナンスを使用する理由とタイミング

索引の同期要件が明確でない場合や、多数の索引を最適な方法で同期させる必要がある場合は、自動メンテナンスを使用することをお薦めします。

このフレームワークを使用する利点は、索引の管理タスクが減ることに加え、DMLキューの追跡によって、バックグラウンドのSYNC操作を実行する必要があるタイミングが自動的に判別されることです。また、プラガブル・データベース(PDB)ごとに索引または索引パーティションごとに独立したジョブを作成するのではなく、任意の時点で実行される様々なバックグラウンド・ジョブの頻度をより詳細に制御できます。結果として、自動メンテナンスは、データベース・リソースでのワークロードを減らし、スケジューリングの競合をなくし、問合せのパフォーマンスを高めるために役立ちます。

自動バックグラウンド同期も有効にするSYNC (EVERY)では、interval-stringを使用して同期間隔を手動で指定する必要があります。SYNC (EVERY)を使用すると同期間隔を明示的に制御できますが、自動メンテナンスを使用するとデータベース・リソースを効率的に使用できます(特に複数のPDBをサポートしている場合)。また、SYNC (EVERY)では、ユーザーが推定した新規索引データ到着頻度に基づいて、バックグラウンド同期ジョブが過剰に起動される可能性があります。

手動メンテナンスとは

手動メンテナンスは、リリース23aiより前の同期動作を提供する非自動メンテナンス・モードです。

手動メンテナンス・モードでは、SYNC MANUALSYNC EVERY interval-stringSYNC ON COMMITなどのSYNCタイプを指定できます。MAINTENANCE MANUAL索引パラメータは、索引を手動メンテナンスに設定します。

新しいリリースにアップグレードした後も、既存の索引では、以前に指定した同期方法が引き続き使用されます。たとえば、Oracle Database 23aiにアップグレードした後に、既存の索引が、以前に指定したSYNC設定を使用して手動メンテナンスに設定されます。アップグレード前にSYNC設定を指定しなかった場合、索引では、デフォルトのSYNCタイプが使用されます。つまり、Oracle TextのCONTEXT索引の場合はSYNC MANUAL、JSONおよびXML検索索引の場合はSYNC ON COMMITです。必要な場合は、このような索引に対して自動メンテナンスを手動で有効にできます。

MAINTENANCEパラメータの構成方法

MAINTENANCEパラメータにより、索引のメンテナンス・タイプ(モード)を制御します。MAINTENANCEパラメータは、パーティションごとではなくグローバルに設定できます。つまり、索引に対して指定したメンテナンス・タイプは、すべての索引パーティションに適用されます。

サポートされているメンテナンス・タイプは次のとおりです。
  • MAINTENANCE AUTO (デフォルト): 索引を自動メンテナンスに設定します。

    デフォルトでは、索引の作成時に自動メンテナンスを構成する必要はありません。この例では、デフォルトの動作(PARAMETERS句なし)を持つJSON検索索引を作成します。
    CREATE SEARCH INDEX po_search_idx ON j_purchaseorder (po_document) 
        FOR JSON;
    この例では、PARAMETERS句を使用してMAINTENANCE AUTOを明示的に指定することで、JSON検索索引を作成します:
    CREATE SEARCH INDEX po_search_idx ON j_purchaseorder (po_document)
        FOR JSON PARAMETERS ('MAINTENANCE AUTO');
  • MAINTENANCE MANUAL: 索引を手動メンテナンスに設定します。

    この例では、PARAMETERS句を使用してMAINTENANCE MANUALを指定することで、新しいJSON検索索引の自動メンテナンスを無効にします:
    CREATE SEARCH INDEX po_search_idx ON j_purchaseorder (po_document)
        FOR JSON PARAMETERS('MAINTENANCE MANUAL');

これらのパラメータの構成の詳細は、「自動メンテナンスの有効化および無効化」を参照してください。

ALTER INDEXを使用して、自動メンテナンス・モードと手動メンテナンス・モードとを切り替えることができます。このコマンドでは同期オプションのみが変更されるため、索引を再構築する必要はありません。手動メンテナンスに設定されている場合、SYNCタイプを明示的に指定しないと、索引ではデフォルトのSYNCタイプが使用されます。

5.8.2 自動メンテナンスの要件および制限事項

自動メンテナンス・モードを使用する場合は、これらの要件および制限事項(データベースの互換性、サポートされているパラメータの組合せ、サポートされている索引など)を確認します。

  • 非同期メンテナンス・フレームワークのデータベース互換性は、Oracle Database 21.0.0.0以降です。

  • 自動メンテナンスと次のパラメータの組合せはサポートされていません:

    • FAST_QUERY

    • ASYNCHRONOUS_UPDATE

    • TRANSACTIONAL

    • SYNC (ON COMMIT)およびSYNC (EVERY)

    前述のいずれかの組合せを実行するとエラーが発生し、索引と互換性のあるモードを使用するよう求められます。

  • シャドウ索引は自動メンテナンスをサポートしていません。

5.8.3 非同期メンテナンス・フレームワーク

自動メンテナンス・モードでは、IRnnバックグラウンド・プロセスによって索引メンテナンス操作が実行されます。これにより、バックグラウンド・ジョブのスケーラビリティと、問合せのパフォーマンスが向上します。

メンテナンス・イベントのリスト

SYNC操作は、バックグラウンドで同時に実行できる別々のイベント(ステージ)からなります。

イベント 説明

SYNC-Mapping

(Sync-M)

$Bカタログ表を読み取って次のDocIDを見つけ、DocIDを各ROWIDに割り当てます。次に、$Cコミット・ジャーナルの内容を読み取り、それをROWIDでソートし、削除または追加する必要があるDocIDを決定します。次に、$Kマッピング表に対して削除と挿入を実行します。その後、削除したDocIDを$Nガベージ・コレクション表に追加します。最後に、$Cから読み取ったすべての行を削除します。

障害の発生中は、これらのイベントが再試行され、他のOracle Real Application Clusters (Oracle RAC)ノードにもブロードキャストされます。

SYNC-Mapping Timeout

(Sync-MT)

コミット時に生成される、Sync-Mタイムアウト・イベントを指定します。これらはタイムアウト・アクションによってのみ処理され、割り込みアクションでは処理されません。

タイムアウト中に、Sync-MTイベントがSync-Mイベントに変換されます。

SYNC-Ranges

(Sync-R)

ポスト・ステージのREADYとして、Sync-Mによって生成されたDocID範囲を割り当てます。使用可能なすべてのNEW範囲を読み取り、最初のDocIDの最小値、および最後のDocIDの最大値を特定します。次に、すべてのNEW範囲を削除し、同じサイズの多数のREADY範囲を挿入します。範囲のサイズは、索引または索引パーティションの各ドキュメントの平均サイズに基づいて決定されます。

障害の発生中は、これらのイベントが再試行され、他のRACノードにもブロードキャストされます。

SYNC-Scheduler

(Sync-S)

Sync-Rによって生成されたREADY範囲の数に基づいて、Sync-Pをスケジュールします。この値に応じて、シリアルSync-Pイベントか同時Sync-Pイベントをスケジュールします。

SYNC-Postings

(Sync-P)

新しい索引データを含むポスト・リストを生成します。Sync-Pは、READY範囲の取得から開始します。スケジューリングの間に、そのイベントを実行するワーカーの数を決定します。

Oracle RACシステムで、同時イベントが、SYNC-Postings同時 (Sync-PC)イベントとして実行するために他のノードにもブロードキャストされます。

障害の発生中は、Sync-Sイベントがスケジュールされて反復が増分されます。Oracle RACシステムで、失敗したSync-PCおよびSYNC-Postingsシリアル (Sync-PS)イベントが、Sync-PSイベントとしてブロードキャストされます。

SYNC-Postings Serial

(Sync-PS)

Sync-Pをシリアルに実行します。ポストはSGAバッチで生成されます。

SYNC-Postings Concurrent

(Sync-PC)

Sync-Pを同時に実行します。競合なしで複数の範囲を同時に独立して実行するようにスケジュールできます。

SYNC-Writer

(Sync-W)

ポスト・リストのSGAバッチをディスクに書き込みます。Sync-Wイベントは、それ自体と同時に実行できます。ただし、これらのイベントは、SYNC-Cleanupバッチ (Sync-C)とともに実行できません。

Sync-Wイベントは、それらを生成したノードにローカルなSGAバッチを処理するため、他のRACノードにブロードキャストされることはありません。

SYNC-Cleanup batches

(Sync-C)

障害のためにSGAバッチが関連付けられていない$B内のWRITE範囲をクリーン・アップします。これらのイベントは、以降のSync-Pの実行で再試行されます。

SYNC-Inspect

(Sync-I)

索引および索引パーティションを調べて($C表と$B表をチェックする)、イベントが欠落しているかどうかを確認します。

障害の発生中は、Sync-Iイベントは再試行されず、他のRACノードにブロードキャストされることもありません。

MONITOR

各索引または索引パーティションのSync-Iイベント、および各プラガブル・データベース(PDB)のECleanイベントをスケジュールします。スケジューラが実際のモニター・イベントをスケジュールし、それをさらにモニター・ワーカーが処理します。

EVENT Stats

(EStat)

ライター・ワーカー(Sync-Wイベント)によって処理される終了イベント。PDB内の完了したすべてのイベントについてイベント統計を書き込みます。

EVENT Stats Clean up

(EClean)

永続イベント統計(PDB固有のしきい値より古いもの)をディクショナリからクリーン・アップします。

OPTIMIZE-Scheduler Timeout

(Opti-ST)

Sync-Wイベントの順序完了後に発生する大きなポスト・リストのギャップに対処しないようにします。

OPTIMIZE-Scheduler

(Opti-S)

Sync-WイベントによるWRITE範囲の順不同処理によるポスト・リストでのギャップがない、最大DocIDのを特定します。

Opti-Sイベントは、Sync-Wイベントで$Bに格納された$Gトークンの数を集計し、その集計数がユーザー指定のしきい値に達するとOpti-Mイベントをスケジュールします。

OPTIMIZE-Merge

(Opti-M)

実際のMERGE操作を実行しない終了イベント。かわりに、DBMS_SCHEDULER最適化マージ操作をスケジュールします。

バックグラウンド・メカニズム・プロセス

メインのスケジューラ・バックグラウンド・プロセスでは、すべての索引によるワークロードが、事前定義された間隔(デフォルトでは3秒ごと)でチェックされます。その後、そのワークロードがワーカー・バックグラウンド・プロセスに割り当られます。それにより、イベントが1つずつ読み取られ、イベント・タイプに基づいて処理されます。索引は、ワーカー・プロセスでCTX_DDL.SYNC_INDEXが実行された直後に同期されます。スケジューラ・プロセスとワーカー・プロセスは別として、モニター・バックグラウンド・プロセスは、失われたイベントのリカバリに役立ちます。

CTX_DDL.SYNC_INDEXコールでは、次のステップが順番に実行されます:
  1. 索引または索引パーティションのすべての待機イベントをリセットします:

    イベントが失敗すると、そのイベントを待機キューに追加し、遅延時間を徐々に増分していきます。問題を修正しても、そのイベントは、現在の遅延時間が経過するまで待機し続けます。このような遅延時間を追跡するために、増分レベルで再試行イベントをスケジュールします。つまり、スケジューラ・プロセスが最初に再試行イベントをイベント・キューに移動します。スケジューラがそれをイベント・キューから待機キューに移動し、次に準備完了キューに移動し、最後にワーカー・プロセスに割り当てます。

    各イベントには、増分レベルに加え、再試行の反復があります。長期にわたる再試行では(つまり、再試行イベントがその元のイベントと同じでない場合)、レベルではなく反復を増分し、レベルを反復に初期化します。

    CTX_DDL.SYNC_INDEXでは、イベントをただちに強制的に再実行できます。それにより、関連するすべての待機キュー・イベントがイベント・キューに移動され、レベルと反復もリセットされます。イベントが再度失敗した場合は、初めの増分レベルまたは反復から再開します。

  2. フォアグラウンドでSync-Mを実行します:

    CTX_DDL.SYNC_INDEXは、バックグラウンド・メンテナンスが終了するまで待機します。ただし、すべてのイベントが終了するまで待機するのではなく、フォアグラウンドでSync-Mをコールし、割り当てられている最大DocIDを取得します。このDocIDを使用して、将来のすべてのイベントを無視します。

  3. SYNCの他のステージをバックグラウンドでスケジュールします。

    CTX_DDL.SYNC_INDEXは、スケジューラ・プロセスをポストして、保留中のイベントの処理をただちに開始できるようにします。

  4. バックグラウンド処理の完了まで待機します:

    この待機は、lockingパラメータがCTX_DDL.LOCK_WAITに設定されている場合はそれによって制御されます。他のすべての値については、CTX_DDL.SYNC_INDEXが、Sync-Mの完了後に返します。

    memoryparallel_degreemaxtimeおよびdirect_pathパラメータの値は無視されます。

    一部のバックグラウンド・イベントが遅延しているか完了できない場合、CTX_DDL.SYNC_INDEXはORA-30608を返し、カタログ・ビューにエラー・メッセージを記録します。

自動メンテナンスと手動メンテナンスのSYNC動作の違い

自動メンテナンスと手動メンテナンスの同期動作の違い、およびCTX_DDL.SYNC_INDEX操作の間に様々なイベントがどのように処理されるかを比較します:

動作 自動メンテナンス 手動メンテナンス

バックグラウンド・メカニズム

自動メンテナンス・モードでは、バックグラウンド・プロセスによって索引がメンテナンスされます。このバックグラウンド・メカニズムでは、各SYNC操作が別々のイベントに分割され、それらは必要に応じて互いに同時実行されます。

たとえば、Sync-SによってSync-Pが起動されて、Sync-RでREADY範囲が生成されたときのみ、新しい索引データが取得されます。

手動メンテナンス・モードでは、DBMS_SCHEDULERバックグラウンド・ジョブによって索引がメンテナンスされます。このバックグラウンド・メカニズムでは、すべての同期イベント(Sync-M、Sync-RおよびSync-P)が単一のSYNC操作としてまとめて実装されます。

SYNCタイプ

これらの索引は、自動メンテナンスとSYNC (MANUAL)の組合せで事前構成されています。

通常のSYNC (MANUAL)タイプ(CTX_DDL.SYNC_INDEXを手動でコールする必要がある)とは異なり、ここではCTX_DDL.SYNC_INDEXは最適な間隔で自動的にバックグラウンドでコールされます。

その他のSYNCタイプ(SYNC ON COMMITSYNC EVERYなど)は、自動メンテナンスではサポートされていません。

SYNC (MANUAL)SYNC (ON COMMIT)またはSYNC (EVERY)を実行すると、索引または索引パーティションごとにフォアグラウンドでSYNC操作が開始されます。

カタログ・ビュー

  • CTX_BACKGROUND_EVENTS

  • CTX_USER_BACKGROUND_EVENTS

  • V$TEXT_WAITING_EVENTS

  • CTX_AUTOSYNC_JOBS

  • CTX_AUTOSYNC_STATUS

  • CTX_USER_AUTOSYNC_JOBS

  • CTX_USER_AUTOSYNC_STATUS

5.8.4 自動メンテナンスの有効化および無効化

自動メンテナンスは、新しいOracle Text CONTEXTおよび検索索引に対してデフォルトで有効になっています。索引の作成時に自動メンテナンスを明示的に指定する方法、またはデフォルトの動作をオーバーライドしてかわりにSYNCを有効にするために無効にする方法について学習します。
  1. 新しい索引の自動メンテナンスを明示的に指定するには、CREATE INDEXまたはCREATE SEARCH INDEX文のPARAMETERS句でMAINTENANCE AUTOキーワードを使用します。
    • Oracle Text索引の場合:
      CREATE INDEX CTX_IDX ON CTX_TAB(DOC)
          INDEXTYPE IS CTXSYS.CONTEXT 
          PARAMETERS('MAINTENANCE AUTO');
    • Oracle Text検索索引の場合:
      CREATE SEARCH INDEX CTX_IDX ON CTX_TAB(DOC)
          PARAMETERS('MAINTENANCE AUTO');
    • JSON検索索引の場合:
      CREATE SEARCH INDEX JSON_IDX ON CTX_TAB(JSON_DOC) FOR JSON
          PARAMETERS('MAINTENANCE AUTO');
    • XML検索索引の場合:
      CREATE SEARCH INDEX XML_IDX ON CTX_TAB(XML_DOC) FOR XML
          PARAMETERS('MAINTENANCE AUTO');
  2. 新しい索引の自動メンテナンスを無効にするには、CREATE INDEX句またはCREATE SEARCH INDEX句でMAINTENANCE MANUALキーワードを使用します。

    これにより、索引が手動メンテナンスに設定されます。SYNCタイプを指定しない場合、索引ではデフォルトのSYNC設定が使用されます。たとえば、Oracle TextのCONTEXT索引の場合はSYNC MANUAL、JSONおよびXML検索索引の場合はSYNC ON COMMITです。

    • Oracle Text索引の場合:
      CREATE INDEX CTX_IND ON CTX_TAB(DOC) 
      INDEXTYPE IS CTXSYS.CONTEXT 
      PARAMETERS('MAINTENANCE MANUAL');
    • Oracle Text検索索引の場合:
      CREATE SEARCH INDEX CTX_IDX ON CTX_TAB(DOC)
          PARAMETERS('MAINTENANCE MANUAL');
    • JSON検索索引の場合:
      CREATE SEARCH INDEX JSON_IDX ON CTX_TAB(JSON_DOC) FOR JSON
          PARAMETERS('MAINTENANCE MANUAL');
    • XML検索索引の場合:
      CREATE SEARCH INDEX XML_IDX ON CTX_TAB(XML_DOC) FOR XML
          PARAMETERS('MAINTENANCE MANUAL');
  3. 手動メンテナンスに設定された索引のデフォルトのSYNC設定をオーバーライドするには、必要なSYNCタイプを指定します:
    • MANUAL: オンデマンドで手動で索引を同期します。

      たとえば:
      ALTER INDEX CTX_IDX REBUILD
          PARAMETERS(‘REPLACE METADATA MAINTENANCE MANUAL);
    • ON COMMIT: コミット直後に索引を同期します。

      たとえば:
      ALTER INDEX CTX_IDX REBUILD 
          PARAMETERS('REPLACE METADATA SYNC(ON COMMIT) MAINTENANCE MANUAL');
    • EVERY "interval-string": 定期的に索引を同期します。

      たとえば、20分ごとに開始します。
      ALTER INDEX CTX_IDX REBUILD 
          PARAMETERS('REPLACE METADATA SYNC(EVERY "freq=minutely;interval=20") MAINTENANCE MANUAL');

5.8.5 自動メンテナンスと手動メンテナンスの切替え

ALTER INDEXを使用すると、索引を再構築せずにMAINTENANCE AUTOMAINTENANCE MANUALを切り替えることができます。モードの変更中に、互換性のあるメンテナンス・タイプとSYNCタイプの組合せを指定する必要があります。

モード間の切り替えのガイドライン

  • MAINTENANCE AUTOは、SYNC (MANUAL)でサポートされています。デフォルトでは、自動メンテナンスを含むすべての索引がこの組合せで指定されます。

  • MAINTENANCE AUTOSYNC ON COMMITまたはSYNC (EVERY)の組合せはサポートされていません。SYNC (ON COMMIT)またはSYNC (EVERY)も使用する索引にMAINTENANCE AUTOを指定する場合は、最初にそのような索引をSYNC (MANUAL)に設定する必要があります。

  • 静的ディクショナリ・ビューCTX_USER_INDEXESには、現行ユーザーの既存のOracle Text CONTEXT索引および検索索引に関する情報が含まれています。たとえば、この問合せでは、MAINTENANCE AUTOに設定されたOracle Text索引のSYNCタイプとメンテナンス・タイプがリストされます。

    SQL> SELECT IDX_NAME, IDX_SYNC_TYPE, IDX_MAINTENANCE_TYPE FROM CTX_USER_INDEXES;
    
    IDX_NAME                IDX_SYNC_TYPE                IDX_MAINTENANCE_TYPE
    ----------------------- ---------------------------- ----------------------
    DOCIDX                  MANUAL                       AUTO
    

索引の自動メンテナンスへの切替え

この表では、索引をMAINTENANCE MANUALからMAINTENANCE AUTOに変更する、様々なSYNCタイプでのALTER INDEXの例を示します。

設定 メンテナンスおよびSYNCタイプ

SYNC (MANUAL)

変更後

MAINTENANCE AUTO

IDX_SYNC_TYPE: MANUAL

IDX_MAINTENANCE_TYPE: AUTO

ALTER INDEX CTX_IDX REBUILD
    PARAMETERS(‘REPLACE METADATA MAINTENANCE AUTO’);

SYNC ON COMMIT

変更後

MAINTENANCE AUTO

IDX_SYNC_TYPE: ON COMMIT

IDX_MAINTENANCE_TYPE: AUTO

ALTER INDEX CTX_IDX REBUILD
    PARAMETERS(‘REPLACE METADATA SYNC (MANUAL) MAINTENANCE AUTO’);

SYNC (EVERY)

変更後

MAINTENANCE AUTO

IDX_SYNC_TYPE: EVERY

IDX_MAINTENANCE_TYPE: AUTO

ALTER INDEX CTX_IDX REBUILD
    PARAMETERS(‘REPLACE METADATA SYNC (MANUAL) MAINTENANCE AUTO’);

索引の手動メンテナンスへの切替え

この表では、索引をMAINTENANCE AUTOからMAINTENANCE MANUALに変更する、様々なSYNCタイプでのALTER INDEXの例を示します。

設定 メンテナンスおよびSYNCタイプ

MAINTENANCE AUTO

変更後

SYNC (MANUAL)

IDX_SYNC_TYPE: MANUAL

IDX_MAINTENANCE_TYPE: MANUAL

ALTER INDEX CTX_IDX REBUILD
    PARAMETERS(‘REPLACE METADATA MAINTENANCE MANUAL);
CONTEXT索引のデフォルトのSYNCタイプはMANUALです。

MAINTENANCE AUTO

変更後

SYNC ON COMMIT

IDX_SYNC_TYPE: ON COMMIT

IDX_MAINTENANCE_TYPE: MANUAL

ALTER INDEX CTX_IDX REBUILD 
    PARAMETERS('REPLACE METADATA SYNC(ON COMMIT) MAINTENANCE MANUAL');

MAINTENANCE AUTO

変更後

SYNC (EVERY)

IDX_SYNC_TYPE: EVERY

IDX_MAINTENANCE_TYPE: MANUAL

ALTER INDEX CTX_IDX REBUILD
    PARAMETERS(‘REPLACE METADATA MAINTENANCE MANUAL);
ALTER INDEX CTX_IDX REBUILD 
    PARAMETERS(‘REPLACE METADATA SYNC(EVERY "freq=minutely;interval=20")’);

関連トピック

5.8.6 メンテナンス・イベントおよびエラーの監視

SYSユーザーとCTXSYSユーザーは、カタログ・ビューを問い合せて、自動メンテナンスを使用した索引に関するすべてのバックグラウンド・メンテナンス・イベントのステータスを監視できます。

自動メンテナンス・モードでは、索引は、ユーザーによる操作なしで非同期的にメンテナンスされます。CTXビューと動的パフォーマンス・ビューを定期的に調べて、完了したか遅延しているすべてのバックグラウンド・メンテナンス・イベントのステータスを把握することをお薦めします。

メンテナンス・イベントに関するデータおよびステータスの問合せ

次のビューを使用して、索引または索引パーティション・レベルでイベントを監視します:
  • CTX_BACKGROUND_EVENTS:

    このOracle Textビューには、SYSユーザーまたはCTXSYSユーザーのイベントの実行について履歴情報が表示されます。

  • CTX_USER_BACKGROUND_EVENTS:

    このOracle Textビューには、索引所有者に基づいて、現行ユーザーのイベントの実行について履歴情報が表示されます。

  • V$TEXT_WAITING_EVENTS:

    この動的パフォーマンス・ビューには、エラーや競合が原因で遅延しているか完了できないイベントについて履歴情報が表示されます。

たとえば、索引オブジェクトの番号と名前、索引所有者の番号と名前、元表(または表パーティション)のオブジェクトの番号と名前、イベントのタイプ(SYNC-PostingsSYNC-MappingSYNC-Rangesなど)、イベントのステータス(成功、実行中、失敗など)、再試行の反復のステータス(再試行の遅延、待機時間など)、イベントが待機を始めてからの経過時間、ログに記録されたエラー・メッセージなどを問い合せることができます。

エラーの処理

索引付けエラー(索引の失敗、イベントの遅延、イベントの再試行など)が発生すると、カタログ・ビューにエラーが記録されます。エラーは、直接はユーザーに報告されません。このようなエラーを確認し、次のように修正措置をとるには、ビューを定期的に問い合せる必要があります:
  • 一部のエラーは一時的なものであり、再試行したときには再現されません。このようなエラー・タイプの場合は、ユーザーによる操作は必要ありません。

  • 失敗したイベントの中には、再試行後に自動的に成功するものがあります。再試行イベントが成功しない場合は、別のイベントからそのイベントを再起動してみてください。

    たとえば、再試行後にSYNC-Postings (Sync-P)が失敗した場合は、システムでシリアル操作または同時操作をスケジュールできるように、SYNC-Scheduler (Sync-S)を再起動できます。Sync-Sが正常に完了すると、Sync-Pのキューがクリアされ、Sync-Pがただちに開始レベルで実行され、システムが過負荷になることはありません。

  • 定期的に再試行してもイベントが成功しない場合は、データベース管理者に連絡してください。

  • 定期的な再試行によるシステムの負荷を制限するために、連続的な再試行間の遅延時間が徐々に増分される場合があります。

    このような遅延時間を追跡するために、すべての再試行イベントが増分レベルでスケジュールされます。つまり、スケジューラ・プロセスが最初に再試行イベントをイベント・キューに移動します。スケジューラ・プロセスがそれをイベント・キューから待機キューに移動し、次に準備完了キューに移動し、最後にワーカー・プロセスに割り当てます。

    各イベントには、増分レベルに加え、再試行の反復があります。長期にわたる再試行では(つまり、再試行イベントがその元のイベントと同じでない場合)、レベルではなく反復が増分され、レベルが反復に初期化されます。

  • Oracle Real Application Clusters (Oracle RAC)システムでは、一部のノードでのみエラーが発生し、他のノードでは発生しない場合があります。このような場合にイベントが正常に完了するのは、そのイベントが他のノードに送信された場合のみです。