Oracle Text索引の管理

5 Oracle Text索引の管理

索引付けのエラーまたは失敗の管理、索引の再作成または再構築、カスタム索引プリファレンスの削除、同期および最適化タスクの管理、および索引メンテナンス操作の自動化の方法について学習します。

5.1 索引エラーの表示

索引付け操作は失敗したり、正常に完了しないことがあります。行の索引付け操作でエラーが発生すると、システムはそのエラーをOracle Textのビューに記録します。

索引のエラーは、CTX_USER_INDEX_ERRORS.を使用して表示できますすべての索引のエラーを表示するには、CTXSYSとしてCTX_INDEX_ERRORS.を使用します

たとえば、索引に最後に発生したエラーを表示するには、次の文を入力します。

SELECT err_timestamp, err_text 
  FROM ctx_user_index_errors 
  ORDER BY err_timestamp DESC;

エラーのビューをクリアするには、次のように入力します。

DELETE FROM ctx_user_index_errors;

このビューは、新しい索引を作成したときに、自動的にクリアされます。

関連項目:

索引エラー・ビューについてさらに学習するには、『Oracle Textリファレンス』を参照してください。

5.2 索引の削除

CREATE INDEX文を使用して索引を再作成する前に、既存の索引を削除する必要があります。

索引を削除するには、SQLのDROP INDEX文を使用します。

無効なPARAMETERS文字列を使用して索引を作成する場合は、索引を再作成する前に削除する必要があります。

たとえば、newsindexという索引を削除するには、次のSQL文を入力します。

DROP INDEX newsindex;

Oracle Textが索引の状態を判断できない場合(索引付け操作が異常終了したときなど)は、索引を削除できません。この場合は、次のコマンドを使用します。

DROP INDEX newsindex FORCE;

関連項目:

DROP INDEX文についてさらに学習するには、『Oracle Textリファレンス』を参照してください。

5.3 失敗した索引の再開

ALTER INDEX文を使用すると、失敗した索引作成を再開できる場合があります。通常は、失敗した索引を調査して修正した後、その索引作成を再開します。すべての索引の失敗を再開できるわけではありません。

索引の最適化は定期的にコミットされます。したがって、最適化操作が失敗しても、コミット・ポイントまでのすべての最適化作業は保存されています。

関連項目:

ALTER INDEX文の構文についてさらに学習するには、『Oracle Textリファレンス』を参照してください。

次の文は、10MBのメモリーでnewsindexの索引付け操作を再開します。

ALTER INDEX newsindex REBUILD PARAMETERS('resume memory 10M');

5.4 索引の再作成

この項では、索引を再作成する手順を説明します。再作成プロセス中は、索引を正常に問い合せることができます。

5.4.1 グローバル索引の再作成

Oracle Textでは、RECREATE_INDEX_ONLINEが用意されていて新規プリファレンスによりCONTEXT索引を再作成できる一方、元表での挿入、更新および削除機能が保持されています。RECREATE_INDEX_ONLINEを単一ステップのプロシージャで使用して、グローバル索引用のCONTEXT索引をオンラインで作成できます。既存の索引を残したまま新規索引が作成されるため、この操作には既存の索引とほぼ同じサイズの記憶域が必要です。また、RECREATE_INDEX_ONLINE操作はオンラインで実行されるため、操作中に元表で挿入、更新および削除を実行できます。再作成プロセス中に発生したすべての挿入、更新および削除操作は、オンライン保留中キューに記録されます。

再作成操作の完了後、新しい情報がすぐには反映されない場合があります。オンラインでの索引の作成の場合と同様に、再作成操作の完了後に索引を同期化して完全に最新にする必要があります。
再作成操作中に索引に対して発行される同期化は、既存のデータに対して処理されます。問合せがエラーを戻す場合、同期化はブロックされます。
再作成操作の過程で索引に対して発行された最適化コマンドは、なにも実行されずにエラーなしで即時に戻ります。
RECREATE_INDEX_ONLINEの間は、ほぼ通常どおりに索引を問い合せることができます。問合せは、最後のスワップが終わるまで、既存の索引およびポリシーに基づいて結果を戻します。また、挿入、更新および削除操作を発行してそれを同期化した場合は、既存の索引を問い合せると新しい行を表示できます。

ノート:

