1. アプリケーション開発者ガイド
  2. Oracle Textのチューニング

7 Oracle Textのチューニング

Oracle Textには、問合せと索引付けのパフォーマンスを改善する方法が用意されています。

この章のトピックは、次のとおりです:

7.1 統計を使用した問合せの最適化

統計を使用して問合せを最適化する場合は、問合せ表および索引に関して収集された統計を使用して、その問合せを最も効率的に処理できる実行計画が選択されます。一般に、問合せパフォーマンスの改善が必要な場合は、元表に関する統計を収集することをお薦めします。統計を使用して最適化を行うと、CONTAINS述語の選択性およびコストをより正確に見積ることができるため、より適切な実行計画が選択されます。

オプティマイザは、次のパラメータに基づいて最適な実行計画を選択します。

  • CONTAINS述語の選択性

  • 同じ問合せに含まれるその他の述語の選択性

  • CONTAINS述語を処理したときのCPUコストとI/Oコスト

次の各項では、統計を拡張可能問合せオプティマイザで使用する方法を説明します。

注意:

Oracle Text索引などの、ドメイン索引に関する統計のインポートおよびエクスポートは、DBMS_STATSパッケージではサポートされていません。統計のインポートおよびエクスポートの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

関連項目:

CONTAINS問合せ演算子の詳細は、『Oracle Textリファレンス』を参照してください

7.1.1 統計の収集

デフォルトでは、Oracle Textはコストベース・オプティマイザ(CBO)を使用し、問合せに対する最適な実行計画を決定します。

オプティマイザを使用して最適なコストを見積るために、問い合せる表の統計を次のように計算できます。

ANALYZE TABLE <table_name> COMPUTE STATISTICS;

また、次のように表のサンプルの統計を見積ることができます。

ANALYZE TABLE <table_name> ESTIMATE STATISTICS 1000 ROWS;

または

ANALYZE TABLE <table_name> ESTIMATE STATISTICS 50 PERCENT;

統計の収集は、DBMS_STATS.GATHER_TABLE_STATSプロシージャを使用してパラレルに行うこともできます。 

begin
 
DBMS_STATS.GATHER_TABLE_STATS('owner', 'table_name',
                                       estimate_percent=>50,
                                       block_sample=>TRUE,
                                       degree=>4) ;
 
end  ;

これらの文は、table_nameに関連付けられたすべてのオブジェクトの統計を収集します。オブジェクトには、その表の列とその表に関連付けられたすべての索引(Bツリー、ビットマップまたはテキスト・ドメイン)も含まれます。

表の統計を再収集するには、ANALYZE文を必要な回数入力するか、DBMS_STATSパッケージを使用します。

テキスト・ドメイン索引の統計を収集することによって、Oracle Databaseのコストベース・オプティマイザでは、次のタスクを実行できます。

  • CONTAINS述語の選択性の見積り

  • テキスト索引を使用したときのI/OコストとCPUコスト(ドメイン索引を使用してCONTAINS述語を処理するときのコスト)の見積り

  • CONTAINSの起動ごとのI/OコストとCPUコストの見積り

CONTAINS述語の選択性がわかっていると、構造化問合せなど、複数の述語が含まれた問合せを行う場合に役立ちます。このように、コストベース・オプティマイザでは、ドメイン索引を使用してCONTAINSを評価するか、あるいはCONTAINS述語をポスト・フィルタとして適用するかを、より適切に判断できます。

関連項目:

  • ANALYZE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

  • DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

7.1.2 統計による問合せ最適化の例

次の構造化問合せは、統計を最適化する例です。

select score(1) from tab where contains(txt, 'freedom', 1)  > 0 and author = 'King' and year > 1960;

author列はVARCHAR2型で、year列はNUMBER型であるとします。また、author列にはBツリー索引があるとします。

また、構造化述語authorはCONTAINS述語およびyear述語と比較してきわめて厳密であると想定しています。つまり、構造化述語(author = 'King')は、year述語およびCONTAINS述語と比較して、かなり少ない数の行(たとえば、それぞれ1000行および1500行に対して5行)を戻すと想定します。

このような状況の場合、Oracle Textでは、最初に構造化述語(author = 'King')にBツリー索引のレンジ・スキャンを行い、次にROWIDで表アクセスを行った後、Bツリーの表アクセスから戻された行に他の2つの述語を適用することで、この問合せをより効率的に行うことができます。

注意:

テキスト索引の統計が収集されていない場合、コストベース・オプティマイザは、CONTAINS述語の選択性と索引コストが低いものとみなします。

7.1.3 統計の再収集

索引を同期化した後、単一の索引の統計を再収集して、コストの見積りを更新できます。

同期化の前に元表が再解析されている場合は、同期化の後に表全体を再解析しなくても、索引を解析するのみで十分です。

そのためには、次の文のいずれかを入力します。

ANALYZE INDEX <index_name> COMPUTE STATISTICS;

または

ANALYZE INDEX <index_name> ESTIMATE STATISTICS SAMPLE 50 PERCENT;

7.1.4 統計の削除

表に対応付けられた統計を削除するには、次の文を発行します。

ANALYZE TABLE <table_name> DELETE STATISTICS;

1つの索引の統計を削除するには、次の文を発行します。

ANALYZE INDEX <index_name> DELETE STATISTICS;

7.2 応答時間短縮のための問合せの最適化

デフォルトでは、Oracle Textにより、問合せはスループット向上のために最適化されます。最適化の結果、問合せは最短時間ですべての行を戻します。

ただし、多くの場合(特にWebアプリケーションの場合)、問合せを応答時間が短縮されるように最適化する必要があります。これは大きなヒットリストからできるだけ短い時間で、最初の数個のヒットのみを取得する必要があるためです。

次の各項では、応答時間が短縮されるようにCONTAINS問合せを最適化する方法を説明します。

7.2.1 問合せの応答時間に影響するその他の要因

次のような要因が問合せ応答時間に影響します。

7.2.2 FIRST_ROWS(n)ヒントによるORDER BY問合せの応答時間の短縮

ORDER BY問合せの最初のいくつかの行が必要な場合は、コストベースであるFIRST_ROWS(n)ヒントを使用することをお薦めします。

注意:

FIRST_ROWS(n)ヒントはコストベースであるため、使用する前に表に関する統計を収集しておくことをお薦めします。

FIRST_ROWS(n)ヒントは、最初の(n)行をできるだけ短時間で受け取る必要がある場合に使用します。たとえば、次のPL/SQLブロックでは、カーソルを使用して問合せの最初の10ヒットを取り出し、FIRST_ROWS(n)ヒントを使用して応答時間が短縮されるように最適化しています。 

declare
cursor c is 

select /*+ FIRST_ROWS(10) */ article_id from articles_tab
   where contains(article, 'Omophagia')>0 order by pub_date desc;

begin
for i in c
loop
insert into t_s values(i.pk, i.col);
exit when c%rowcount > 11;
end loop;
end;
/

カーソルcはomophagiaというワードを含むソートされたROWIDを戻すSELECT文です。コードがカーソル内をループして、最初の10行を取り出します。取り出された行は、一時表t_sに格納されます。

FIRST_ROWS(n)ヒントを指定した場合、オプティマイザは上位n個のヒットを戻すコストが低い場合に、テキスト索引に対してROWIDをスコア順で戻すように指示します。

このヒントがない場合、テキスト索引によりCONTAINS述語を満たすすべての行がソートされていない順序で戻された後、Oracle DatabaseによりROWIDがソートされます。このように結果セット全体を取り出すと時間がかかります。

この問合せでは、最初の10ヒットのみが必要なため、ヒントを使用することでパフォーマンスが向上します。

注意:

FIRST_ROWS(n)ヒントは、問合せで最初の数個のヒットのみが必要な場合に使用します。結果セット全体が必要な場合は、パフォーマンスの低下につながるため、このヒントは使用しないでください。

7.2.3 DOMAIN_INDEX_SORTヒントを使用した応答時間の短縮

また、DOMAIN_INDEX_SORTヒントを使用して応答時間を短縮することもできます。FIRST_ROWS(n)の場合と同じように、応答時間が短縮されるように問合せが最適化されている場合は、Oracle Textは最初の数行を最短時間で戻します。

たとえば、このヒントは次のように使用できます。

select /*+ DOMAIN_INDEX_SORT */ pk, score(1), col from ctx_tab 
            where contains(txt_col, 'test', 1) > 0 order by score(1) desc;

