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 MANUAL、SYNC EVERY interval-string、SYNC 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-M) |
$Bカタログ表を読み取って次のDocIDを見つけ、DocIDを各ROWIDに割り当てます。次に、$Cコミット・ジャーナルの内容を読み取り、それをROWIDでソートし、削除または追加する必要があるDocIDを決定します。次に、$Kマッピング表に対して削除と挿入を実行します。その後、削除したDocIDを$Nガベージ・コレクション表に追加します。最後に、$Cから読み取ったすべての行を削除します。 障害の発生中は、これらのイベントが再試行され、他のOracle Real Application Clusters (Oracle RAC)ノードにもブロードキャストされます。 |
|
(Sync-MT) |
コミット時に生成される、Sync-Mタイムアウト・イベントを指定します。これらはタイムアウト・アクションによってのみ処理され、割り込みアクションでは処理されません。 タイムアウト中に、Sync-MTイベントがSync-Mイベントに変換されます。 |
|
(Sync-R) |
ポスト・ステージの 障害の発生中は、これらのイベントが再試行され、他のRACノードにもブロードキャストされます。 |
|
(Sync-S) |
Sync-Rによって生成された |
|
(Sync-P) |
新しい索引データを含むポスト・リストを生成します。Sync-Pは、 Oracle RACシステムで、同時イベントが、 障害の発生中は、Sync-Sイベントがスケジュールされて反復が増分されます。Oracle RACシステムで、失敗したSync-PCおよび |
|
(Sync-PS) |
Sync-Pをシリアルに実行します。ポストはSGAバッチで生成されます。 |
|
(Sync-PC) |
Sync-Pを同時に実行します。競合なしで複数の範囲を同時に独立して実行するようにスケジュールできます。 |
|
(Sync-W) |
ポスト・リストのSGAバッチをディスクに書き込みます。Sync-Wイベントは、それ自体と同時に実行できます。ただし、これらのイベントは、 Sync-Wイベントは、それらを生成したノードにローカルなSGAバッチを処理するため、他のRACノードにブロードキャストされることはありません。 |
|
(Sync-C) |
障害のためにSGAバッチが関連付けられていない$B内の |
|
(Sync-I) |
索引および索引パーティションを調べて($C表と$B表をチェックする)、イベントが欠落しているかどうかを確認します。 障害の発生中は、Sync-Iイベントは再試行されず、他のRACノードにブロードキャストされることもありません。 |
|
|
各索引または索引パーティションのSync-Iイベント、および各プラガブル・データベース(PDB)のECleanイベントをスケジュールします。スケジューラが実際のモニター・イベントをスケジュールし、それをさらにモニター・ワーカーが処理します。 |
|
(EStat) |
ライター・ワーカー(Sync-Wイベント)によって処理される終了イベント。PDB内の完了したすべてのイベントについてイベント統計を書き込みます。 |
|
(EClean) |
永続イベント統計(PDB固有のしきい値より古いもの)をディクショナリからクリーン・アップします。 |
|
(Opti-ST) |
Sync-Wイベントの順序完了後に発生する大きなポスト・リストのギャップに対処しないようにします。 |
|
(Opti-S) |
Sync-Wイベントによる Opti-Sイベントは、Sync-Wイベントで$Bに格納された$Gトークンの数を集計し、その集計数がユーザー指定のしきい値に達するとOpti-Mイベントをスケジュールします。 |
|
(Opti-M) |
実際の |
バックグラウンド・メカニズム・プロセス
メインのスケジューラ・バックグラウンド・プロセスでは、すべての索引によるワークロードが、事前定義された間隔(デフォルトでは3秒ごと)でチェックされます。その後、そのワークロードがワーカー・バックグラウンド・プロセスに割り当られます。それにより、イベントが1つずつ読み取られ、イベント・タイプに基づいて処理されます。索引は、ワーカー・プロセスでCTX_DDL.SYNC_INDEXが実行された直後に同期されます。スケジューラ・プロセスとワーカー・プロセスは別として、モニター・バックグラウンド・プロセスは、失われたイベントのリカバリに役立ちます。
CTX_DDL.SYNC_INDEXコールでは、次のステップが順番に実行されます:
-
索引または索引パーティションのすべての待機イベントをリセットします:
イベントが失敗すると、そのイベントを待機キューに追加し、遅延時間を徐々に増分していきます。問題を修正しても、そのイベントは、現在の遅延時間が経過するまで待機し続けます。このような遅延時間を追跡するために、増分レベルで再試行イベントをスケジュールします。つまり、スケジューラ・プロセスが最初に再試行イベントをイベント・キューに移動します。スケジューラがそれをイベント・キューから待機キューに移動し、次に準備完了キューに移動し、最後にワーカー・プロセスに割り当てます。
各イベントには、増分レベルに加え、再試行の反復があります。長期にわたる再試行では(つまり、再試行イベントがその元のイベントと同じでない場合)、レベルではなく反復を増分し、レベルを反復に初期化します。
CTX_DDL.SYNC_INDEXでは、イベントをただちに強制的に再実行できます。それにより、関連するすべての待機キュー・イベントがイベント・キューに移動され、レベルと反復もリセットされます。イベントが再度失敗した場合は、初めの増分レベルまたは反復から再開します。 -
フォアグラウンドでSync-Mを実行します:
CTX_DDL.SYNC_INDEXは、バックグラウンド・メンテナンスが終了するまで待機します。ただし、すべてのイベントが終了するまで待機するのではなく、フォアグラウンドでSync-Mをコールし、割り当てられている最大DocIDを取得します。このDocIDを使用して、将来のすべてのイベントを無視します。 -
SYNCの他のステージをバックグラウンドでスケジュールします。CTX_DDL.SYNC_INDEXは、スケジューラ・プロセスをポストして、保留中のイベントの処理をただちに開始できるようにします。 -
バックグラウンド処理の完了まで待機します:
この待機は、
lockingパラメータがCTX_DDL.LOCK_WAITに設定されている場合はそれによって制御されます。他のすべての値については、CTX_DDL.SYNC_INDEXが、Sync-Mの完了後に返します。memory、parallel_degree、maxtimeおよびdirect_pathパラメータの値は無視されます。一部のバックグラウンド・イベントが遅延しているか完了できない場合、
CTX_DDL.SYNC_INDEXはORA-30608を返し、カタログ・ビューにエラー・メッセージを記録します。
自動メンテナンスと手動メンテナンスのSYNC動作の違い
自動メンテナンスと手動メンテナンスの同期動作の違い、およびCTX_DDL.SYNC_INDEX操作の間に様々なイベントがどのように処理されるかを比較します:
| 動作 | 自動メンテナンス | 手動メンテナンス |
|---|---|---|
|
バックグラウンド・メカニズム |
自動メンテナンス・モードでは、バックグラウンド・プロセスによって索引がメンテナンスされます。このバックグラウンド・メカニズムでは、各 たとえば、Sync-SによってSync-Pが起動されて、Sync-Rで |
手動メンテナンス・モードでは、DBMS_SCHEDULERバックグラウンド・ジョブによって索引がメンテナンスされます。このバックグラウンド・メカニズムでは、すべての同期イベント(Sync-M、Sync-RおよびSync-P)が単一のSYNC操作としてまとめて実装されます。
|
|
|
これらの索引は、自動メンテナンスと 通常の その他の |
|
|
カタログ・ビュー |
|
|
関連トピック
5.8.4 自動メンテナンスの有効化および無効化
CONTEXTおよび検索索引に対してデフォルトで有効になっています。索引の作成時に自動メンテナンスを明示的に指定する方法、またはデフォルトの動作をオーバーライドしてかわりにSYNCを有効にするために無効にする方法について学習します。5.8.5 自動メンテナンスと手動メンテナンスの切替え
ALTER INDEXを使用すると、索引を再構築せずにMAINTENANCE AUTOとMAINTENANCE MANUALを切り替えることができます。モードの変更中に、互換性のあるメンテナンス・タイプとSYNCタイプの組合せを指定する必要があります。
モード間の切り替えのガイドライン
-
MAINTENANCE AUTOは、SYNC (MANUAL)でサポートされています。デフォルトでは、自動メンテナンスを含むすべての索引がこの組合せで指定されます。 -
MAINTENANCE AUTOとSYNC ON COMMITまたはSYNC (EVERY)の組合せはサポートされていません。SYNC (ON COMMIT)またはSYNC (EVERY)も使用する索引にMAINTENANCE AUTOを指定する場合は、最初にそのような索引をSYNC (MANUAL)に設定する必要があります。 -
静的ディクショナリ・ビュー
CTX_USER_INDEXESには、現行ユーザーの既存のOracle TextCONTEXT索引および検索索引に関する情報が含まれています。たとえば、この問合せでは、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タイプ | 例 |
|---|---|---|
|
変更後
|
|
|
|
変更後
|
|
|
|
変更後
|
|
|
索引の手動メンテナンスへの切替え
この表では、索引をMAINTENANCE AUTOからMAINTENANCE MANUALに変更する、様々なSYNCタイプでのALTER INDEXの例を示します。
| 設定 | メンテナンスおよびSYNCタイプ | 例 |
|---|---|---|
|
変更後
|
|
CONTEXT索引のデフォルトのSYNCタイプはMANUALです。
|
|
変更後
|
|
|
|
変更後
|
|
|
関連トピック
5.8.6 メンテナンス・イベントおよびエラーの監視
SYSユーザーとCTXSYSユーザーは、カタログ・ビューを問い合せて、自動メンテナンスを使用した索引に関するすべてのバックグラウンド・メンテナンス・イベントのステータスを監視できます。
CTXビューと動的パフォーマンス・ビューを定期的に調べて、完了したか遅延しているすべてのバックグラウンド・メンテナンス・イベントのステータスを把握することをお薦めします。
メンテナンス・イベントに関するデータおよびステータスの問合せ
-
CTX_BACKGROUND_EVENTS:このOracle Textビューには、
SYSユーザーまたはCTXSYSユーザーのイベントの実行について履歴情報が表示されます。 -
CTX_USER_BACKGROUND_EVENTS:このOracle Textビューには、索引所有者に基づいて、現行ユーザーのイベントの実行について履歴情報が表示されます。
-
V$TEXT_WAITING_EVENTS:この動的パフォーマンス・ビューには、エラーや競合が原因で遅延しているか完了できないイベントについて履歴情報が表示されます。
たとえば、索引オブジェクトの番号と名前、索引所有者の番号と名前、元表(または表パーティション)のオブジェクトの番号と名前、イベントのタイプ(SYNC-Postings、SYNC-Mapping、SYNC-Rangesなど)、イベントのステータス(成功、実行中、失敗など)、再試行の反復のステータス(再試行の遅延、待機時間など)、イベントが待機を始めてからの経過時間、ログに記録されたエラー・メッセージなどを問い合せることができます。
エラーの処理
-
一部のエラーは一時的なものであり、再試行したときには再現されません。このようなエラー・タイプの場合は、ユーザーによる操作は必要ありません。
-
失敗したイベントの中には、再試行後に自動的に成功するものがあります。再試行イベントが成功しない場合は、別のイベントからそのイベントを再起動してみてください。
たとえば、再試行後に
SYNC-Postings(Sync-P)が失敗した場合は、システムでシリアル操作または同時操作をスケジュールできるように、SYNC-Scheduler(Sync-S)を再起動できます。Sync-Sが正常に完了すると、Sync-Pのキューがクリアされ、Sync-Pがただちに開始レベルで実行され、システムが過負荷になることはありません。 -
定期的に再試行してもイベントが成功しない場合は、データベース管理者に連絡してください。
-
定期的な再試行によるシステムの負荷を制限するために、連続的な再試行間の遅延時間が徐々に増分される場合があります。
このような遅延時間を追跡するために、すべての再試行イベントが増分レベルでスケジュールされます。つまり、スケジューラ・プロセスが最初に再試行イベントをイベント・キューに移動します。スケジューラ・プロセスがそれをイベント・キューから待機キューに移動し、次に準備完了キューに移動し、最後にワーカー・プロセスに割り当てます。
各イベントには、増分レベルに加え、再試行の反復があります。長期にわたる再試行では(つまり、再試行イベントがその元のイベントと同じでない場合)、レベルではなく反復が増分され、レベルが反復に初期化されます。
-
Oracle Real Application Clusters (Oracle RAC)システムでは、一部のノードでのみエラーが発生し、他のノードでは発生しない場合があります。このような場合にイベントが正常に完了するのは、そのイベントが他のノードに送信された場合のみです。