RECREATE_INDEX_ONLINEでは、トランザクション・ベースの問合せはサポートされていません。

時間制限付き同期化によるグローバル索引の再作成

索引の再作成を制御して、営業時間外にSYNC_INDEXの時間制限を設定し、索引を追加的に再作成できます。CREATE_SHADOW_INDEXプロシージャをPOPULATE_PENDINGおよびmaxtimeとともに使用します。

スケジュールされたスワッピングによるグローバル索引の再作成

問合せの失敗およびDMLブロックを許容できる場合は、CTX_DDL.EXCHANGE_SHADOW_INDEXを使用して、営業時間外に索引の再作成を実行できます。

関連項目:

RECREATE_INDEX_ONLINEプロシージャについてさらに学習するには、『Oracle Textリファレンス』を参照してください。
CREATE_SHADOW_INDEXの例については、『Oracle Textリファレンス』を参照してください。
CTX_DDL.EXCHANGE_SHADOW_INDEXの例については、『Oracle Textリファレンス』を参照してください。

5.4.2 ローカル・パーティション索引の再作成

索引がローカルにパーティション化されている場合は、1回のステップで索引を再作成できません。最初にシャドウ・ポリシーを作成してから、すべてのパーティションに対して RECREATE_INDEX_ONLINEプロシージャを実行する必要があります。パーティションの索引の再作成で索引パーティション・データおよび索引パーティション・メタデータをスワップするかどうかを示すSWAPまたはNOSWAPを指定できます。

パラメータ文字列で NOPOPULATEを指定した場合、このプロシージャを使用して、各パーティションのメタデータ(記憶域プリファレンスなど)を更新できます。このキーワードは、時間が限定された同期化によってシャドウ索引を追加的に構築する場合に便利です。NOPOPULATEを指定した場合、NOSWAPが暗黙的に強制されます。

すべてのパーティションでNOSWAPが使用されている場合、既存の索引とほぼ同じサイズの記憶域が必要です。索引パーティションの再作成中にスワッピングは実行されないため、パーティションに対する問合せは通常処理されます。複数のパーティションにわたる問合せは、スワッピングの段階に到達するまで、パーティションをまたがって一貫した結果を戻します。
SWAPを指定してパーティションを再構築する場合、その操作に必要な記憶域は、既存の索引パーティションとほぼ同じサイズです。索引パーティション・データおよび索引パーティション・メタデータは再作成後にスワッピングされるため、複数のパーティションにわたる問合せはパーティション間で一貫した結果を戻しませんが、各索引パーティションに関しては常に正しい結果となります。
SWAPを指定した場合、パーティションに対する挿入、更新および削除操作ならびに同期化は、スワッピング・プロセス中にブロックされます。

同時スワッピングによるローカル索引の再作成

ローカル・パーティション索引をオンラインで再作成して、プリファレンスを作成または変更できます。索引およびパーティションのメタデータのスワッピングは、この処理の最後に実行されます。複数のパーティションにわたる問合せは、最後に EXCHANGE_SHADOW_INDEXが実行されているときを除く再作成の処理中、パーティションをまたがって一貫した結果を戻します。

同時スワッピングによるローカル索引再作成のスケジューリング

CTX.DDLパッケージのRECREATE_INDEX_ONLINEにより、ローカル・パーティション索引を追加的に再作成できます。ここで、パーティションは最後にすべてスワッピングされます。

パーティションごとのスワッピングによるローカル索引の再作成

同時にすべてのパーティションをスワッピングするかわりに、新しいプリファレンスを使用して索引をオンラインで再作成でき、各パーティションはその完了時にスワッピングされます。すべてのパーティションにわたる問合せは、その処理中に一貫性のない結果を戻す場合があります。このプロシージャでは、CREATE_SHADOW_INDEXがRECREATE_INDEX_ONLINE.とともに使用されます

関連項目:

RECREATE_INDEX_ONLINEの詳細は、『Oracle Textリファレンス』を参照してください。

5.5 索引の再構築

ALTER INDEXを使用すると、有効な索引を再構築できます。索引の再構築では、索引のほとんどの設定は変更できません。新しいプリファレンスを使用して索引付けする場合に、索引を再構築することがあります。一般的に、索引を削除して、CREATE INDEX文を使用して再作成した後に、索引を再構築するメリットはありません。