ただし、このヒントはルールベースのみです。つまり、Oracle Textでは、ORDER BY句を満たす索引を常に選択します。この結果、CONTAINS句の選択性が非常に高い問合せでは、パフォーマンスが最善にはならないことがあります。そのような場合は、完全にコストベースのFIRST_ROWS(n)ヒントを使用することをお薦めします。

7.2.4 ローカル・パーティションCONTEXT索引を使用した応答時間の短縮

データをパーティション化し、ローカル・パーティション索引を作成すると、問合せのパフォーマンスが向上します。パーティション表では、各パーティションに独自の索引表セットがあります。実際には複数の索引がありますが、各索引からの結果が必要に応じて組み合され、最終的な結果セットが生成されます。

LOCALキーワードを使用して、CONTEXT索引を次のように作成します。 

CREATE INDEX index_name ON table_name (column_name) 
INDEXTYPE IS ctxsys.context
PARAMETERS ('...')
LOCAL

パーティション化された表および索引を使用すると、次のような問合せのパフォーマンスが向上します。

7.2.4.1 パーティション・キー列に対する範囲検索

これは、パーティション・キー列の特定の値範囲に検索を限定する問合せです。たとえば、日付範囲に対する次の問合せについて考えます。

SELECT storyid FROM storytab WHERE CONTAINS(story, 'oliver')>0 and pub_date BETWEEN '1-OCT-93' AND '1-NOV-93';

日付範囲が制限されている場合は、1つのパーティションを検索するだけで問合せが満たされる可能性があります。

7.2.4.2 パーティション・キー列でのORDER BY

これは、最初のn個のヒットのみが必要で、ORDER BY句がパーティション・キーを指定する問合せです。次のように、price列に対するORDER BY問合せで最初の20ヒットをフェッチする場合を考えてみます。 

SELECT * FROM (
SELECT itemid FROM item_tab WHERE CONTAINS(item_desc, 'cd player')
  >0 ORDER BY price)
  WHERE ROWNUM < 20;
この例では、表はpriceによりパーティション化されており、最初のパーティションからのヒットを取得すれば問合せが満たされる可能性があります。 

                     

                  

               
7.2.5 スコア順のローカル・パーティション索引を使用した応答時間の短縮
                  

                  

                     
ローカル・パーティション索引に対してDOMAIN_INDEX_SORTヒントを使用すると、特にスコア順にした場合にパフォーマンスが大幅に低下することがあります。これは、結果をソートする前に、全パーティションにまたがる問合せの全ヒットを取得する必要があるためです。
                     

                     
パフォーマンスの低下を回避するには、DOMAIN_INDEX_SORTヒントを使用するときにインライン・ビューを使用します。DOMAIN_INDEX_SORTヒントを使用すると、次のような条件下で、ローカル・パーティション表の問合せパフォーマンスを向上させることができます。
                     

                     
    
                        
  • 
                           
    SCORE()句による順序を含むテキスト問合せ自体がインライン・ビューとして表されている場合 
                           
    
                        
    • 
                        
  • 
                           
    インライン・ビュー内のテキスト問合せにDOMAIN_INDEX_SORTヒントが含まれている場合 
                           
    
                        
    • 
                        
  • 
                           
    インライン・ビューに対する問合せに、ビューからフェッチする行数を制限するROWNUM述語が含まれている場合 
                           
    
                        
    • 
                     

                     
たとえば、次のテキスト問合せがあり、パーティション表doc_tabに対してローカル・テキスト索引が作成されているとします。 
                     
     select doc_id, score(1) from doc_tab 
        where contains(doc, 'oracle', 1)>0 
        order by score(1) desc;

ここで、上位20行のみを取り出す場合は、この問合せを次のように再作成します。 
     select * from 
          (select /*+ DOMAIN_INDEX_SORT */ doc_id, score(1) from doc_tab 
              where contains(doc, 'oracle', 1)>0 order by score(1) desc) 
      where rownum < 21;

                        
関連項目:

                        
EXPLAIN PLAN文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
                        

                     

                  

               
7.2.6 問合せフィルタ・キャッシュを使用した応答時間の短縮
                  

                  

                     
Oracle Textには、問合せ結果のキャッシュに使用できる、問合せフィルタ・キャッシュというキャッシュ・レイヤーがあります。問合せフィルタ・キャッシュは、問合せ間で共有が可能です。そのため、キャッシュされた問合せ結果を複数の問合せで再利用でき、問合せの応答時間が短縮されます。

                     
キャッシュする問合せ結果を指定するには、ctxfiltercache演算子を使用します。次の例は、ctxfiltercache演算子を使用して、common_predicate問合せの結果をキャッシュに格納します。
                     
select * from docs where contains(txt, 'ctxfiltercache((common_predicate), FALSE)')>0;
次の例では、common_predicate問合せの結果がキャッシュされ、new_query問合せによって再利用されます。そのため、問合せの応答時間が短縮されます。
                     
select * from docs where contains(txt, 'new_query & ctxfiltercache((common_predicate), FALSE)')>0; 


                        
注意: 

                        

                        
    
                           
  • 
                              
    問合せフィルタ・キャッシュのサイズは、基本記憶域属性query_filter_cache_sizeを使用して指定できます。
    
                           
    • 
                           
  • 
                              
    ctx_filter_cache_statisticsビューには、問合せフィルタ・キャッシュに関する様々な統計が用意されています。
                              
    
                           
    • 
                        

                     

                     

                        
関連項目:

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

                        
    
                           
  • 
                              
    ctxfiltercache演算子
                              
    
                           
    • 
                           
  • 
                              
    query_filter_cache_size基本記憶域属性
                              
    
                           
    • 
                           
  • 
                              
    ctx_filter_cache_statisticsビュー
                              
    
                           
    • 
                        

                     

                  

               
7.2.7 CONTEXT索引のBIG_IOオプションを使用した応答時間の短縮
                  

                  

                     
Oracle Textに用意されているBIG_IOオプションを使用すると、IO操作を多用するCONTEXT索引の問合せパフォーマンスを改善できます。問合せパフォーマンスが向上するのは、主として回転ディスク上に格納されているデータの場合であり、SSDに格納されているデータについてはあまり効果がありません。
                     

                     
CONTEXT索引でBIG_IOオプションを有効にすると、一意のトークン・テキストごとに1つのLOB (ラージ・オブジェクト・データ型)を伴うトークン・タイプ・ペアが作成されます。したがって、テキストが同じでトークン・タイプが異なるトークンは、$I表で対応する行が異なります。 
                     

                     
BIG_IOオプションを有効にした索引では、トークンLOBをSecureFile LOBとして作成する必要があります。SecureFile LOBでは、データが複数のブロックに連続して格納されます。こうすると、問合せで短い読取りを何度も実行するかわりに、連続した長い読取りを実行できるため、問合せの応答時間が短縮されます。
                     

                     

                        
注意: 

                        
SecureFilesを使用するには、COMPATIBLE設定が11.0以上である必要があります。また、LOBは自動セグメント領域管理(ASSM)の表領域に作成する必要があります。既存のテキスト索引からSecureFilesに移行する際には、ASSM表領域を使用します。既存の索引をSecureFiles LOBに移行しやすくするために、ALTER INDEX REBUILDは、再索引付けを実行せずに$I表にのみ影響する記憶域プリファレンスを置換できるように拡張されています。
                        

                     

                     
BIG_IO索引オプションを指定してCONTEXT索引を作成するには、まずBIG_IO記憶域属性の値をYESに設定して基本記憶域プリファレンスを作成し、CONTEXT索引の作成時にこの記憶域プリファレンスを指定します。
                     

                     
次の例は、基本記憶域プリファレンスmystoreを作成し、そのBIG_IO記憶域属性の値をYESに設定します。
                     
exec ctx_ddl.create_preference('mystore', 'BASIC_STORAGE');
exec ctx_ddl.set_attribute('mystore', 'BIG_IO', 'YES');
BIG_IOオプションを無効にするには、BIG_IO記憶域属性の値をNOに設定して既存の記憶域プリファレンス(mystore)を更新してから、索引を再構築します。
                     
exec ctx_ddl.set_attribute('mystore', 'BIG_IO', 'NO');
alter index idx rebuild('replace storage mystore');

                        
警告:

                        
索引で矛盾が生じるので、BIG_IO索引オプションの無効化にメタデータ置換操作は使用しないでください。
                        

                     

                     
索引を再構築せずにパーティション索引でBIG_IOオプションを有効にするには、BIG_IO記憶域属性の値をYESに設定して基本記憶域プリファレンスを変更し、ctx_ddl.replace_index_metadataを使用してグローバル索引メタデータを置き換えてから、パーティション索引表のパーティションごとにREBUILDモードでoptimize_indexをコールします。
                     

                     
次の例では、パーティション索引idxに対してBIG_IOオプションを有効にします。
                     
