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索引を表示、同期化および最適化する方法を説明します。この項では、次の項目について説明します。

ノート:

CTXCAT索引はトランザクション・ベースで更新されるため、元表が変更されると即時に更新されます。この項で説明する手動同期化は、CTXCAT索引には不要です。

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;

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

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: ロックの挿入、更新または削除、あるいは最適化の待機中にタイムアウトになりました)が生成されます。

関連項目:

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リファレンス』を参照してください