関連項目:

索引の設定の変更の詳細は、「「索引の再作成」を参照してください

次の文は、索引を再構築し、レクサー・プリファレンスをmy_lexerで置き換えます。

ALTER INDEX newsindex REBUILD PARAMETERS('replace lexer my_lexer');

5.6 プリファレンスの削除

カスタム索引プリファレンスが不要になった場合は、そのプリファレンスを削除できます。

索引プリファレンスの削除には、CTX_DDL.DROP_PREFERENCEプロシージャを使用します。

プリファレンスを削除しても、そのプリファレンスから作成された索引は影響を受けません。

関連項目:

CTX_DDL.DROP_PREFERENCEプロシージャの構文についてさらに学習するには、『Oracle Textリファレンス』を参照してください。

次のコードは、my_lexerプリファレンスを削除します。

begin
ctx_ddl.drop_preference('my_lexer');
end;

5.7 CONTEXT索引に関するDML操作の管理

DML操作とは、元表に対するドキュメントの挿入、更新または削除操作のことです。

この項では、DML操作のためにOracle TextのCONTEXT索引を表示、同期化および最適化する方法を説明します。この項では、次の項目について説明します。

5.7.1 保留中のDML操作の表示

元表のドキュメントを挿入、更新または削除すると、そのROWIDは、その索引が同期化されるまでDMLキューに保持されます。このキューはCTX_USER_PENDINGビューで表示できます。

たとえば、索引で保留中のDML操作を表示するには、次の文を入力します。

SELECT pnd_index_name, pnd_rowid, to_char(
        pnd_timestamp, 'dd-mon-yyyy hh24:mi:ss'
        ) timestamp FROM ctx_user_pending;

この文によって、次の形式の出力結果が戻されます。

PND_INDEX_NAME                 PND_ROWID          TIMESTAMP
------------------------------ ------------------ --------------------
MYINDEX                        AAADXnAABAAAS3SAAC 06-oct-1999 15:56:50

関連項目:

CTX_USER_PENDINGビューについてさらに学習するには、『Oracle Textリファレンス』を参照してください

5.7.2 索引の同期化

索引を同期化すると、元表に対する保留中のすべての更新および挿入が処理されます。同期化は、PL/SQLでCTX_DDL.SYNC_INDEXプロシージャを使用して実行します。CTX_DDL.SYNC_INDEXプロシージャを使用して索引の同期化の期間およびロック動作を制御できます。

SYNC_INDEXによる索引の同期化

次の例では、2MBのメモリーを使用して索引を同期化します。

begin

ctx_ddl.sync_index('myindex', '2M');

end;

SYNC_INDEXのmaxtimeパラメータ

SYNC_INDEXプロシージャには、OPTIMIZE_INDEXのように、操作に対し分単位の提示された時間制限を指定するmaxtimeパラメータが含まれます。SYNC_INDEXプロシージャは、指定の時間制限内に、キュー内のできるかぎり多くのドキュメントを処理します。

maxtimeがNULLの場合は、CTX_DDL.MAXTIME_UNLIMITED.の場合と同じです。
時間制限は、概算です。実際にかかる時間が指定した時間より短いかまたは長い場合があります。
ALTER INDEX... syncコマンドは非推奨であるため、変更されていません。
SYNC_INDEXが索引名なしに起動された場合、maxtimeパラメータは無視されます。
maxtimeパラメータは、自動同期化(sync on commitやsync everyなど)には反映されません。

SYNC_INDEXのロック・パラメータ

SYNC_INDEXのロック・パラメータにより、索引に対してすでに他の同期化が実行中の場合に同期化がどのような動作をするかを構成できます。

SYNC_INDEXが索引名なしに起動された場合、ロック・パラメータは無視されます。
ロック・パラメータは、自動同期化(sync on commitやsync everyなど)には反映されません。
ロック・モードがLOCK_WAITの場合、ロックが取得できない場合には永久に待機し、maxtimeの設定は無視されます。

使用できるオプションは次のとおりです。