exec ctx_ddl.set_attribute('mystore', 'BIG_IO', 'YES');
exec ctx_ddl.replace_index_metadata('idx', 'replace storage mystore');
exec ctx_ddl.optimize_index('idx', 'rebuild', part_name=>'part1');

                        
注意: 

                        
BIG_IOオプションのみを有効にして既存の索引表を変更するプロシージャでは、データの再索引付けは行われません。
                        

                     

                     

                        
注意: 

                        
BIG_IO索引オプションは連続した長い読取りを実行するので、BIG_IO索引オプションを使用する問合せでは、必要なプログラム・グローバル領域(PGA)のメモリーが多くなります。
                        

                     

                  

               
7.2.8 CONTEXT索引のSEPARATE_OFFSETSオプションを使用した応答時間の短縮
                  

                  

                     
Oracle Textに用意されているSEPARATE_OFFSETSオプションを使用すると、主に1つのワードまたはブールの問合せを対象としてIO操作を多用するCONTEXT索引の問合せパフォーマンスを改善できます。
                     

                     
SEPARATE_OFFSETSオプションでは、TEXTタイプのトークンに対して作成されるポスト・リストの構造が異なります。DOCID、頻度、情報の長さ(オフセット情報の長さ)およびオフセットをポスト・リストに分散させるかわりに、SEPARATE_OFFSETSオプションではDOCIDと頻度をポスト・リストの最初にまとめて格納し、情報の長さとオフセットをポスト・リストの最後に格納します。ポストの先頭にあるヘッダーには、DOCIDとオフセットの間の境界点に関する情報が含まれています。このようにDOCIDとオフセットを分離すると、データを読み取る問合せの時間が短くなるため、問合せの応答時間が短縮されます。
                     

                     
SEPARATE_OFFSETSオプションのパフォーマンスが最大限に発揮されるのは、BIG_IOオプションと組み合せたときに、きわめて長いポストを持つトークンを対象とした場合です。
                     

                     
SEPARATE_OFFSETS索引オプションを指定してCONTEXT索引を作成するには、まずSEPARATE_OFFSETS記憶域属性の値をTに設定して基本記憶域プリファレンスを作成し、CONTEXT索引の作成時にこの記憶域プリファレンスを指定します。
                     

                     
次の例は、基本記憶域プリファレンスmystoreを作成し、そのSEPARATE_OFFSETS記憶域属性の値をTに設定します。
                     
exec ctx_ddl.create_preference('mystore', 'BASIC_STORAGE');
exec ctx_ddl.set_attribute('mystore', 'SEPARATE_OFFSETS', 'T');
SEPARATE_OFFSETSオプションを無効にするには、SEPARATE_OFFSETS記憶域属性の値をFに設定して既存の記憶域プリファレンス(mystore)を更新してから、索引を再構築します。
                     
exec ctx_ddl.set_attribute('mystore', 'SEPARATE_OFFSETS', 'F');
alter index idx rebuild('replace storage mystore');

                        
警告:

                        
索引で矛盾が生じるので、SEPARATE_OFFSETS索引オプションの無効化にメタデータ置換操作は使用しないでください。
                        

                     

                     
索引を再構築せずにパーティション索引でSEPARATE_OFFSETSオプションを有効にするには、SEPARATE_OFFSETS記憶域属性の値をTに設定して基本記憶域プリファレンスを変更し、ctx_ddl.replace_index_metadataを使用してグローバル索引メタデータを置き換えてから、パーティション索引表のパーティションごとにREBUILDモードでoptimize_indexをコールします。
                     

                     
次の例では、パーティション索引idxに対してSEPARATE_OFFSETSオプションを有効にします。
                     
exec ctx_ddl.set_attribute('mystore', 'SEPARATE_OFFSETS', 'T');
exec ctx_ddl.replace_index_metadata('idx', 'replace storage mystore');
exec ctx_ddl.optimize_index('idx', 'rebuild', part_name=>'part1');

                        
注意: 

                        
SEPARATE_OFFSETSオプションのみを有効にして既存の索引表を変更するプロシージャでは、データの再索引付けは行われません。
                        

                     

                  

               
7.2.9 CONTEXT索引のSTAGE_ITAB、STAGE_ITAB_MAX_ROWS、STAGE_ITAB_PARALLELオプションを使用した応答時間の短縮
                  

                  

                     
Oracle Textに用意されているSTAGE_ITABオプションを使用すると、ほぼリアルタイムの索引付けにDML操作を多用するCONTEXT索引の問合せパフォーマンスを改善できます。
                     

                     
STAGE_ITAB索引オプションを使用しない場合は、新しいドキュメントがCONTEXT索引に追加されるたびに、ドキュメントを検索可能にするためにSYNC_INDEXがコールされます。こうすると、$I表に新しい行が作成されるため、$I表で断片化が大きくなります。これによって、問合せパフォーマンスの低下につながります。

                     
STAGE_ITAB索引オプションを有効にすると、新しいドキュメントに関する情報は$I表ではなく$Gステージング表に格納されます。これによって$I表は断片化しなくなるため、問合せパフォーマンスが低下しません。

                     
STAGE_ITAB索引オプションを有効にすると、$H Bツリー索引も$G表に作成されます。$G表と$H Bツリー索引は、$I表と$X Bツリー索引と同等です。

                     
$G表に存在する行を最適化して$I表に移動するには、MERGE最適化モードを使用します。

                     

                        
注意: 

                        
$G表は、KEEPプールに格納されます。十分なKEEPプール・メモリーを割り当て、新しいstage_itab_max_rowsオプションを使用して十分な大きさの$G表を維持して、問合せパフォーマンスを改善する必要があります。
                        

                     

                     
STAGE_ITAB索引オプションを指定してCONTEXT索引を作成するには、まずSTAGE_ITAB記憶域属性の値をYESに設定して基本記憶域プリファレンスを作成し、CONTEXT索引の作成時にこの記憶域プリファレンスを指定します。
                     

                     
次の例は、基本記憶域プリファレンスmystoreを作成し、そのSTAGE_ITAB記憶域属性の値をYESに設定します。
                     
exec ctx_ddl.create_preference('mystore', 'BASIC_STORAGE');
exec ctx_ddl.set_attribute('mystore', 'STAGE_ITAB', 'YES');
ALTER INDEX文の再構築オプションを使用すれば、パーティション化されていない既存のCONTEXT索引に対してSTAGE_ITAB索引オプションを有効にすることもできます。
alter index IDX rebuild parameters('replace storage mystore');
パーティション化されていないCONTEXT索引に対してSTAGE_ITABオプションを無効にするには、STAGE_ITAB記憶域属性の値をNOに設定して既存の記憶域プリファレンス(mystore)を更新してから、索引を再構築します。
                     
exec ctx_ddl.set_attribute('mystore', 'STAGE_ITAB', 'NO');
alter index idx rebuild('replace storage mystore');
この操作は、MERGE最適化モードを使用して最適化プロセスを実行してから、$G表を削除します。

                     
ALTER INDEX文の再構築オプションを、パーティション化されているCONTEXT索引に使用して、STAGE_ITABオプションの有効化と無効化を行うことはできません。 

                     
次の例は、CONTEXTパーティション索引idxに対してSTAGE_ITABオプションを有効にします。
                     
alter index idx parameters('add stage_itab');
次の例は、CONTEXTパーティション索引idxに対してSTAGE_ITABオプションを無効にします。
                     
