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

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

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

5.7.1 保留中のDML操作の表示

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

次のように索引表を問い合せると、DMLキューを表示できます:

  • デフォルトのfast_dmlオプションを使用して索引が作成された場合およびCOMPATIBLEデータベース・パラメータが20.0より小さい値に設定されている場合に、CTXSYS.DR$PENDING表は保留中のDMLを追跡します。保留中の挿入および更新操作をCTX_PENDINGおよびCTX_USER_PENDINGビューを使用して問い合せることができます。

  • デフォルトのfast_dmlオプションを使用して索引が作成され、COMPATIBLEデータベース・パラメータが20.0以上に設定されている場合、DR$INDEX_NAME$C表には、索引への同期を待機しているROWIDに関する情報が格納されます。

MAINTENANCE AUTO (自動メンテナンス)またはSYNC EVERYに設定されている索引は自動的に同期されますが、保留中のDML表を定期的に確認して、同期コールが失敗しているかどうかを確認できます。たとえば、問合せ結果が正しくないか古いと思われる場合は、ドキュメントが同期されたかどうかを確認し、必要に応じて手動のSYNC_INDEXコールを実行できます。

たとえば、索引で保留中のDML操作を表示するには、次のコマンドを入力します:

SELECT COUNT(*) FROM myschema.dr$myindex$c;

出力が次のように表示されます。

COUNT(*)
----------
1

$C表から同期されていないすべての変更のROWIDを取得するには、次のコマンドを入力します:

SELECT dml_rid FROM myschema.dr$myindex$c;

出力が次のように表示されます。

DML_RID
------------------
AAAVP9AAMAAAAKGAAD

CTX_DDL.SYNC_INDEXを実行して索引を同期し、$C表がクリアされているかどうかを確認できます:

EXEC CTX_DDL.SYNC_INDEX('myschema.myindex');
SELECT COUNT(*) FROM myschema.dr$myindex$c;
COUNT(*)
----------
0

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プロシージャは、指定の時間制限内に、キュー内のできるかぎり多くのドキュメントを処理します。

  • maxtimeNULLの場合は、CTX_DDL.MAXTIME_UNLIMITED.の場合と同じです。

  • 時間制限は、概算です。実際にかかる時間が指定した時間より短いかまたは長い場合があります。

  • ALTER INDEX... syncコマンドは非推奨であるため、変更されていません。

  • SYNC_INDEXが索引名なしに起動された場合、maxtimeパラメータは無視されます。

  • maxtimeパラメータは、自動同期化(sync on commitsync everyなど)には反映されません。

SYNC_INDEXのロック・パラメータ

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

  • SYNC_INDEXが索引名なしに起動された場合、ロック・パラメータは無視されます。

  • ロック・パラメータは、自動同期化(sync on commitsync everyなど)には反映されません。

  • ロック・モードがLOCK_WAITの場合、ロックが取得できない場合には永久に待機し、maxtimeの設定は無視されます。

次の2通りの場合があります。

オプション 説明

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