オプション	説明
`CTX_DDL.LOCK_WAIT`	別の`SYNC_INDEX`が実行されている場合、実行中の同期化が完了するまで待機してから、新しい同期化を開始します。
`CTX_DDL.LOCK_NOWAIT`	別の`SYNC_INDEX`が実行されている場合、すぐにエラーなしで戻ります。
`CTX_DDL.LOCK_NOWAIT_ERROR`	別の`SYNC_INDEX`が実行されている場合、すぐにエラー(DRG-51313: ロックの挿入、更新または削除、あるいは最適化の待機中にタイムアウトになりました)が生成されます。

ノート:

Oracle Database 12cリリース2 (12.2.0.1)以降、SYNC_INDEXを使用すると、STAGE_ITABの行が$I表に自動的にマージされて戻されます。この行のマージは、STAGE_ITAB ($G)の行数がSTAGE_ITAB_MAX_ROWSパラメータ(デフォルトでは1万行)を超えた場合に実行されます。したがって、マージの最適化を明示的に実行したり、自動最適化ジョブをスケジュールする必要はありません。

関連項目:

CTX_DDL.SYNC_INDEX文の構文についてさらに学習するには、『Oracle Textリファレンス』を参照してください。

5.7.3 索引の最適化

CONTEXTCONTEXT索引は、各ワードにそのワードを含むドキュメントのリストが格納された逆向きの索引です。たとえば、初期の索引付け操作が1つ終了すると、ワードDOGのエントリは次のようになります。

DOG DOC1 DOC3 DOC5

索引の同期化を頻繁に行うと、最終的にCONTEXT索引が断片化します。索引の断片化は、問合せ応答時間に悪影響を与える場合があります。したがって、断片化および索引のサイズを減らし、最善の問合せパフォーマンスを実現するために、時間をおいてCONTEXT索引を最適化します。

自動最適化ジョブをスケジュールするには、STAGE_ITAB_MAX_ROWSを0に設定して、SYNC_INDEXを使用して実行される自動マージを無効にする必要があります。

索引を最適化する場合は、CTX_DDL.OPTIMIZE_INDEX.を使用することをお薦めします索引の最適化を理解するには、索引の構造と同期化の内容を理解する必要があります。この項では、次の項目について説明します。

関連項目:

CTX_DDL.OPTIMIZE_INDEX文の構文と使用例の詳細は、『Oracle Textリファレンス』を参照してください。

5.7.3.1 索引の断片化

新しいドキュメントが元表に追加されると、索引は新しい行の追加によって同期化されます。たとえば、ワードdogを含むDOC 7ドキュメントを追加し、索引を同期化すると、次のようになります。

DOG DOC1 DOC3 DOC5
DOG DOC7

その後の挿入や更新、削除によっても次のように新しい行が作成されます。

DOG DOC1 DOC3 DOC5
DOG DOC7
DOG DOC9
DOG DOC11

索引の断片化は、新規文書を追加して索引を同期化するときに発生します。特に、バックグラウンドでの挿入、更新または削除では索引が頻繁に同期化されるため、一般的にはバッチ・モードでの同期化に比べて断片化が激しくなります。

バッチ処理をより低い頻度で実行する場合、索引の行数が減少してドキュメント・リストが長くなるため、断片化が軽減されます。

CTX_DDL.OPTIMIZE_INDEX.を使用して、FULL(完全)またはFAST(高速)モードで索引を最適化すると、索引の断片化を減少させることができます

5.7.3.2 ドキュメントの無効性とガベージ・コレクション

ドキュメントを元表から削除すると、Oracle Textでは、そのドキュメントに削除済のマークが設定されます。ただし、索引は即時に変更されません。

古い情報が領域を占有していると問合せ時に余分なオーバーヘッドが発生するため、索引をFULLモードで最適化して古い情報を削除する必要があります。この処理はガベージ・コレクションと呼ばれます。元表に対する更新または削除を頻繁に実行する場合は、ガベージ・コレクションのためにFULLモードで最適化を行う必要があります。

5.7.3.3 単一のトークンの最適化

索引全体の最適化以外に、単一のトークンも最適化できます。トークン・モードを使用すると、参照頻度の低いトークンの最適化に時間をかけずに、検索頻度の高い索引トークンを最適化できます。

たとえば、トークンDOGの更新と問合せが頻繁に行われる場合、索引内のこのトークンのみの最適化を指定できます。

トークンを最適化すると、そのトークンの問合せ応答時間が短縮できます。

索引の最適化を単一のトークンで行うには、CTX_DDL.OPTIMIZE_INDEX.を使用します