alter index idx parameters('remove stage_itab');
Oracle Database 12cリリース2 (12.2)より、$Gに100万行を超える行がある場合、索引の同期中に$Gの内容が自動的に$Iに移動します。この値は、STORAGEプリファレンスのSTAGE_ITAB_MAX_ROWS属性により制御されます。
                     

                     

                        
注意: 

                        
不定期の索引同期化に時間がかかる場合は、STAGE_ITAB_MAX_ROWSパラメータの値を削減するか、STORAGEプリファレンスのSTAGE_ITAB_PARALLEL属性を使用して並列度を上げることができます。STAGE_ITAB_MAX_ROWSの値を非常に小さい値に設定すると、$Gの内容が$Iに頻繁に移動します。そのため、この値を非常に低い値に設定しないでください。
                        

                     

                     

                        
注意: 

                        
CONTEXT索引にSTAGE_ITAB索引オプションを使用するには、BASIC_STORAGEプリファレンスg_index_clauseおよびg_table_clauseを指定する必要があります。
                        

                     

                     

                        
関連項目:

                        
BASIC_STORAGEの詳細は、『Oracle Textリファレンス』を参照
                        

                     

                  

               

            
7.3 スループット向上のための問合せの最適化
               

               

                  
問合せがスループット向上のために最適化された場合は、すべてのヒットが最短時間で戻されます。これはデフォルトの動作です。

                  
次の各項では、スループット向上のために明示的に最適化する方法を説明します。

                  
               
7.3.1 CHOOSEモードおよびALL ROWSモード
                  

                  

                     
デフォルトでは、問合せはCHOOSEモードおよびALL_ROWSモードでスループットが向上するように最適化されます。問合せがスループット向上のために最適化された場合は、Oracle Textによってすべての行が最短時間で戻されます。 
                     

                  

               
7.3.2 FIRST_ROWS(n)モード
                  

                  

                     
FIRST_ROWS(n)モードでは、可能な場合、テキスト・ドメイン索引でスコア順にソートされた行が戻されるようにすることで応答時間を短縮するよう、Oracle Databaseのオプティマイザが最適化を行います。これは、FIRST_ROWS(n)ヒントを使用する場合のデフォルトの動作です。 
                     

                     
FIRST_ROWS(n)でスループットがさらに向上するように最適化するには、DOMAIN_INDEX_NO_SORTヒントを使用します。スループットの向上とは、すべての行を最短時間で問合せに取り込むことです。
                     

                     
次の例では、スコア順にソートした行を戻すためにテキスト・ドメイン索引を使用せずにスループットを向上させています。かわりに、CONTAINS述語を満たすすべての行が索引から取り出された後で、Oracle Textによって行がソートされます。 
                     
select /*+ FIRST_ROWS(10) DOMAIN_INDEX_NO_SORT */ pk, score(1), col from ctx_tab 
            where contains(txt_col, 'test', 1) > 0 order by score(1) desc;

                        
関連項目:

                        
 問合せオプティマイザの詳細、およびFIRST_ROWS(n)やCHOOSEなどのヒントの使用方法は、Oracle Database SQLチューニング・ガイドを参照してください。

                     

                  

               

            
7.4 Oracle Textのコンポジット・ドメイン索引(CDI)
               

               

                  
Oracle Databaseの拡張性フレームワークのコンポジット・ドメイン索引機能を使用すると、構造化された列をOracle Textで索引付けできます。したがって、テキストと1つ以上の構造化された条件の両方が、Oracle Textの単一の索引の行ソースによって満たされます。次のタイプの問合せのパフォーマンスが向上します。

                  
    
                     
  • 
                        
    SQL WHERE句内の、構造化された条件を持つテキスト問合せ
                        
    
                     
    • 
                     
  • 
                        
    構造化されたORDER BY条件を持つテキスト問合せ
                        
    
                     
    • 
                     
  • 
                        
    前述の2つの問合せタイプの両方の組合せ
    
                     
    • 
                  

                  
連結されたBツリー索引やビットマップ索引と同様、FILTER BY列およびORDER BY列の数が増えるに従って、アプリケーションではDMLのパフォーマンスが低下します。SCOREによるソートのプッシュダウンが応答時間の短縮のために最適化されている場合、構造化されたソートまたはSCOREと構造化されたソートの組合せのプッシュダウンも同様に、スループットの向上ではなく応答時間の短縮のために最適化されます。ただし、DOMAIN_INDEX_SORTヒントまたはFIRST_ROWS(n)ヒントを使用してフェッチ中にCDIにソートを含めるよう強制した場合、ヒットリスト全体を表示するには問合せ応答時間が大幅にかかります。
                  

               

            
7.5 CDIによるパフォーマンス・チューニング
               

               

                  
FILTER BY列のMDATAへのマッピングがサポートされているため、RANGEおよびLIKEのサポートされた機能を制限することで、問合せのパフォーマンスは等価性検索に対して最適化されます。ただし、FILTER BY列が連続した値を含むかまたはそのカーディナリティが非常に高い場合は、FILTER BY列のMDATAへのマッピングはお薦めしません。このようなマッピングは、非常に時間がかかり、$I表の範囲が限定され、$Xのパフォーマンスが低下する可能性があります。このような連続した列の一例として、DATEスタンプを使用した場合があります。このような連続した列の場合は、SDATAへのマッピングをお薦めします。
                  

                  
SORT述語およびFILTER BY述語をCDIに含めるか含めないかには、次のヒントを使用できます。
                  

                  
    
                     
  • 
                        
    DOMAIN_INDEX_SORT。問合せオプティマイザは、適用可能なソート条件を、指定したコンポジット・ドメイン索引に含めようとします。
                        
    
                     
    • 
                     
  • 
                        
    DOMAIN_INDEX_NO_SORT。問合せオプティマイザは、ソート条件を、指定したコンポジット・ドメイン索引に含めないようにします。
                        
    
                     
    • 
                     
  • 
                        
    DOMAIN_INDEX_FILTER(table name index name)。問合せオプティマイザは、適用可能なFILTER BY述語を、指定したコンポジット・ドメイン索引に含めます。
                        
    
                     
    • 
                     
  • 
                        
    DOMAIN_INDEX_NO_FILTER(table name index name)。問合せオプティマイザは、適用可能なFILTER BY述語を、指定したコンポジット・ドメイン索引に含めないようにします。
                        
    
                     
    • 
                  

                  

                     
注意: 

                     
domain_index_filterヒントは、問合せオプティマイザにCDIの使用を強制しません。かわりに、コストベース・オプティマイザがCDIの使用を選択している場合は、フィルタ述語も索引に含められます。問合せオプティマイザにCDI索引の選択を強制するには、さらにINDEXヒントも使用する必要があります。
                     

                  

                  

                     
例7-1 CDIヒントを使用したテキスト問合せのパフォーマンス・チューニング

                     
次の例では、表booksに対し、最適化された問合せを実行しています。
                     
SELECT bookid, pub_date, source FROM
  (SELECT /*+ domain_index_sort domain_index_filter(books books_ctxcdi) */ bookid, pub_date, source
      FROM books
      WHERE CONTAINS(text, 'aaa',1)>0 AND bookid >= 80
      ORDER BY PUB_DATE desc nulls last, SOURCE asc  nulls last, score(1) desc)
 WHERE rownum < 20;

                  
               

            
7.6 トレースを使用した索引および問合せのボトルネックの解決
               

               

                  
Oracle Textには、索引付けおよび問合せにおけるボトルネックを特定するためのトレース機能が備わっています。
                  

                  
Oracle Textには、事前定義済のトレースのセットが用意されています。各トレースは一意の番号で識別されます。また、この番号に対するCTX_OUTPUTの記号があります。
                  

                  
各トレースでは、特定の数量を測定します。たとえば、テキスト問合せ時に選択される$I行の数などです。 
                  

                  
トレースは累積カウンタです。そのため、使用方法は次のようになります。

                  
    
                     
  1. 
                        
    ユーザーがトレースを使用可能にします。
    
                     
    2. 
                     
  2. 
                        
    ユーザーが複数の操作を実行します。Oracle Textではアクティビティを測定し、トレースの結果を累積します。
    
                     
    3. 
                     
  3. 
                        
    ユーザーがトレース値を取得します。これは、手順2で実行されたすべての操作の合計値となります。
    
                     
    4. 
                     
  4. 
                        
    ユーザーがトレースを0(ゼロ)に再設定します。
    
                     
    5. 
                     
  5. 
                        
    ユーザーが手順2を繰り返します。
    
                     
    6. 
                  

                  
このため、たとえば、手順2でユーザーが2つの問合せを実行し、問合せ1で$Iから15行を選択し、問合せ2で$Iから17行を選択した場合、手順3ではトレースの値は32 (15 + 17)となります。
                  

                  
トレースは1つのセッションに関連付けられています。トレースは、1つのセッション内で発生した演算を測定できますが、反対に、複数のセッション間で測定を行うことはできません。

                  
パラレル同期化または最適化の際、トレースが現在有効になっている場合にかぎり、トレース・プロファイルはスレーブ・セッションにコピーされます。各スレーブは独自のトレースを蓄積し、終了前にすべてのトレース値をスレーブ・ログ・ファイルに暗黙的に書き込みます。

                  

                     
関連項目:

                     
Oracle Textリファレンス

                  

               

            
7.7 パラレル問合せの使用
               

               

                  
一般に、パラレル問合せは、大規模なデータ・コレクションと複数のCPUを備え、同時ユーザー数が少ないDSS、OLAPまたは分析システムに最も適しています。または、Oracle Real Application Clusters(Oracle RAC)ノード間でパラレル化されます。
                  

                  
Oracle Textでは、次のようにパラレル問合せをサポートしています。

                  
               
