interMedia Textのパフォーマンス
6.3.4 interMedia Text 検索結果の表示 検索結果の表示 検索結果の表示 検索結果の表示
「検索設定」ページ（図6-4を参照）からテーマと要旨を使用可能にした場合は、検索によっ て検索結果から返される文書のテーマと要旨にアクセスできます。次のような表示ができま す。
■ そのファイルのHTMLバージョンを表示します。
■ そのファイルのHTMLバージョンを表示し、Oracle Portal管理者が設定した色または フォントで検索文字列を強調します。
■ 主要なテーマをチャートで表示します（文書のテーマ分析）。
■ ファイルの内容に関する概要を表示します（要旨）。
interMedia Textのパフォーマンス
6.4.2 索引付けに関する考慮事項 索引付けに関する考慮事項 索引付けに関する考慮事項 索引付けに関する考慮事項
索引付けに要する時間 索引付けに要する時間索引付けに要する時間 索引付けに要する時間
テキストの索引付けは、リソースを消費する処理です。明らかに、索引付けの速度は関係す るハードウェアの処理能力に依存しますが、ワークステーション・クラスのNTマシン（約
400MHzのCPU、128MBのメモリー）で1時間あたり50MB、マルチCPU、マルチギガバ
イトの大規模サーバー・マシンで1時間あたり1GB以上の速度が期待できます。後者の数字 は、パーティション表でパラレルの索引付けを使用することを前提としています（8.1.6の新 しいオプション）。
ほどんどの現実のシステムでは、文書の表に完全な索引付けをするには、数時間、場合に よっては数日かかります。
索引付け処理の進行状況を追跡する方法 索引付け処理の進行状況を追跡する方法索引付け処理の進行状況を追跡する方法 索引付け処理の進行状況を追跡する方法
ctx_output.start_log <filename>コマンドを使用して、索引付け処理の出力を記録 できます。通常、<filename>は$ORACLE_HOME/ctxに書き込まれますが、
ctx_adm.set_parameterのlog_directoryパラメータを使用してディレクトリを変更 できます。
この方法を使用しなくても、粗削りな方法ですが、DR$xxx$K表の行数を数えることができ ます。この表には、索引の付いた行ごとに1つの行があります。ただし、これらの行は、索 引付け処理によって索引付けメモリーが使い果されたときにのみコミットされ、データベー スへのフラッシュを行います。索引付けが完了するまでこれが起こらないようにすることも できます。
索引付けに必要なディスク容量のオーバーヘッド 索引付けに必要なディスク容量のオーバーヘッド索引付けに必要なディスク容量のオーバーヘッド 索引付けに必要なディスク容量のオーバーヘッド
オーバーヘッド（DR$索引表に必要な空き容量）は、元のテキスト・ボリュームの25パー セントから100パーセントまで様々です。一般に、テキストの合計容量が大きいほどオー バーヘッドは小さくなりますが、小さいレコードが多数ある場合は、大きいレコードが少数 ある場合よりオーバーヘッドが大きくなります。また、「クリーン」なデータ（公開されたテ キストなど）は、電子メールや議事録などの「乱雑な」データよりオーバーヘッドが少なく てすみます。これは、乱雑なデータには、スペルミスや省略形などによる、特異な単語が含 まれていることが多いためです。
一般に、テーマ索引はテキスト索引よりずっと小さいものです。通常、テーマ索引のみの作 成に必要な記憶域はごくわずかですが、テキスト索引のみの作成では結合された索引の容量 はあまり節約されません。ただし、速度はかなり速くなる可能性があります。
データ形式が索引付けに及ぼす影響 データ形式が索引付けに及ぼす影響データ形式が索引付けに及ぼす影響 データ形式が索引付けに及ぼす影響
索引付けのオーバーヘッドを調べると、書式付き文書（Microsoft Wordファイル）のオー バーヘッドはずっと少ないことがわかります。これは、そのような文書は、その中に含まれ
interMedia Textのパフォーマンス
したがって、たとえば、1GBのWord文書に必要な索引容量は50MBのみですが、1GBのプ レーン・テキストでは500MB必要です。これは、後者の場合は10倍のプレーン・テキスト があるためです。
索引付けに要する時間を割り出すのは困難です。索引付けするテキストの量が減少すれば明 らかに効果がありますが、この効果と文書をフィルタリングするコストとの間で平衡を取る 必要があります。一般に、これらの効果とコストはおおむね相殺されます。したがって、
1GBの書式付き文書の索引付けに要する時間は、少し長い場合がありますが、1GBのプレー ン・テキストの索引付けに要する時間とほぼ同じです。
6.4.3 更新に関する考慮事項 更新に関する考慮事項 更新に関する考慮事項 更新に関する考慮事項
新規または更新されたレコードの索引付けの回数 新規または更新されたレコードの索引付けの回数新規または更新されたレコードの索引付けの回数 新規または更新されたレコードの索引付けの回数
索引付けは何回行う必要があるでしょうか。索引付けをやり直す回数が少ないほど（コマン ドALTER INDEX indexname REBUILD ONLINE PARAMETERS('SYNC')を使用）、索引 の断片化は少なくなり、最適化の必要も少なくなります。ただし、これは、データが徐々に 古くなり、ユーザーにとって役に立たなくなる可能性があることを意味しています。
多くのシステムでは、夜間に索引付けを処理することができます。これは、1日経過してい ないデータは検索できないことを意味します。システムによっては、1時間、10分または5 分ごとの更新を行うものもあります。
注意 注意注意
注意: Contextサーバー（ctxsrv）は、今後は使用しないでください。かわりに、
drbgdml.sqlを使用してください。
索引の断片化が進んだときの対処方法 索引の断片化が進んだときの対処方法索引の断片化が進んだときの対処方法 索引の断片化が進んだときの対処方法
最善の方法は、一部の問合せのタイミングを調整し、索引の最適化を実行し、同じ問合せの タイミングを調整することです。毎回データベースを再起動してSGAを消去する必要があり ます。問合せの速度が大幅に向上する場合は、最適化が効果的だと言えます。
より厳密な方法としては、DR$xxx$I表にある各用語の行数を数える方法があります。
SELECT AVG(COUNT(*)) FROM DR$index_name$I GROUP BY TOKEN_TEXT HAVING COUNT(*) > 1;
注意 注意注意
注意: 索引表に1行のみ持つ単語は、すべて無視してください。
この問合せで値が10より大きい場合は、索引の最適化が必要な場合がありますが、実験で は、どのような特殊な状況においても最善の値が出ます。非常に大きな表には必然的に多数 の行があり、TOKEN_INFOデータが4Kの内部制限を超えるので、大きなシステムでは平均 はもっと大きくなることがあります。
interMedia Text検索の設定