5.7.3.4 索引の断片化およびガベージ・データの表示

CTX_REPORT.INDEX_STATSプロシージャを使用すると、索引の統計レポートを作成できます。このレポートには、最適な行の断片化に関する情報、最も断片化されているトークン、および索引内のガベージ・データの量が含まれています。大規模な索引の場合はこのレポートの実行に時間がかかることがありますが、このレポートは索引を最適化する必要があるかどうかの判断に役立ちます。

関連項目:

CTX_REPORT.INDEX_STATSプロシージャについてさらに学習するには、『Oracle Textリファレンス』を参照してください

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

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

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

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

概要

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

自動メンテナンスは、Oracle Database 23c以降のリリースで作成された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)では、ユーザーが推定した新規索引データ到着頻度に基づいて、バックグラウンド同期ジョブが過剰に起動される可能性があります。

手動メンテナンスとは

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

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

新しいリリースにアップグレードした後も、既存の索引では、以前に指定した同期方法が引き続き使用されます。たとえば、Oracle Database 23cにアップグレードした後に、既存の索引が、以前に指定した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タイプが使用されます。

要件と制限事項

非同期メンテナンス・フレームワークのデータベース互換性は、Oracle Database 21.0.0.0以降です。
自動メンテナンスと次のパラメータの組合せはサポートされていません:
- FAST_QUERY
- ASYNCHRONOUS_UPDATE
- TRANSACTIONAL
- SYNC (ON COMMIT)およびSYNC (EVERY)
前述のいずれかの組合せを実行するとエラーが発生し、索引と互換性のあるモードを使用するよう求められます。
MAINTENANCE AUTO索引では、シャドウ索引はサポートされていません。

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

自動メンテナンス・モードでは、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タイムアウト` (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シリアル` (Sync-PS)	Sync-Pをシリアルに実行します。ポストはSGAバッチで生成されます。
`SYNC-Postings同時` (Sync-PC)	Sync-Pを同時に実行します。競合なしで複数の範囲を同時に独立して実行するようにスケジュールできます。
`SYNC-Writer` (Sync-W)	ポスト・リストのSGAバッチをディスクに書き込みます。Sync-Wイベントは、それ自体と同時に実行できます。ただし、これらのイベントは、`SYNC-Cleanupバッチ` (Sync-C)とともに実行できません。 Sync-Wイベントは、それらを生成したノードにローカルなSGAバッチを処理するため、他のRACノードにブロードキャストされることはありません。
`SYNC-Cleanupバッチ` (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`最適化マージ操作をスケジュールします。

SYNC-Mapping

(Sync-M)

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

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

SYNC-Mappingタイムアウト

(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シリアル

(Sync-PS)

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

SYNC-Postings同時

(Sync-PC)

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

SYNC-Writer

(Sync-W)

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

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

SYNC-Cleanupバッチ

(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コールでは、次のステップが順番に実行されます:

索引または索引パーティションのすべての待機イベントをリセットします:

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

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

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`操作が別々のイベントに分割され、それらは必要に応じて互いに同時実行されます。たとえば、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 COMMIT`や`SYNC 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`

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

自動メンテナンス・モードでは、バックグラウンド・プロセスによって索引がメンテナンスされます。このバックグラウンド・メカニズムでは、各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 COMMITやSYNC 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.3 自動メンテナンスの有効化および無効化

自動メンテナンスは、新しいOracle Text CONTEXTおよび検索索引に対してデフォルトで有効になっています。索引の作成時に自動メンテナンスを明示的に指定する方法、またはデフォルトの動作をオーバーライドしてかわりにSYNCを有効にするために無効にする方法について学習します。

新しい索引の自動メンテナンスを明示的に指定するには、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');

新しい索引の自動メンテナンスを無効にするには、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');
```
手動メンテナンスに設定された索引のデフォルトの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.4 自動メンテナンスと手動メンテナンスの切替え

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 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タイプ	例
`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’);`

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タイプ例

設定	メンテナンスおよび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")’);`

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")’);

関連項目

Oracle Textリファレンス

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

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)システムでは、一部のノードでのみエラーが発生し、他のノードでは発生しない場合があります。このような場合にイベントが正常に完了するのは、そのイベントが他のノードに送信された場合のみです。

関連項目