7.7.1 ローカルのCONTEXT索引でのパラレル問合せ
                  

                  

                     
パラレル問合せは、ローカルのCONTEXT索引のパラレル処理を指します。索引の並列度と様々なシステム属性に基づいて、Oracleにより、索引処理のために起動されるパラレル問合せスレーブの数が決定されます。各パラレル問合せスレーブが、1つ以上の索引パーティションを処理します。これは、パラレルに作成されたローカル索引のデフォルトの問合せ動作です。
                     

                     
ただし、同時ユーザー数が多く負荷の高いシステムで問合せが連続的に実行される場合は、通常上位N個のヒットが最初の数個のパーティションによって満たされるため、問合せのスループットはパラレル問合せによって一般に低下します。たとえば、次のような、ORDER BYパーティション・キー列を持つ典型的な上位N個のテキスト問合せでは、
                     
select * from (
        select story_id from stories_tab where contains(...)>0 order by 
publication_date desc)
    where rownum <= 10;

通常、パラレル問合せを使用するとパフォーマンスが下がります。
                     

                     
ALTER INDEX文を次のように使用して、パラレル索引の操作後にパラレル問合せを使用禁止にできます。
                     
Alter index <text index name> NOPARALLEL;
Alter index <text index name> PARALLEL 1;

次のように指定すると、パラレル問合せを使用可能にするか、並列度を上げることができます。
Alter index <text index name> parallel < parallel degree >;

               
7.7.2 Oracle RACノード間のパラレル問合せ
                  

                  

                     
Oracle Real Application Clusters (Oracle RAC)は、問合せのスループットを向上するために有効な手段です。Oracle Textで問合せの負荷が軽く良好なパフォーマンスが得られる場合は、問合せの負荷が増えた場合、Oracle RACによる優れた拡張性を期待できます。

                     
Oracle RAC環境におけるOracle Textのパフォーマンスは、(ローカル・パーティション索引を使用して)テキスト・データとテキスト索引を物理的にパーティション化し、各パーティションが個別のOracle RACノードで処理されるようにすると、さらに向上する場合があります。この方法で、複数のノード間でのキャッシュ・コンテンツの重複を回避することにより、Oracle RAC Cache Fusionのメリットを最大限に活用できます。

                     
Oracle 10gリリース1では、索引の作成時に、Oracle Textの各索引パーティションが個別のデータベース・ファイルに格納される必要があります。これにより、Oracle RACの再マスタリング機能を使用できるようになり、データベース・ファイルのアフィニティが適用されるため、各ノードは特定のデータベース・ファイル、つまり特定のOracle Text索引パーティションに集中します。

                     
Oracle 10gリリース2およびそれ以降では、データベース・オブジェクト・レベルのアフィニティがサポートされています。これにより、索引オブジェクト($I表および$R表)の特定ノードへの割当てが大幅に容易になっています。
                     

                     
Oracle RACは問合せのスループットとパフォーマンスを向上させるソリューションを提供していますが、あらゆる場合に効果があるわけではなく、データの容量が増加しても常に同じパフォーマンス向上が見込めるわけではありません。パフォーマンスの向上を図るには、SGAキャッシュに使用できるメモリー量を増やすか、データをパーティション化して、問合せで表の全パーティションをヒットせずに必要な問合せ結果セットを通常提供できるようにします。

                  

               

            
7.8 ブロック操作による問合せのチューニング
               

               

                  
複数の述語を持つ問合せを発行すると、実行計画でブロック操作が行われる場合があります。たとえば、次の複合問合せについて考えます。
select docid from mytab where contains(text, 'oracle', 1) > 0 
  AND colA > 5 
  AND colB > 1 
  AND colC > 3; 

すべての述語が非選択的で、colA、colBおよびcolCがビットマップ索引を持つと想定します。Oracle Databaseのコストベース・オプティマイザでは、次の実行計画を選択します。
TABLE ACCESS BY ROWIDS
  BITMAP CONVERSION TO ROWIDS
    BITMAP AND
      BITMAP INDEX COLA_BMX
      BITMAP INDEX COLB_BMX
      BITMAP INDEX COLC_BMX
      BITMAP CONVERSION FROM ROWIDS
        SORT ORDER BY
          DOMAIN INDEX MYINDEX

BITMAP ANDはブロック操作であるため、Oracle Textでは、BITMAP AND操作を実行する前に、Oracle Textのドメイン索引から戻されたROWIDとスコアのペアを一時的に保存する必要があります。
                  

                  
Oracle Textでは、これらのROWIDとスコアのペアをメモリーに保存しようとします。ただし、これらのROWIDとスコアのペアを含む結果セットのサイズがSORT_AREA_SIZE初期化パラメータの値を超える場合は、Oracle Textにより、これらの結果がディスク上の一時セグメントに排出されます。
                  

                  
ディスクに結果を保存すると余分なオーバーヘッドが発生するため、次のようにALTER SESSIONを使用してSORT_AREA_SIZEパラメータを増やすことによって、パフォーマンスが向上します。
                  
alter session set SORT_AREA_SIZE = <new memory size in bytes>;

たとえば、バッファを約8MBに設定するには、次の文を入力します。
alter session set SORT_AREA_SIZE = 8300000;

                     
関連項目:

                     
SORT_AREA_SIZEの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Databaseリファレンス』を参照してください。

                  

               

            
7.9 問合せのパフォーマンスに関するFAQ(よくある質問)
               

               

                  
この項では、問合せのパフォーマンスに関してよくある質問と、それに対する回答を提供します。 

                  
               
7.9.1 問合せのパフォーマンスとは何を意味しますか。
                  

                  

                     
回答: 問合せのパフォーマンスは、一般的に次の2つの基準で判断します。
                     

                     
    
                        
  • 
                           
    応答時間。個々の問合せに対する応答を取得するまでの時間です。 
    
                        
    • 
                        
  • 
                           
    スループット。任意の時間内に実行可能な問合せの数(たとえば、1秒当たりの問合せ数)です。
    
                        
    • 
                     

                     
この2つは関連していますが、同一ではありません。通常、負荷の高いシステムでは高いスループットが必要ですが、比較的負荷の低いシステムではレスポンス時間を最短にすることが必要になります。また、問合せの全ヒットをユーザーに戻す必要があるアプリケーションもあれば、順序付け済セットの最初の20ヒットのみを戻すだけでよいアプリケーションもあります。この2つの状況を区別することが重要です。 

                  

               
7.9.2 テキスト問合せのうち、最速のタイプはどれですか。
                  

                  

                     
回答: 最速タイプの問合せは、次の条件を満たす問合せです。 
                     

                     
    
                        
  • 
                           
    単一のCONTAINS句 
                           
    
                        
    • 
                        
  • 
                           
    WHERE句内に他の条件がない。 
                           
    
                        
    • 
                        
  • 
                           
    ORDER BY句が存在しない。
                           
    
                        
    • 
                        
  • 
                           
    結果の最初のページのみが戻される(たとえば、最初の10ヒットまたは20ヒット)。 
    
                        
    • 
                     

                  

               
