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
プロシージャは、指定の時間制限内に、キュー内のできるかぎり多くのドキュメントを処理します。
SYNC_INDEXのロック・パラメータ
SYNC_INDEX
のロック・パラメータにより、索引に対してすでに他の同期化が実行中の場合に同期化がどのような動作をするかを構成できます。
-
SYNC_INDEX
が索引名なしに起動された場合、ロック・パラメータは無視されます。 -
ロック・パラメータは、自動同期化(
sync
on
commit
やsync
every
など)には反映されません。 -
ロック・モードが
LOCK_WAIT
の場合、ロックが取得できない場合には永久に待機し、maxtimeの設定は無視されます。
次の2通りの場合があります。
オプション | 説明 |
---|---|
|
別の |
|
別の |
|
別の |
ノート:
Oracle Database 12cリリース2 (12.2.0.1)以降、SYNC_INDEX
を使用すると、STAGE_ITAB
の行が$I
表に自動的にマージされて戻されます。この行のマージは、STAGE_ITAB ($G)
の行数がSTAGE_ITAB_MAX_ROWS
パラメータ(デフォルトでは1万行)を超えた場合に実行されます。したがって、マージの最適化を明示的に実行したり、自動最適化ジョブをスケジュールする必要はありません。
5.7.3 索引の最適化
CONTEXT
CONTEXT索引は、各ワードにそのワードを含むドキュメントのリストが格納された逆向きの索引です。たとえば、初期の索引付け操作が1つ終了すると、ワードDOGのエントリは次のようになります。
DOG DOC1 DOC3 DOC5
索引の同期化を頻繁に行うと、最終的にCONTEXT
索引が断片化します。索引の断片化は、問合せ応答時間に悪影響を与える場合があります。したがって、断片化および索引のサイズを減らし、最善の問合せパフォーマンスを実現するために、時間をおいてCONTEXT
索引を最適化します。
自動最適化ジョブをスケジュールするには、STAGE_ITAB_MAX_ROWS
を0
に設定して、SYNC_INDEX
を使用して実行される自動マージを無効にする必要があります。
索引を最適化する場合は、CTX_DDL.OPTIMIZE_INDEX.
を使用することをお薦めします索引の最適化を理解するには、索引の構造と同期化の内容を理解する必要があります。この項では、次の項目について説明します。
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リファレンス』を参照してください