7.9.3 表に関する統計を収集する必要がありますか。
                  

                  

                     
回答: はい。表に関する統計を収集しておくと、Oracle Textがコストベースの分析を実行できます。これにより、問合せに最も効率的な実行計画をOracle Textが選択できます。 
                     

                     
問合せが常に簡単なテキスト問合せ(構造化述語および結合がない)の場合、Oracle Text索引の統計を削除する必要があります。

                  

               
7.9.4 データのサイズは問合せにどのように影響しますか。
                  

                  

                     
回答: テキスト索引がROWIDを戻す速度は、データの実際のサイズには影響されません。テキスト問合せの速度は、索引表からフェッチする必要のある行数、要求されるヒット数、問合せにより生成されるヒット数、およびソートの有無に関係します。 
                     

                  

               
7.9.5 データの形式は問合せにどのように影響しますか。
                  

                  

                     
回答: ドキュメントの形式(ASCIIプレーン・テキスト、HTMLまたはMicrosoft Word)は、問合せ速度には影響しません。ドキュメントは、問合せ時ではなく索引付け時にプレーン・テキストにフィルタ処理されます。 
                     

                     
データがクリーンであるかどうかが、問合せに影響します。スペルチェック済で編集作業が行われた出版用のテキストは、スペルミスや略語の多い電子メールなどの非公式のテキストと比べて、合計語彙数がかなり少なくなる傾向にあります(したがって、索引表のサイズも小さくなります)。指定した索引メモリー設定では、余分なテキストがあるとメモリー使用量が多くなり、クリーンなテキストと比べて断片化される行が増え、問合せの応答時間に悪影響を及ぼす可能性があります。 

                  

               
7.9.6 機能的検索と索引付き検索とは、何を意味しますか。
                  

                  

                     
回答: カーネルがテキスト索引に対して問合せを行う方法は2つあります。1つ目は、カーネルがテキスト索引に対して特定のテキスト検索を満たすすべてのROWIDを問い合せる方法であり、これが最も一般的です。これらのROWIDはまとめて戻されます。2つ目の方法では、カーネルが個々のROWIDをテキスト索引に渡し、その特定のROWIDが特定のテキスト基準を満たしているかどうかを問い合せます。 
                     

                     
2つ目の方法は機能的検索と呼ばれ、選択性の高い構造の句が存在する場合はこの方法を使用すると、テキスト索引に対してチェックが必要なROWIDの数はわずかです。機能的検索を使用できる検索の例は、次のとおりです。 
SELECT ID, SCORE(1), TEXT FROM MYTABLE
WHERE START_DATE = '21 Oct 1992'         <- highly selective
AND CONTAINS (TEXT, 'commonword') > 0    <- unselective

構造化列(たとえば、日時や価格など)でORDER BYを行い、テキスト問合せが非選択的な場合にも、機能的検索が使用されます。

                  

               
7.9.7 問合せで使用される表はどれですか。
                  

                  

                     
回答: すべての問合せで、索引トークン表が参照されます。この表の名前は、DR$indexname$Iの形式です。この表には、トークンのリスト(TOKEN_TEXT列)とトークンが発生する行とワードの位置に関する情報(TOKEN_INFO列)が含まれます。 
                     

                     
行情報は内部DOCID値として格納されます。これらは外部ROWID値に変換する必要があります。これに使用される表は、検索のタイプによって決まります。機能的検索の場合は、$K表DR$indexname$Kが使用されます。これは、DOCID/ROWIDの各ペアに対する1行を含む、単純な索引構成表(IOT)です。 
                     

                     
索引付き検索の場合は、$R表(DR$indexname$R)が使用されます。この表のBLOB列にはROWIDの完全なリストが保持されます。
                     

                     
Oracle Database 12cリリース2 (12.2)より、新しい記憶域属性SMALL_R_ROWが導入され、$R行のサイズを削減できるようになりました。22行の静的な行を作成するのではなく、$R行をオンデマンドで移入して、DMLの競合を削減します。並列DMLが挿入または削除操作で同じ$R行をロックしようとすると、競合が生じます。 
                     

                     
このため、SQLトレースを調べて$K表または$R表を検索すれば、機能的検索と索引付き検索のどちらが使用されているかが容易に判断できます。

                     

                        
注意: 

                        
これらの内部索引表は、リリースごとに変更されることがあります。アプリケーションではこれらの表に直接アクセスしないことをお薦めします。

                     

                  

               

               
7.9.8 $R表の競合の軽減方法
                  

                  

                     
ベース表の削除および更新操作中の$R競合はこの数年間繰り返されるテーマになってきています。現在、各$R索引には22行の静的行があり、各行には最大2億個の行IDを含めることができます。並列DMLプロセスが挿入または削除操作で同じ$R行をロックしようとすると、競合が生じます。このリリースの次の拡張機能によって、競合が軽減されます。
                        
    
                           
  • 
                              
    各$R行に含めることができる行IDの最大数は70,000(各行に格納される1MBのデータに変換される)です。この機能を使用するには、SMALL_R_ROW記憶域属性を設定する必要があります。
                              
    
                           
    • 
                           
  • 
                              
    事前に決定した行数が移入されるだけでなく、$R行がオンデマンドで作成されます。 
    
                           
    • 
                        

                     

                  

               
7.9.9 テキストのみの問合せは、結果をソートすると遅くなりますか。
                  

                  

                     
回答: はい。低下します。 
                     

                     
ソートしない場合、Oracle Textは検索したままの結果を戻すことができます。通常、アプリケーションでは結果を一度に1ページずつ表示するため、この方が高速です。 

                  

               
7.9.10 ORDER BYスコアの問合せを高速化するには、どうすればよいですか。
                  

                  

                     
回答: 関連性スコア(SCORE(n))によるソートは、FIRST_ROWS(n)ヒントを使用すると、非常に高速になります。この場合、Oracle Textはテキスト索引表からフェッチするときに高速の内部ソートを実行します。 
                     

                     
このような問合せの例を次に示します。 
              SELECT /*+ FIRST_ROWS(10) */ ID, SCORE(1), TEXT FROM mytable
                WHERE CONTAINS (TEXT, 'searchterm', 1) > 0
                ORDER BY SCORE(1) DESC;

これを効率的に行うには、1つのCONTAINS以外の条件をWHERE句に含めないでください。 
                     

                  

               
7.9.11 どのメモリー設定が問合せに影響しますか。
                  

                  

                     
回答: 問合せを行うには、大規模なシステム・グローバル領域(SGA)を取得する必要があります。SGA関連のパラメータは、Oracle Database初期化ファイルに設定できます。これらのパラメータは動的に設定することもできます。 
                     

                     
SORT_AREA_SIZEパラメータは、ORDER BY問合せのソートで使用可能なメモリーを制御します。構造化列で頻繁にORDER BYを行う場合は、このパラメータのサイズを増やす必要があります。
                     

                     

                        
関連項目:

                        

                        
                     

                  

               
7.9.12 長い列を表外のLOBに格納すると、パフォーマンスは向上しますか。
                  

                  

                     
回答: はい。一般に、SELECT文は元表から複数の列を選択します。Oracle Textでは列をメモリーにフェッチするため、特にこれらの列がほとんど更新されないのに頻繁に選択されるような場合は、元表のLOBなどの長い列は表外に格納する方が効率的です。 
                     

                     
LOBを表外に格納するとき、問合せ中にメモリーにフェッチする必要があるのはLOBロケータのみです。表外に格納すると、元表の有効なサイズが減少し、Oracle Textで表全体をメモリーにキャッシュしやすくなります。これにより、元表から列を選択するコストが低減し、テキスト問合せが高速になります。

                     
さらに、メモリーにキャッシュされる元表が小さくなれば、問合せ中により多くの索引表データをキャッシュできるため、パフォーマンスが向上します。

                  

               
7.9.13 複数の列に対するCONTAINS問合せを高速にするには、どうすればよいですか。
                  

                  

                     
回答: 最も高速の問合せタイプは、WHERE句にCONTAINS句が1つあるのみで、その他の条件が含まれていない問合せです。 
                     

                     
複数のCONTAINSを含む次の問合せについて考えます。 
                     
              SELECT title, isbn FROM booklist
                WHERE CONTAINS (title, 'horse') > 0
                  AND CONTAINS (abstract, 'racing') > 0

セクション検索とWITHIN演算子を次のように使用すると、同じ結果が得られます。
                     
              SELECT title, isbn FROM booklist
                WHERE CONTAINS (alltext, 
                  'horse WITHIN title AND racing WITHIN abstract')>0

この問合せは、さらに高速になります。このような問合せを使用するには、各列のデータをセクション・タグで囲んで、索引付けのためにすべてのデータを1つのテキスト列にコピーする必要があります。これを実行するには、索引付けの前にPL/SQLプロシージャを使用するか、索引付け時にUSER_DATASTOREデータソースを利用して、構造化列とテキスト列を1つのドキュメントに統合します。 
                     

                  

               
7.9.14 問合せに多数の拡張を使用してもかまいませんか。
                  

                  

                     
回答: 問合せに使用されるワードごとに、索引表から少なくとも1行をフェッチする必要があります。このため、拡張の数はできるだけ少なくします。 
                     

                     
ワイルド・カード、シソーラス、ステミングおよびファジー・マッチングなどの拡張は、作業上必要でないかぎり、使用しないようにします。一般的に、問合せに少数の拡張(たとえば10から20)は許容されますが、多数の拡張(80または100)は使用しないでください。問合せ式の拡張の数を判断するには、問合せフィードバック・メカニズムを使用できます。

                     
さらに、ワイルド・カードおよびステミングの問合せの場合は、プリフィックス、サブストリングまたはステム索引を作成すると、問合せ時から索引付け時への語句拡張コストをなくすことができます。問合せのパフォーマンスは上がりますが、索引付けの時間が長くなり、ディスク領域が大きくなります。 

                     
プリフィックス索引およびサブストリング索引により、ワイルド・カードのパフォーマンスが向上します。プリフィックスとサブストリングの索引付けは、BASIC_WORDLISTプリファレンスを使用して使用可能にします。次の例では、プリフィックスとサブストリングの索引付けに対してワードリスト・プリファレンスを設定します。プリフィックス索引付けに対して、3から4文字の長さのトークン・プリフィックスの作成を指定します。
                     
begin 
ctx_ddl.create_preference('mywordlist', 'BASIC_WORDLIST'); 
ctx_ddl.set_attribute('mywordlist','PREFIX_INDEX','TRUE');
ctx_ddl.set_attribute('mywordlist','PREFIX_MIN_LENGTH', '3');
ctx_ddl.set_attribute('mywordlist','PREFIX_MAX_LENGTH', '4');
ctx_ddl.set_attribute('mywordlist','SUBSTRING_INDEX', 'YES');
end

                     
ステム索引付けは、BASIC_LEXERプリファレンスを使用して使用可能にします。
                     
begin
ctx_ddl.create_preference('mylex', 'BASIC_LEXER');
ctx_ddl.set_attribute ( 'mylex', 'index_stems', 'ENGLISH');
end;

               
7.9.15 ローカル・パーティション索引はどのような場合に便利ですか。
                  

                  

                     
回答: ローカル・パーティションCONTEXT索引は、パーティション表に対して作成できます。つまり、パーティション表上では、各パーティションに独自の索引表セットがあることを意味します。実際には複数の索引がありますが、各索引からの結果が必要に応じて組み合され、最終的な結果セットが生成されます。 
                     

                     
この索引は、LOCALキーワードを使用して作成します。 
                     
CREATE INDEX index_name ON table_name (column_name) 
INDEXTYPE IS ctxsys.context
PARAMETERS ('...')
LOCAL

パーティション表およびローカル索引を使用すると、次のタイプのCONTAINS問合せのパフォーマンスが向上します。
                     

                     
                  

               
7.9.16 問合せはパラレルに実行する方がよいですか。
                  

                  

                     
回答: システム負荷およびサーバー容量により異なります。パラレルに作成された索引の場合にはパラレル問合せがデフォルト動作ですが、通常、負荷の高いシステムでは問合せの全体的なスループットが低下します。
                     

                     
一般に、パラレル問合せは、大規模なデータ・コレクションと複数のCPUを備え、同時ユーザー数が少ないDSSや分析システムに特に適しています。

                     

                        
関連項目:

                        
「パラレル問合せの使用」

                     

                  

               
7.9.17 テーマには索引を付けた方がよいですか。
                  

                  

                     
回答: テーマ情報にCONTEXT索引で索引付けすると、時間がかかり、索引のサイズも大きくなります。ただし、テーマ索引を使用すると、ナレッジ・ベースが使用され、ABOUT問合せの精度が上がります。アプリケーションでABOUT問合せが頻繁に使用される場合は、索引に対してテーマ・コンポーネントを作成してみる価値はあります。ただし、索引の作成時間と記憶領域が余分に必要になります。
                     

                     

                        
関連項目:

                        
「ABOUT問合せおよびテーマ」

                     

                  

               
7.9.18 CTXCAT索引はどのような場合に使用すればよいですか。
                  

                  

                     
回答: CTXCAT索引は、テキストが小さなチャンク(最大で数行)になっており、特定の構造化基準(通常は数値または日付)に従って、検索で結果セットを制限またはソートする必要がある場合(あるいはその両方)に、最も効率的に機能します。 
                     

                     
たとえば、オンラインのオークション・サイトについて考えます。各競売対象品目には、短い説明、現在の入札価格、オークションの開始日と終了日が含まれています。この場合、説明に「antique cabinet」が含まれていて、現在の入札価格が$500未満の全レコードを表示するとします。ユーザーが新しく提示される商品に特に興味がある場合は、結果をオークション開始日でソートする必要があります。 
                     

                     
このような検索では、CONTEXT索引に対してCONTAINS構造化問合せを行っても、構造化句およびCONTAINS句に応じてレスポンス時間が大きく異なるため、必ずしも効率的ではありません。これは、構造化句とCONTAINS句の共通部分またはテキスト問合せの順序付けが問合せ時に計算されるためです。
                     

                     
価格や日付などの構造化情報をCTXCAT索引内に含めると、検索条件にかかわらず、問合せ応答時間は常に最適な範囲内にとどまります。これは、テキストと構造化問合せ間の相互作用が、索引付け時に事前に計算されるためです。この結果、問合せ応答時間が最適になります。
                     

                  

               
7.9.19 CTXCAT索引が適さないのは、どのような場合ですか。
                  

                  

                     
回答: 索引作成に要する時間と領域に違いがあります。CTXCAT索引はCONTEXT索引と比べて作成に時間がかかり、使用するディスク領域もかなり多くなります。ディスク領域に余裕がない場合は、CTXCAT索引が適切かどうかを慎重に考慮する必要があります。
                     

                     
問合せ演算子に関しては、CATSEARCH問合せでは問合せテンプレートを使用して、より豊富なCONTEXT文法を使用できるようになっています。CATSEARCH問合せ文法のみを使用する必要があるという古い制限はなくなりました。
                     

                  

               
7.9.20 使用可能なオプティマイザ・ヒントおよびそれらの機能はどのようなものですか。
                  

                  

                     
回答: オプティマイザ・ヒントINDEX(table column)を通常の方法で使用すると、テキスト索引またはBツリー索引を使用した問合せを実行できます。 
                     

                     
NO_INDEX(table column)ヒントを使用すると、特定の索引を使用禁止にすることもできます。
                     

                     
さらに、テキスト問合せではFIRST_ROWS(n)ヒントが特殊な意味を持ち、問合せで最初のn個のヒットが必要な場合に使用できます。DOMAIN_INDEX_SORTヒントをORDER BY SCORE(n) DESCとともに使用すると、Oracleオプティマイザは、ソート済のセットをテキスト索引から受け入れ、それ以上のソートを実行しないように指示されます。
                     

                     

                        
関連項目:

                        
「応答時間短縮のための問合せの最適化」

                     

                  

               

            
7.10 索引付けのパフォーマンスに関するFAQ(よくある質問)
               

               

                  
この項では、索引付けのパフォーマンスに関してよくある質問と、それに対する回答を提供します。 

                  
               
7.10.1 索引付けにはどのくらいの時間が必要ですか。
                  

                  

                     
回答: テキストの索引付けは、リソース集中型の処理です。索引付けの速度は関連するハードウェアの性能に依存します。索引付けの速度はCPUおよびI/O容量により異なります。元のデータの読込みや索引エントリの書込みに十分なI/O容量がある場合、CPUが制限要素となります。
                     

                     
Intel x86(Core 2アーキテクチャ、2.5GHz)CPUを使用したテストでは、Oracle Textでは1日当たりCPUコアごとに約100GBのテキストを索引付けできました。CPUのクロック速度が増すかCPUアーキテクチャがさらに効率的(あるいはその両方)になると、処理量が増えることが予想されます。

                     
ドキュメント形式、データの場所、ユーザー定義データストアのコール、フィルタ、レクサーなどのその他の要因も、索引付けの速度に影響します。 

                  

               
7.10.2 どの索引メモリー設定を使用すればよいですか。
                  

                  

                     
回答: 索引メモリーは、システム・パラメータDEFAULT_INDEX_MEMORYおよびMAX_INDEX_MEMORYを使用して設定できます。また、CREATE INDEXのパラメータ文字列にmemoryパラメータを指定して、索引メモリーを実行時に設定することもできます。
                     

                     
DEFAULT_INDEX_MEMORY値は、ページングが発生しない範囲で、できるだけ高く設定するようにします。 
                     

                     
SORT_AREA_SIZEシステム・パラメータを増やして、索引付けのパフォーマンスを向上させることもできます。
                     

                     
索引メモリーの設定を大きくすることをお薦めします。数百MBまで設定を大きくすると、索引付けの速度が上がり、最終的な索引の断片化が減少します。ただし、索引メモリー設定を高くしすぎると、メモリーのページングが発生し、索引付けの速度が低下します。

                     
索引のパラレル作成では、各プロセスがそれぞれ索引付け用のメモリーを必要とします。巨大な表を扱う場合には、索引作成時と検索時とで、システム・グローバル領域(SGA)のチューニング方法を変えます。問合せでは、システム・グローバル領域(SGA)のブロック・バッファ・キャッシュにできるだけ多くの情報をキャッシュするようにします。このため、ブロック・バッファ・キャッシュには大量のメモリーを割り当てる必要があります。ただし、この設定は索引付けには影響を与えないため、索引作成時には、SGAのサイズを減らして、索引付け処理中の索引メモリー設定を大きくする方が賢明です。

                     
SGAのサイズはOracle Database初期化ファイルで設定します。

                     

                        
関連項目:

                        

                        
                     

                  

               
7.10.3 索引付けにはどの程度のディスク・オーバーヘッドが必要ですか。
                  

                  

                     
回答: オーバーヘッド(索引表に必要な領域の量)は、元のテキスト量の50%から200%までの範囲で様々です。一般に、テキストの総量が多いほどオーバーヘッドは小さくなりますが、小さなレコードが多数あるほうが、大きなレコードが少数あるよりもオーバーヘッドの消費が大きくなります。また、電子メールや討論記録のような未処理のデータにはスペルミスや略語などの特異なワードが数多く含まれている可能性が高いため、クリーンなデータ(出版されたテキストなど)のほうが未処理のデータよりも必要なオーバーヘッドが小さくなります。
                     

                     
テキストのみの索引は、テキストとテーマを組み合せた索引よりも小さくなります。プリフィックス索引およびサブストリング索引では、索引がかなり大きくなります。

                  

               
7.10.4 データの形式は索引付けにどのように影響しますか。
                  

                  

                     
回答: Microsoft Wordファイルのように形式設定されたドキュメントの場合は、ドキュメントに含まれる実際のテキストに比べてサイズが大きくなる傾向があるため、記憶域オーバーヘッドはかなり低くなります。したがって、1GBのWordドキュメントに必要な索引領域が50MBのみであるのに対し、1GBのプレーン・テキストに必要な索引領域は500MBになることがあります。 
                     

                     
索引付けに要する時間については、これほど単純ではありません。索引付け対象のテキスト量が減れば明らかな影響は出ますが、索引付けに要する時間を見積るためには、AUTO_FILTERフィルタまたはその他のユーザー定義フィルタを使用してドキュメントをフィルタ処理する時間を相殺することが必要になります。
                     

                  

               
7.10.5 パラレル索引付けにより、パフォーマンスは向上しますか。
                  

                  

                     
回答: データが大量にあり、CPUも複数ある場合は、パラレル索引付けにより、索引付けのパフォーマンスが向上します。
                     

                     
索引を作成するときに、次のようにPARALLELキーワードを使用します。 
                     
CREATE INDEX index_name ON table_name (column_name) 
INDEXTYPE IS ctxsys.context PARAMETERS ('...') PARALLEL 3;

これで、リソースに応じて最大3つの索引付けプロセスを使用して索引が作成されます。 

                     
また、パラレル索引付けを使用して、パーティション表のローカル・パーティション索引を作成することもできます。ただし、CPUが複数あるときのみ、索引付けのパフォーマンスは向上します。

                     

                        
注意: 

                        
ローカル・パーティション索引を作成するのにPARALLELを使用すると、パラレル問合せが有効になります。(非パーティション索引をパラレルに作成しても、問合せはパラレルに処理されません。)
                        

                        
パラレル問合せは、特に負荷の大きいシステムに対して実行すると、問合せのスループットが低下します。このため、パラレル索引作成後はパラレル問合せを使用禁止にすることをお薦めします。この場合は、ALTER INDEX NOPARALLELを使用します。
                        

                     

                  

               
7.10.6 ローカル・パーティション索引を作成する場合、索引のパフォーマンスを改善するにはどうすればよいですか。
                  

                  

                     
回答: CPUが複数あるときは、ローカル索引をパラレルで作成することで索引付けのパフォーマンスを改善できます。索引付けをパラレルで行うには、次の2つの方法があります。
                     

                     
ローカル・パーティション索引をパラレルで作成するには、次の2つの方法があります。

                     
    
                        
  • 
                           
    CREATE_INDEXで、LOCAL句とともにPARALLEL句を使用します。この場合、最大並列度はユーザーが持つパーティションの数によって制限されます。
                           
    
                        
    • 
                        
  • 
                           
    UNUSABLEの索引を作成してから、DBMS_PCLXUTIL.BUILD_PART_INDEXユーティリティを実行します。この方法により、特にパーティションより多くのCPUを使用している場合に、並列性が高くなります。
                           
    
                        
    • 
                     

                     
2つ目の方法の例を次に示します。この例の元表には3つのパーティションがあります。まず使用禁止のローカル・パーティション索引を作成してから、DBMS_PCLUTIL.BUILD_PART_INDEXを実行すると、3つのパーティションがパラレルに作成されます(パーティション間並列性)。また、各パーティション内では、索引作成が並列度2でパラレルに実行されます(パーティション内並列性)。
                     
create index tdrbip02bx on tdrbip02b(text) 
indextype is ctxsys.context local (partition tdrbip02bx1, 
                                   partition tdrbip02bx2, 
                                   partition tdrbip02bx3) 
unusable; 

exec dbms_pclxutil.build_part_index(3,2,'TDRBIP02B','TDRBIP02BX',TRUE); 

               
7.10.7 索引付けがどの程度完了したかはどうすればわかりますか。
                  

                  

                     
回答: CTX_OUTPUT.START_LOGプロシージャを使用すると、索引付けプロセスからの出力を記録できます。ファイル名は、通常$ORACLE_HOME/ctx/logに書き込まれますが、CTX_ADM.SET_PARAMETERでLOG_DIRECTORYパラメータを使用してディレクトリを変更できます。 
                     

                     

                        
関連項目:

                        
このプロシージャの使用方法の詳細は、『Oracle Textリファレンス』を参照してください。
                        

                     

                  

               

            
7.11 索引の更新に関するFAQ(よくある質問)
               

               

                  
この項では、索引の更新と関連するパフォーマンスの問題に関してよくある質問と、それに対する回答を提供します。

                  
               
7.11.1 新規または更新されたレコードの索引付けは、どのくらいの頻度で行う必要がありますか。
                  

                  

                     
回答: CTX_DDL.SYNC_INDEXを使用して再索引付けを実行する頻度が低いほど、索引の断片化が少なくなり、索引の最適化を実行する頻度も低く抑えることができます。
                     

                     
ただし、これではデータが次第に古くなるため、ユーザーにとっては不便になる可能性があります。 

                     
ほとんどのシステムでは、毎日の夜間の索引付けで対応可能です。この場合、作成されてから1日未満のデータは検索できないということになります。毎時、10分ごとまたは5分ごとに更新を行うシステムもあります。

                     

                        
関連項目:

                        

                        
                     

                  

               
7.11.2 索引の断片化は、どのようにするとわかりますか。
                  

                  

                     
回答: 最善の方法は、いくつかの問合せに要する時間を測定してから、索引の最適化を実行し、その後で同じ問合せの時間を再度測定することです(SGAをクリアするために、その都度データベースを再起動する必要があります)。問合せの速度が大幅に上がっている場合は、最適化が有効であったことを示しています。そうでない場合は、次回は待機時間が長くなる可能性があります。   
                     

                     
索引の断片化の分析には、CTX_REPORT.INDEX_STATSを使用することもできます。
                     

                     

                        
関連項目:

                        

                        
    
                           
  • 
                              
    CTX_REPORTパッケージの使用方法の詳細は、『Oracle Textリファレンス』を参照してください。
                              
    
                           
    • 
                           
  • 
                              
    「索引の最適化」
    
                           
    • 
                        

                     

                  

               
7.11.3 メモリー割当ては索引の同期化に影響しますか。
                  

                  

                     
回答: はい。通常の索引付けへの影響と同じです。同期操作中に索引付けされるレコード数が大幅に少ないことが多いので、通常は索引付けのメモリーに数百MBも準備する必要はありません。