| Oracle® Fusion Middleware Oracle WebCenter Contentの管理 12c (12.2.1.1) E77332-02 |
|
 前へ |
 次へ |
この章の内容は次のとおりです。
コンテンツ・サーバーは、商用検索エンジンやデータベースなどの検索付けツールと接続して一緒に機能します。使用する検索付けツールは、コンテンツ・サーバー・インスタンスが機能する目的や環境に基づいて、インストール前に選択されます。
各索引付けツールには、フルテキストの索引付けとメタデータのみの索引付け機能があります。フルテキストの索引付けでは、ファイル内のメタデータのみでなく、すべての語に索引が付けられます。フルテキストの索引付けは、メタデータの索引付けより時間がかかりますが、より包括的な結果セットが得られます。メタデータのみの索引付けでは、格納されたコンテンツ情報のすべての語に索引が付けられます。メタデータのみの索引付けは、フルテキストの索引付けよりも高速です。デフォルトでは、コンテンツ・サーバー・インスタンスは、メタデータのみの索引付けを使用するように構成されます。
システムが、データベースによる索引付けおよび検索機能を使用できるように設定されているとすれば、担当のシステム・インテグレータがIntradocDir/config/config.cfgファイルに次のいずれかの行を追加しているものと考えられます。
メタデータ検索のみ:
SearchIndexerEngineName=DATABASE.METADATA
DATABASE.METADATAは、Oracle Fusion Middleware 12cリリースによってサポートされるすべてのデータベースでサポートされています。
フルテキスト検索:
SearchIndexerEngineName=ORACLETEXTSEARCH
Oracle Databaseリリース11.1.0.7以上では、ORACLETEXTSEARCHがサポートされます。
フルテキスト検索:
SearchIndexerEngineName=DATABASE.FULLTEXT
SQL ServerおよびOracle Database(サポートされている全リリース)で、DATABASE.FULLTEXTがサポートされます。
サポートされているデータベースに適したdbfulltextsearchスクリプトが実行されます。
デフォルトでは、フルテキスト索引付けは、変換されたすべてのファイルに適用されます。
デフォルトでは、次のいずれかのフォーマットを経た、またはそのフォーマットに変換されたファイルに、コンテンツ・サーバーはフルテキスト索引を付けます。
Oracleでサポートされているフォーマット
html
htm
xls
hcsp
text
txt
doc
rtf
ppt
MS SQLでサポートされているフォーマット
text
txt
htm
html
doc
msword
ms-word
ms-powerpoint
ppt
ms-excel
xls
たとえば、Microsoft Word(.doc)ファイルをPDFのかわりにテキスト・ファイルに変換する場合、構成マネージャでこれを指定できます。つまり、「ファイル・フォーマット」オプションを使用して、.docファイル拡張子をテキスト・フォーマットにマップすると、これによってそのファイルがどのようにWeb表示可能フォーマットに変換されるかが定義されます。この場合、テキスト・ファイルは、Webサイトに渡される前に完全に索引付けされます。
構成マネージャの「ファイル形式」オプションの詳細は、『Oracle WebCenter Contentのマネージング』を参照してください。
「システム・プロパティ」ユーティリティでフォーマット・オーバーライド機能を有効にすれば、コントリビュータがファイルのフルテキスト索引付けをするかどうかを指定できます。詳細は、「一般オプションの構成」を参照してください。
たとえば、構成マネージャの「ファイル形式」オプションを使用して、Corel WordPerfect (.wpd)ファイルをtextフォーマットが使用できるようにマップしている場合、コントリビュータがチェックイン・ページの「フォーマット」フィールドで「デフォルトの使用」オプションを選択すると、ファイルはテキストに変換され、フルテキスト索引が付けられます。コントリビュータが「Corel WordPerfectドキュメント」を選択した場合、ファイルはネイティブ・フォーマットで渡され、フルテキスト索引付けは行われません。
構成マネージャの「ファイル形式」オプションの詳細は、『Oracle WebCenter Contentのマネージング』を参照してください。
フルテキスト検索を使用する場合、メタデータ検索では大文字と小文字が区別され、フルテキスト検索では区別されません。ただし、コンテンツIDの場合、小文字が大文字に変換されるため、小文字では検索できません。
注意:
索引付けのエラーを防ぐために、存在しないメタデータ・フィールドを構成マネージャのDrillDownFieldsパラメータに追加しないでください。また、SDATAセクションまたはDrillDownFieldsパラメータにメモ・フィールドを追加しないでください。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』を参照してください。
次の項では、その他の検索索引構成の手順を示します。
SQL ServerおよびOracle Database(サポートされているすべてのバージョン)におけるフルテキストのデータベース検索および索引付けを設定して使用する手順は、次のとおりです。
OracleTextSearch (Oracle Databaseバージョン11.1.0.7以降でサポートされています)によるフルテキストの検索および索引付けを設定して使用する手順は、次のとおりです。
OracleTextSearchの詳細は、「OracleTextSearchの管理」を参照してください。
次の2つの設定のどちらかを使用してWebCenter Contentで全文検索を使用する場合、データベースではOracle Text索引を使用して検索のためのデータを管理します。
SearchIndexerEngineName=OracleTextSearch SearchIndexerEngineName=DATABASE.FULLTEXT
Oracle Text検索を使用する際は、ディスクが断片化されないようにするためにデータベース上の索引を維持する必要があります。断片化を防ぐには、optimize_indexプロシージャを毎週実行する必要があります。このプロシージャは、WebCenter Contentのデータベース管理者がスケジュールする必要があります。
アクティブな索引の判別
WebCenter Contentシステムでどれがアクティブな索引であるかを判別するには、WebCenter Contentシステムにログインし、「管理」を選択し、「インスタンスの構成」を選択します。「構成」ページで、Oracle Text Searchに対して次のような情報が表示されます。
Search Engine::ORACLETEXTSEARCH Index Engine Name:ORACLETEXTSEARCH Active Index:ots2
全文検索データベースに対して次のような情報が表示されます。
Search Engine::DATABASE.FULLTEXT Index Engine Name:DATABASE.FULLTEXT Active index:IdcColl1
「アクティブな索引」の値は、データベース内でアクティブな表と索引を示します。
| SearchIndexerEngineName | アクティブな表 | データベース表 | データベース索引 |
|---|---|---|---|
OracleTextSearch |
ots1 |
IDCTEXT1 |
FT_IDCTEXT1 |
OracleTextSearch |
ots2 |
IDCTEXT2 |
FT_IDCTEXT2 |
DATABASE.FULLTEXT |
IdcColl1 |
IDCCOLL1 |
FT_IDCCOLL1 |
DATABASE.FULLTEXT |
IdcColl2 |
IDCCOLL2 |
FT_IDCCOLL2 |
Oracle Text索引に最適化が必要かどうかの決定
Oracle Text索引が断片化されており最適化の必要があるかどうかを決定するために、CTX_REPORTパッケージのINDEX_STATSというレポートに、Oracle Text検索に使用されるWebCenter Content索引がわかりやすく表示されます。CTX_REPORTパッケージの詳細は、Oracle Textリファレンス・ガイドを参照してください。
optimize_indexプロシージャの実装
データベース管理者がデータベース上でoptimize_indexプロシージャを毎週(通常週末または使用量が少ないとき)またはデータベース管理者の推奨に従って必要に応じて実行するスケジュールを作成するようリクエストします。パラメータはプロシージャへのコール内で調整できますが、デフォルトの実行では次の例に示すパラメータが使用されます。
begin
CTX_DDL.OPTIMIZE_INDEX('FT_IDCTEXT1','FULL',parallel_degree=>'1');
end;
初めてoptimize_indexプロシージャを実行すると、データベースに大量のログが作成される場合があります。optimize_indexが完了できないか、データベース上のログ・ファイルがいっぱいになっている場合は、データベースをNOARCHIVELOGモードで再起動してから、optimize_indexプロシージャを実行してください。最適化プロシージャが完了したら、データベースをARCHIVELOGモードで再起動します。
ファイル形式をネイティブ・フォーマットでPASSTHRUに定義し、そのフォーマット名に前述のリストにあるタイプの1つが含まれている場合(application/ms-excel.nativeなど)、通過するネイティブ・ファイルにはデフォルトでフルテキスト索引が作成されます。
または、構成変数を使用して、ドキュメントにフルテキスト索引を作成するかどうかを制御することもできます。特定のドキュメント・フォーマット・タイプのフルテキスト索引および検索を管理するには、IntradocDir/config/config.cfgに該当するエントリを追加し、ファイルを保存します。フルテキスト索引付け構成変数には、次のものがあります。
FormatMap構成変数は、フルテキスト検索索引に特定のフォーマットを含めるべきかどうかを制御します。これは、フルテキスト索引付けの対象となるすべてのフォーマットのカンマ区切りのリストです。ファイルに割り当てられたMIMEタイプを取得し、MIMEタイプをスラッシュ(/)またはピリオド(.)で分割し、その値がFormatMapリストにあるかどうかを調べることで決定します。
たとえば、application/vnd.mswordは、次の3項目のリストになります。
application
vnd
msword
FormatMapのリストにmswordがある場合、インデクサ・エンジンではファイルにフルテキスト索引付けが試みられ、比較テストでは大文字と小文字は区別されません。
使用されている検索エンジンにより、Content Serverはメタデータのみか、またはメタデータとコンテンツ・アイテムのフルテキストの両方を索引付けします。デフォルトでは、コンテンツ・アイテムのファイル形式およびいくつかのそれ以外のファイル関係の考慮事項に基づいて、フルテキストの索引付けが実行されます。
コンテンツ・アイテムが検索索引に転送される前に、Content Serverはstd_indexable_format_scriptリソースを実行します。デフォルトの索引付け条件を変更するには、カスタム・コンポーネントを作成して、std_indexable_format_scriptリソースを変更します。たとえば、MIMEタイプに基づき、またはカスタム・メタデータ・フィールドを含むメタデータ・フィールドの値に基づき、コンテンツ・アイテムのフルテキストの索引付けを選択的に含めるまたは除外することができます。
この項の内容は次のとおりです。
カスタム・コンポーネントの作成の詳細は、『Oracle WebCenter Contentでの開発』を参照してください。
std_indexable_format_scriptリソースのデフォルト・スクリプトは次のとおりです。
<@dynamichtml std_indexable_format_script@> <$loop DocIndexableFormats$> <$if DocIndexableFormats.fileSize <= MaxIndexableFileSize and DocIndexableFormats.fileSize >= MinIndexableFileSize$> <$indexableFilePath = DocIndexableFormats.filePath$> <$indexableFileSize = DocIndexableFormats.fileSize$> <$indexableFileURL = DocIndexableFormats.url$> <$if isFalse(DocIndexableFormats.allowDirectIndex) and isTrue(DocIndexableFormats.allowConversion)$> <$indexerConversionHandler = DocIndexableFormats.conversionHandler$> <$endif$> <$if isTrue(DocIndexableFormats.useMap)$> <$indexerUseMap = "1"$> <$indexerMapExtension = DocIndexableFormats.mapExtension$> <$endif$> <$break$> <$endif$> <$endloop$> <@end@>
このスクリプトはコンテンツ・アイテムと索引付け可能形式のリストを比較します。一致を検出すると、ファイルが確立されたサイズ範囲内であるかどうかを判断し、コンテンツ・アイテムに索引関係値の数を設定します。
シナリオ1:
ユーザーが特定のドキュメント・タイプにチェックインするときに、コンテンツ・アイテムの索引付けに、メタデータのみを使用するか、またはメタデータとフルテキストの両方を使用するかのいずれかを選択できます。
方法1:
ドキュメントの索引付けに、メタデータのみを使用するか、またはメタデータとフルテキストの両方を使用するかをユーザーが指定できるようにするには、次の2つの値を含むリストを使用してカスタム・メタデータ・フィールド(xIsFullTextSearchableなど)を作成します: YesおよびNo (Yesがデフォルト)。そのため、ユーザーがアカウンティング・データを含むドキュメントにチェックインすると、フルテキストを使用して索引付けできず、xIsFullTextSearchableの値はNoに設定されます。
この方法を実装するには、カスタム・フィールドの値をチェックする新しいIF文にデフォルトのリソース・コードを含むカスタム・コンポーネントを作成します。
<@dynamichtml std_indexable_format_script@> <$if strEquals(xIsFullTextSearchable, "Yes")$> <$loop DocIndexableFormats$> . . . <$endloop$> <$endif$> <@end@>
シナリオ2:
それ自体が索引付けされたコンテンツ・アイテムのWeb表示可能レンディションに対し、フルテキスト索引を実行しないでください。
方法2:
この方法を実装するには、FormatTypeの値をチェックして、アイテムがネイティブ・ファイル(FormatType="vault")またはWeb表示可能レンディション(FormatType="webviewable")であるかを判断する新しいIF文にデフォルトのリソース・コードを含むカスタム・コンポーネントを作成します。
<@dynamichtml std_indexable_format_script@> <$if strEquals(FormatType, "vault")$> <$loop DocIndexableFormats$> . . . <$endloop$> <$endif$> <@end@>
この項の項目は次のとおりです。
リポジトリ・マネージャ・ユーティリティには、管理者が検索索引に対してアクションを実行するために使用できる「インデクサ」タブがあります。
リポジトリ・マネージャにアクセスするには、「管理」→「管理アプレット」→「リポジトリ・マネージャ」を選択します。リポジトリ・マネージャには、スタンドアロン・アプリケーションとしてアクセスすることもできます。詳細は、スタンドアロン・モードでの管理アプリケーションの実行を参照してください。
リポジトリ・マネージャ・ウィンドウの「インデクサ」タブでは、管理者が次のアクションを実行できます。
検索索引の更新: 索引データベースを追加的に更新します。索引はサーバーにより約5分ごとに自動的に更新されるため、これは通常必要ありません。
コレクションの再構築: 検索索引が完全に再構築され、古い索引コレクションは新しい索引コレクションに置き換えられます。
更新または再構築の一時停止: 更新または再構築を一時的に停止します。適切な「開始」ボタンをクリックすることで、プロセスを再開できます。
検索更新の取消し: 索引の更新プロセスが終了し、その時点までに処理されたファイルのみが検索エンジンでアクセス可能になります。
コレクション再構築の取消し: 索引再構築プロセスが終了し、前の索引データベースが引き続き検索エンジンによって使用されます。
リポジトリの管理方法の詳細は、『Oracle WebCenter Contentのマネージング』を参照してください。
注意:
OracleTextSearchには高速再構築機能があり、サイトでOracleTextSearch機能を使用する場合、リポジトリ・マネージャのインデクサ機能から使用できます。詳細は、「高速再構築」を参照してください。
索引付けエンジンとしてDATABASE.FULLTEXTまたはORACLETEXTSEARCHを使用するようにコンテンツ・サーバー・インスタンスを構成した場合、コンテンツ・サーバーでは、Outside Inコンテンツ・アクセス・モジュールを使用して、チェックイン時にコンテンツをテキスト・ファイルにエクスポートします。その後、テキスト・ファイルは、フルテキスト索引付けのためにフルテキスト・インデクサに渡されます。
注意:
Outside Inコンテンツ・アクセス・モジュールでPostScriptファイルを変換する際、変換プロセスで余分な文字を含むテキストが生成されます。残念ながらこれにより、フルテキスト索引付けされてもフルテキスト検索ができないファイルが作成されます。
DATABASE.FULLTEXTを使用する場合、フルテキスト検索は、大きなドキュメントでは問題になる可能性があります。デフォルトでは、索引付けされる最大のドキュメント・サイズは10MBです。これは、コンテンツ・サーバー・リポジトリでMaxIndexableFileSize構成変数を設定すれば変更できます。デフォルトは、MaxIndexableFileSize=10485760です。それより大きなドキュメントでフルテキスト索引付けが必要な場合は、MaxIndexableFileSizeの値を増やす必要があります。
Oracleデータベースでフルテキスト検索を使用している場合(OracleTextSearchおよびDATABASE.FULLTEXTの両方の検索方法に適用される)、検索コレクションを最適化する方法の詳細は、「全文検索の最適化」およびhttps://blogs.oracle.com/kyle/entry/full_text_indexing_you_mustを参照してください。
たとえば、ファイル・スペースを節約したり、特定のコンテンツ・タイプにフルテキスト検索が不要な場合などには、フルテキスト索引付けを無効にできます。フルテキスト索引付けを無効にしても、メタデータには索引が付けられます。
特定のファイルに対してフルテキスト索引付けを無効にするには、次のようにします。
検索索引では、索引付けにデフォルトでWebレイアウト・ファイルを使用します。状況によっては、Webレイアウト・ファイルのかわりに、デフォルトでネイティブ・ファイルに索引を付ける方が便利な場合があります。たとえば、処理上の問題のために、変換されたPDFファイルを抽出して索引付けできない場合、ネイティブのWordドキュメントまたはかわりのタイプのドキュメントを抽出して、索引を付けることができます。あるいは、プライマリ・ファイルが.exeファイルであるために索引付けできなくても、かわりの.txtファイルがある場合、そのファイルに索引付けができます。
検索索引で、ネイティブ・ファイルをデフォルトで索引付けに使用できるようにするには、コンテンツ・サーバー・インスタンスで次のパラメータを設定します。
UseNativeFormatInIndex=true
この項で説明する機能は、データベース検索の「次を含む」演算子機能をインストールし、有効にしてある場合にのみ使用可能です。
注意:
この機能は、OracleTextSearchコンポーネントでは必要ありません。
この項の項目は次のとおりです。
データベース検索の「次を含む」演算子を使用すると、SQLサーバーおよびOracleでデータベースおよびデータベース・フルテキスト検索を実行する際、テキスト・フィールドの検索に「次を含む」検索演算子を使用できます。まず、「次を含む」検索演算子を使用して問合せができるテキスト・フィールドを有効にする必要があります。これらのテキスト・フィールドは、ゾーン・テキスト・フィールドと呼ばれます。
テキスト・フィールドがゾーン・テキスト・フィールドとして追加されると、そのフィールド内のテキストは解析され、データベースにフィールドのフルテキスト索引が作成されます。データベースにより索引作成の全作業が実行され、そのテキスト・フィールドがゾーン・テキスト・フィールドとして無効になると、索引はデータベースから削除されます。したがって、テキスト・フィールドをゾーン・テキスト・フィールドとして有効または無効にした後で、コレクションを再構築する必要はありません。
重要
テキスト・フィールドをゾーン・テキスト・フィールドに変更すると、非常に時間がかかる場合があります。この処理で、テキストを解析し、フルテキスト索引を作成するのに要する時間は、コンテンツ・サーバー・リポジトリにあるコンテンツ・アイテムの数と、テキスト・フィールドに格納されているテキストの量によって異なります。ただし、テキスト・フィールドに索引が付いていると、コンテンツ・アイテムの更新および追加時に、パフォーマンスが大幅に低下することはありません。
テキスト・フィールドがゾーン・テキスト・フィールドとして有効になっていると、「拡張検索」ページでそのテキスト・フィールドに対してCONTAINS検索演算子を使用できます。それは、そのテキスト・フィールドの隣のリストに、「語を含む」オプションとして表示されます。
注意:
ここで説明する機能は、データベース検索の「次を含む」演算子機能をインストールし、有効にしてある場合にのみ使用可能です。ゾーン・テキスト・フィールド機能は、OracleTextSearchコンポーネントでは必要ありません。
ゾーン・テキスト・フィールドを有効または無効にする際、次のことを考慮してください。
カスタム・テキスト・フィールド(「コメント」テキスト・フィールドおよびカスタマ作成のテキスト・フィールド)がデータベースとデータベース検索エンジンとの間で共有されるため、一方の検索エンジンでこれらのテキスト・フィールドのステータスを変更すると、その変更がもう一方の検索エンジンにも適用されます。
標準テキスト・フィールド(「作成者」、「コンテンツID」、「コンテンツ・タイプ」、「タイトル」など)は、検索エンジンごとに有効化または無効化できます。
データベースにより索引作成の全作業が実行され、そのテキスト・フィールドがゾーン・テキスト・フィールドとして無効になると、索引はデータベースから削除されます。したがって、テキスト・フィールドをゾーン・テキスト・フィールドとして有効または無効にした後で、コレクションを再構築する必要はありません。
ゾーン・テキスト・フィールドは、無効にしなければ、構成マネージャを使用してコンテンツ・サーバー・インスタンスから削除できません。有効なテキスト・フィールドを構成マネージャを使用して削除し、「データベース設計の更新」をクリックすると、エラーが発生します。
ゾーン・テキスト・フィールドを無効にすることで、そのフィールドの索引がデータベースから削除され、フィールドをデータベースから削除できます。ゾーン・テキスト・フィールドを無効にするかわりに、データベースにログインし、フィールドの索引を削除するコマンドを発行して、フィールドを削除することもできます。
すべてのゾーン・テキスト・フィールドを無効する場合は、機能をアンインストールする前に行います。そうしないと、手動でゾーン・テキスト・フィールドを無効にするか、またはゾーン・テキスト・フィールドの索引をデータベースから削除する機能を再インストールしないかぎり、ゾーン・テキスト・フィールドをコンテンツ・サーバー・インスタンスから削除することはできません。
ゾーン・テキスト・フィールドを有効および無効にする手順は次のとおりです。
「管理」→「ゾーン・フィールドの構成」を選択します。
注意:
カスタム・テキスト・フィールド(「コメント」テキスト・フィールドおよびカスタマ作成のテキスト・フィールド)は、Database検索エンジンとDatabaseFullText検索エンジンとの間で共有されます。したがって、一方の検索エンジンでこれらのテキスト・フィールドのステータスを変更すると、その変更がもう一方の検索エンジンにも適用されます。標準テキスト・フィールド(「作成者」、「コンテンツID」、「コンテンツ・タイプ」、「タイトル」など)は、検索エンジンごとに有効化または無効化できます。
「ゾーン・フィールドの構成」ウィンドウで、ゾーン・テキスト・フィールドの検索に使用する検索エンジン(DatabaseまたはDatabaseFullTextのどちらか)を選択します。
テキスト・フィールドをゾーン・テキスト・フィールドとして有効にする手順は次のとおりです。
「テキスト・フィールド」リストで、(選択した検索エンジンの)テキスト・フィールドを選択します。[Ctrl]キーおよび[Shift]キーを押して、複数のフィールドを選択できます。
デフォルトでは、フィールド長が20文字以下のテキスト・フィールドは「テキスト・フィールド」リストに掲載されません。この設定を変更するには、MinFullTextFieldLength構成変数を変更します。詳細は、「テキスト・フィールドの最小限の長さの変更」を参照してください。
左矢印ボタンをクリックして、テキスト・フィールドを「ゾーン・テキスト・フィールド」リストに移動します。
「更新」をクリックします。このアクションは、「ゾーン・テキスト・フィールド」リストのテキスト・フィールドをゾーン・テキスト・フィールドとして有効化し、「テキスト・フィールド」リストのテキスト・フィールドを無効化します。また、すべてのゾーン・テキスト・フィールド内のテキストを解析し、Contains検索演算子を使用して問い合せることができるフルテキスト索引を作成します。
重要
テキスト・フィールドをゾーン・テキスト・フィールドに変更すると、非常に時間がかかる場合があります。この処理で、テキストを解析し、フルテキスト索引を作成するのに要する時間は、コンテンツ・サーバー・リポジトリにあるコンテンツ・アイテムの数と、テキスト・フィールドに格納されているテキストの量によって異なります。ただし、テキスト・フィールドに索引が付けられている場合は、コンテンツ・アイテムを更新および追加するとき、パフォーマンスが大幅に低下することはありません。
ゾーン・テキスト・フィールドを無効にする手順は次のとおりです。
「ゾーン・テキスト・フィールド」リストでゾーン・テキスト・フィールドを選択します。[Ctrl]キーおよび[Shift]キーを押して、複数のフィールドを選択できます。
右矢印ボタンをクリックして、テキスト・フィールドを「テキスト・フィールド」リストに移動します。
「更新」をクリックします。
リストの変更開始後に、最後に保存したリストに戻る場合は、「リセット」をクリックします。
注意:
ここで説明する機能は、データベース検索の「次を含む」演算子機能をインストールし、有効にしてある場合にのみ使用可能です。ゾーン・テキスト・フィールド機能は、OracleTextSearchコンポーネントでは必要ありません。
デフォルトでは、フィールド長が20文字以下のテキスト・フィールドは「テキスト・フィールド」リストに掲載されません。この設定を変更するには、MinFullTextFieldLength構成変数を変更します。この変数を変更する手順は次のとおりです。
注意:
ここで説明する機能は、データベース検索の「次を含む」演算子機能をインストールし、有効にしてある場合にのみ使用可能です。ゾーン・テキスト・フィールド機能は、OracleTextSearchコンポーネントでは必要ありません。
データベース検索の「次を含む」演算子を無効にする前に、すべてのゾーン・テキスト・フィールドを無効にできます。データベースには、有効なゾーン・テキスト・フィールドごとに索引が保存されています(索引は、ゾーン・テキスト・フィールドが無効になると削除されます)。データベースにフィールドの索引が保存されている場合、構成マネージャを使用してそのフィールドをコンテンツ・サーバー・インスタンスから削除することはできません。詳細は、「ゾーン・テキスト・フィールドの有効化および無効化」を参照してください。
機能を無効にした後で、ゾーン・テキスト・フィールドとして有効なフィールドを削除する場合は、次のいずれかの方法があります。
機能を再インストールし、ゾーン・テキスト・フィールドを無効にして、構成マネージャでフィールドを削除してから、機能をアンインストールします。
データベースにログインし、フィールドの索引を削除するコマンドを発行してから、構成マネージャを使用してフィールドを削除します。
OracleQueryOptimizerコンポーネントは、デフォルトではコンテンツ・サーバー・インスタンスによりインストール(有効化)されます。この機能は、Oracleデータベースでのみ機能します。
この項の項目は次のとおりです。
Oracleデータベースでは、一部のタイプのユーザー問合せに対して、最良の実行計画が自動的に選択されません。これに対処するため、Oracle Query Optimizerにより、Oracleデータベースで検索がより効率的に実行されるようにするヒントを問合せに追加します。
ヒントは、コンテンツ・サーバーの表データ配布およびその索引選択性の本質的な知識に基づいています。この知識を利用するために、Oracle Query Optimizerでは、事前定義のヒント・ルール表を使用して、データベース問合せを分析し、その問合せに適切なヒントを追加します。その結果、追加されたヒントにより、Oracleの検索効率が改善されます。
Oracle Query Optimizerでは、Content Serverのデータベース表でのデータ配布と、その索引選択プリファレンスを利用します。これらの特性に基づき、Oracle Query Optimizer付属のヒント・ルール表には、事前定義のルールが含まれています。この機能では、これらのルールを使用してデータベース問合せを分析し、検索効率を最適化するための1つ以上の適切なヒントを追加します。
数百万のコンテンツ・アイテムを含む非常に大きなコレクションでは、通常、コンテンツ・サーバー・ソフトウェアは、簡単な問合せを解決する場合でも、適切な最適化戦略をなかなか選択できません。この問題に対処するために、Oracle Query Optimizerでは、発行された問合せを検査し、その分析に基づいて、検索プロセスを最適化する適切なヒントを追加することで、問合せを再フォーマットします。この機能では、ヒントを追加するために、コンテンツ・サーバーのヒント、ヒント・ルール表およびヒント・キャッシュが使用されます。
最適化プロセスのステージは、次の順序で完了します。
発行された問合せは、1つ以上のヒントが含まれているかどうかを確認し、含まれる場合は、ヒントのタイプ判断するために分析されます。詳細は、「ステージ1: 問合せ分析」を参照してください。
問合せのWHERE句にヒントが含まれていない場合、最適化機能によりWHERE句を解析する必要があります。詳細は、「ステージ2: 解析」を参照してください。
解析後、問合せのWHERE句の各条件が、ヒント・ルール表に照合して評価され、条件の修飾および正規化が試みられます。詳細は、「ステージ3: 正規化」を参照してください。
WHERE句の条件が修飾され、問合せが正規化されると、ヒントが選択されるか、ヒント・キャッシュから取得されます。詳細は、「ステージ4: ヒントの選択」を参照してください。
問合せは選択したヒントを使用して再フォーマットされます。詳細は、「ステージ5: 問合せの再フォーマット」を参照してください。
このステージでは、Oracle(ネイティブ)とコンテンツ・サーバーの両方のヒントがないか、問合せをチェックします。これは、ヒント構文に基づいて判断されます。「問合せヒント構文」を参照してください。Oracleヒントが含まれる問合せは通過します。コンテンツ・サーバーのヒントが含まれる問合せは、ステージ2: 解析およびステージ3: 正規化を迂回して先に進みます。問合せに複数のコンテンツ・サーバーのヒントが含まれる場合、最良のヒントが選択されます。ヒントが含まれていない問合せは、解析と正規化化が必要です。
このステージでは、ヒントが含まれていない問合せが問合せパーサーを通して送られ、WHERE句が解析されます。WHERE句は、ANDまたはORのいずれかの接続詞で接続された1つ以上の条件で構成されています。条件ごとに、フィールド名、演算子およびフィールド値が抽出されます。句のANDまたはOR接続詞は残されますが、カッコは削除されます。条件には次のフォーマットを使用する必要があります。
fieldnameoperatorvalue
たとえば、正しいフォーマットの条件はdID = 3となります。3 = dIDは間違った条件です。
このステージでは、正規化により条件を単純化し、問合せ演算子を確定して、追加の手順のためにWHERE句の表示を安定させます。正規化プロセスの結果は、キャッシュ・キーと、ヒント検索に使用するフィールドのリストを生成するための基礎となります。
注意:
どのデータベース表や列に索引を付けるかを設定するために、ヒント・ルール表がコンテンツ・サーバー・リソースおよび実行中のシステムで定義されます。
WHERE句の条件の修飾:
WHERE句内の各条件は、ヒント・ルール表に照合してチェックされます。条件のフィールド名がヒント・ルール表に含まれている場合、それが修飾され、正規のものとみなされます。条件には、その表の名前とエイリアスが含まれます。次に、正規化された条件は、同じセットの条件が常に一貫してリストに表示されるようにソートされます。
正規化時のWHERE句条件の破棄:
正規化時に、次の条件は不適切とみなされて、その後の処理から除外されます。
結合条件。
副問合せを含む条件。
フィールド名にヒント・ルール表内のエントリが含まれておらず、修飾できない条件。
複数のフィールドを含むOR条件。次に例を示します。
(dSecurityGroup = 'Secure' or dDocAccount LIKE 'prj%')
値がワイルドカードで始まるLIKE演算子を含む条件。
WHERE句条件の再フォーマット:
正規化の手順で、問合せ条件は、複雑な問合せ条件をまとめるために書き換えられます。OR条件は、次のように再評価されます。
すべてのフィールドが同じで、すべての演算子が等しい(またはすべての演算子がLIKEで、ワイルドカードで始まる値がない)場合、条件は結合され、1つのIN問合せに変更されます。
フィールドは同じでも、演算子が異なる場合、条件は結合され、汎用演算子が割り当てられます。
フィールドが異なる場合、条件は削除されます。
たとえば、正規化中に、次の条件は再フォーマットされます。
(dReleaseState = 'Y' OR dReleaseState = 'O")
これは次のように再フォーマットされます。
dReleaseState IN ('Y', 'O')
使用可能な範囲問合せの確認:
解析した問合せは、使用可能な範囲問合せがないか分析され、それらは正規化のプロセスでまとめられます。たとえば、条件dIndate > date1およびdInDate < date2は、range演算子を使用して1つの条件にまとめられます。
このステージでは、正規化された条件が、ヒント・キャッシュに照合してチェックされます。1つ以上の条件で、キャッシュ内に適用可能なヒントが見つかった場合、それらは含まれます。キャッシュで適用可能なヒントが見つからない場合、条件は分析され、考えられる最良のヒントを決めるために、優先順位が比較されます。
このステージでは、選択したヒントを付け加えることで、問合せが再フォーマットされます。検索の最適化に役立つヒントで問合せを再フォーマットする方法の詳細と、再フォーマットされた問合せのいくつかの例は、「再フォーマットされた問合せによる検索の最適化」を参照してください。
コンテンツ・サーバー・インスタンス内の大部分の問合せは、対象となるコンテンツ・アイテム・セットが小さいか、返す行が最大でも100行です。コンテンツ・サーバー・ソフトウェアは、簡単に数百万のコンテンツ・アイテムに対応できます。ただし、1000万のコンテンツ・アイテムを含むコレクションを持つOracleデータベースでテストを行うと、Oracleで選択される実行計画が最も効率のよいものではないことがわかります。Oracleでは通常、多数の問合せを、一部取るに足りないものがあっても、解決するのに最良の最適化戦略が選択されません。次の例は、この問題を説明しています。
前述の環境では、Oracleにより次の問合せができるだけ効率的に解決されることはありません。
SELECT * FROM Revisions, Documents, DocMeta WHERE Revisions.dID = Documents.dID AND Revisions.dID = DocMeta.dID AND Revisions.dRevClassID = 333 Order By Revisions.dID
かなり選択性の高い索引が使用可能であるため(Revisions.dRevClassID用のdRevClassID_2)、この問合せはdRevClassID_2にアクセスし、dRevClassIDに一致する行に対してソートを実行する必要があります。ただし、この問合せの例では、OracleはRevisions.dID索引の使用を選択します。
この選択では、全索引スキャンを実行し、行ごとにdRevClassIDを取得しに表にアクセスするため、実際にはRevisions表で全表スキャンを実行するより効率が悪くなります。コンテンツ・アイテムが1000万を超えるコンテンツ・サーバー・リポジトリの場合、この実行計画を使用して問合せを解決しようとしてもうまくいかないのは明らかです。この場合、結果を返すのに約500秒かかります。
しかし、次のようなヒントを1つ追加して問合せを変更すると、パフォーマンスは劇的に向上します。
SELECT /*+ INDEX(Revisions dRevClassID_2)*/ * FROM Revisions, Documents, DocMeta WHERE Revisions.dID = Documents.dID AND Revisions.dID = DocMeta.dID AND Revisions.dRevClassID = 333 Order By Revisions.dID
問合せは、SELECT句に次のヒントを加えて変更されています。
/*+ INDEX(Revisions dRevClassID_2)*/
これにより、Oracleデータベースでは、Revisions.dID用の索引ではなく、dRevClassID_2索引が強制的に選択されます。この例では、dRevClassIDを共有するコンテンツ・アイテムがわずかなので、変更された問合せは即時に結果を返します。
標準的なコンテンツ・サーバー・インスタンスでは、大部分のドキュメントは、現在の日付より前のdInDateで、dReleaseStateのステータスが「Y」(リリース済)になっています。ただし、わずかながら、dReleaseStateのステータスが「N」(新規、また索引なし)のドキュメントがあります。次の問合せでは、まだリリースされていないコンテンツ・アイテムを検索します。
SELECT dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in
(N'DONE', N'RELEASED', N'DELETED')
AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
問合せの最適化された結果では、dReleaseStateの索引を使用します。
SELECT/*+ LEADING(Revisions) INDEX (Revisions dReleaseState)*/
dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in
(N'DONE', N'RELEASED', N'DELETED')
AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
コンテンツ・サーバー問合せは、様々なリソースで定義されている静的問合せ、動的WHERE句が追加されているデータ・ソース、および臨時のまたはアーカイバなどのアプリケーションで定義されている動的問合せのいずれかです。静的問合せは、Oracleデータベースのヒントによって更新される場合があります。ただし、臨時の問合せや動的WHERE句のヒントを事前に定義することは、ほとんど不可能です。
コンテンツ・サーバーのヒントでは、同じ問合せ内で複数のヒントをサポートする、データベースを選ばないヒント構文が使用されます。コンテンツ・サーバーのヒントは、どの問合せ、データ・ソースおよびWHERE句でも使用できます。ただし、Oracleデータベースのヒントとは結合できません。1つの問合せに両方のタイプのヒントが含まれている場合、Oracle Query Optimizerでは、Oracleデータベースのヒントが保持され、コンテンツ・サーバーのヒントは無視されます。
最適化処理の各ステージで、Oracle Query Optimizerでは、両方のタイプのヒントの異なった構文を認識し、それに応じて発行された問合せを処理します。最適化プロセスの詳細は、「問合せの最適化プロセス」を参照してください。
コンテンツ・サーバーのヒントの構文は、データベースを選ばず、同じ問合せの中で複数のコンテンツ・サーバーのヒントをサポートできます。最適化プロセス中に、コンテンツ・サーバーのヒントは、評価され、最適のヒントが再フォーマットされて、元の問合せに追加されます。
最適化のプロセスでは、1つ以上のコンテンツ・サーバーのヒントを含む問合せは解析されません。コンテンツ・サーバーのヒントのみが、索引選択時に検討されます。
コンテンツ・サーバーのヒントの構文:
問合せが最適化プロセスを経ると、次の構文を使用して、再フォーマットされた問合せにコンテンツ・サーバーのヒントが追加されます。
/*$tableName[aliasName]:columnName[:operator [:<value>]][, …]*/
ここで:
山カッコに囲まれた値(<value>)は必須です。
角カッコに囲まれた値([value])はオプションです。
省略符(…)は、前の表現の繰り返しを示します。
最適化プロセス前の問合せ:
SELECT * FROM Revisions, DocTypes, RoleDefinition WHERE /*$Revisions:dStatus*/(Revisions.dStatus<>'DELETED' AND Revisions.dStatus<>'EXPIRED' AND Revisions.dStatus<>'RELEASED') AND Revisions.dDocType = DocTypes.dDocType AND /*$Revisions:dReleaseState*/Revisions.dReleaseState<>'E' AND (Revisions.dSecurityGroup = RoleDefinition.dGroupName AND RoleDefinition.dRoleName = ? AND RoleDefinition.dPrivilege > 0
コンテンツ・サーバーのヒントを追加して再フォーマットされた問合せ:
問合せが最適化プロセスを経ると、両方の索引が使用され、ネイティブ索引に追加されます。
SELECT/*+ LEADING(revisions) INDEX (revisions dStatus dReleaseState)*/ * FROM Revisions, DocTypes, RoleDefinition WHERE (Revisions.dStatus<>'DELETED' AND Revisions.dStatus<>'EXPIRED' AND Revisions.dStatus<>'RELEASED') AND Revisions.dDocType = DocTypes.dDocType AND Revisions.dReleaseState<>'E' AND (Revisions.dSecurityGroup = RoleDefinition.dGroupName AND RoleDefinition.dRoleName = ? AND RoleDefinition.dPrivilege > 0)
検索問合せ句でOracleソート構造体を使用すると、問合せを実行する際のユーザーの自由度が向上します。ソート構造体は、複数の表で抽出、ソートおよび結合される行データを指定します。基本的に、ソート構造体は、返される行数を制限する目的に役立ちます。Oracle Query Optimizerでは、次のソート構造体が認識されます。
Group by: 一連のレコードをソートし、結果のグループ化の方法を指定します。
Order by: 一連のレコードをソートし、結果を昇順または降順のいずれで返すかを指定します。
Inner join: 一致するものを探して返すことにより、一連のレコードをソートします。
Outer join: 一致しないものを探して返すことにより、一連のレコードをソートします。
ヒント・ルール表には、最適化機能で、最適化プロセス中に動的問合せやデータ・ソースに追加する適切なヒントを決めるために使用されるルールが含まれています。「ヒント・ルール・フォームの編集」を使用すれば、特定のフィールドや演算子に対して、ヒント・ルールを定義できます。ヒント・ルールは、値や日付/数の範囲に基づいて定義することもできます。ヒント・ルール表は、他のコンポーネントによって拡張可能で、コンテンツ・サーバー・インスタンスの実行中に更新できます。
Oracle Query Optimizerに含まれているデフォルトのヒント・ルールの一部については、この後説明します。表の列の詳細は、「ヒント・ルール表」を参照してください。ヒント・ルール表の内容は、「管理」トレイからアクセスする「ヒント・ルールの構成」ページを見ればわかります。
ヒント・ルール表は、毎晩、およびルールが追加または変更されるたびに、再ロードするようにスケジュールされています。ヒント値は、再ロードのたびに再計算されます。
重要
ヒント・ルール表には、複数の索引を相互に使用できる列がありますが、Oracleではbitmap索引のみが結合可能です。これは、ヒント・ルール表が核となるコンテンツ・サーバー機能用に設計されているためです。
したがって、追加の表を作成したり、追加のメタデータ・フィールドを追加したり、あるいはその両方を行うコンポーネントを持つシステムには、不十分かもしれません。しかし、ヒント・ルール表は、追加の表、索引およびフィールドの知識を提供するために、他のコンポーネントによって拡張や上書きができます。
第1のヒント・ルールの説明:
このルールでは、WHERE句に次の条件が含まれている場合、PK_Revisions索引が使用され、最適化された問合せにヒントとして追加されます。
Revisions.dID = some_value
第2のヒント・ルールの説明:
このルールでは、WHERE句に次のいずれかの条件が含まれている場合、dDocName索引が使用され、最適化された問合せにヒントとして追加されます。
Revisions.dDocName = some_value Revisions.dDocName LIKE 'some_value'
第3のヒント・ルールの説明:
このルールでは、WHERE句に次の条件が含まれている場合、この条件は要件を満たさないため、修飾できません。
dStatus = 'DONE'
ただし、WHERE句に次の条件が含まれている場合、dStatus索引が使用され、最適化された問合せにヒントとして追加されます。
dStatus = 'RELEASED'
次の各項では、次に示すヒント・ルール表の列について説明します。
この列には、ルールを識別する一意の名前が含まれています。コンポーネントは、一意のキーを使用して、特定のルールを上書きできます。同じデータベース・スキーマ内では索引名は一意であるため、このキーは通常その索引名と同一です。
デフォルトでは、OracleはB+ Tree(バイナリ・ツリー)を索引構造として使用し、論理レコードへのアクセスを効率化します。B+ Tree索引は、結果の行数が少ない問合せや、ユーザーが変化する基準(等価条件および範囲条件など)を使用して問合せを実行する必要のある場合に、最も便利です。B+ Tree索引には索引の付いたデータ値が格納されるため、リクエストされた値が格納されている値である場合、データの便利なソースとなります。
しかし、ビットマップ索引は、デフォルトのB+ Tree索引と比べて、最小限のストレージ・コストで、大幅にパフォーマンスを向上させます。ビットマップ索引は、異なる値がほとんどないために選択性の低い列の検索に特に効果的です。また、ビットマップは、NULL値を含め(つまりNULLに索引が付けられる)、値ごとに作成されます。全般的に、索引参照プロセスはビットレベルの操作であり、複数の索引へのアクセスが可能であるため、ビットマップ索引の使用は非常に効率的です。
注意:
ヒント・ルールは上書きできるため、Oracle Query Optimizerでは、既存のキーを使用してヒント・ルールを追加することはできません。したがって、一意のキーを割り当てる列にビットマップ索引を作成している場合、これは重要です。
次のリストに示した表の列にはビットマップ索引を使用し、索引名は対応する列名に設定することをお薦めします。
Revisions表:
dIndexerState
dReleaseState
dProcessingState
dIsCheckedOut
dSecurityGroup
dStatus
WorkflowDocuments表:
dWfDocState
この列は、許容演算子のカンマ区切りリストです。有効な演算子オプションの詳細は、「演算子」フィールドおよび「ヒント・ルールの構成」ページのメニューを参照してください。ヒント・ルールの演算子は、ヒント・ルールを条件に適用するかどうかを決定する際に重要です。
たとえば、WHERE句に次の条件が含まれている場合、PK_Revisions索引を使用すると、最適化された問合せに含める非常に貴重なヒントになります。
Revisions.dID = 3
ただし、WHERE句に次の条件が含まれている場合、PK_Revisions索引を使用しても役に立ちません。
Revisions.dID > 3
この列には、ヒント・ルール表にルールが記載されている場合に使用される優先順位が含まれています。問合せで最上位のルールは、どのヒントを使用するかを決める際に優先されます。
順序には次の値があります。
5: この値は、指定した索引が一意か、どの値に対しても一致する行が50行以下であることを示します。たとえば、Revisions、DocumentsまたはDocMeta表でdIDを指定します。
4: この値は、指定した索引がやや少なく選択する必要があることを示します。指定した値は、通常では数行、多い場合でも数百行に一致する必要があります。たとえば、Revisions表でdDocTitleを指定します。
3: この値は、指定した索引が1000行未満と一致することを示します。たとえば、dInDateまたはdOutDateを指定します。
2: この値は、指定した索引が1万行未満と一致することを示します。
1: この値は、指定した索引が1万を超える行と一致することを示します。
この列は、Idocスクリプト作成可能です。この列は、「演算子」列値が次のいずれかであるときにしか定義できません。
inまたはnotIn: これらの演算子のいずれかを使用する場合、値をカッコで囲まれたカンマ区切りのリストにします。
range: この演算子を使用する場合、値は次のいずれかのフォーマットを使用する必要があります。
書式1:
([<lowValue>],range[,<highDateValue>])
指定可能な値の例は、次のとおりです。
('Y', 'O')
(,7d)
({ts '2004-12-11 12:03:23.000'}, 2d, <$dateCurrent()$>)
書式2:
#[d|h]
たとえば、5日の範囲は5d、7時間は7hです。
注意:
演算子inまたはnotInは、それぞれ、対応する値とともに、演算子equalおよびnotEqualのかわりに使用できます。演算子オプションの詳細は、「演算子」フィールドおよび「ヒント・ルール・フォームの編集」のメニューを参照してください。
次の使用例は、この列がどのようにヒント・ルールにさらなる柔軟性をもたらすかを示しています。
使用例1: 表の「状態」または「ステータス」列
dReleaseStateまたはdStatusなどの状態またはステータスを示す表の列は、完成した状態に関して偏りがあります。たとえば、dReleaseStateは、「Y」(リリース済)または「O」(旧バージョン)になる傾向があります。同様に、dStatusはRELEASEDになる傾向があります。したがって、WHERE句では、dReleaseState = YまたはdStatus = RELEASEDなどの条件は、Revisions表の大部分の行と一致します。このように、これら2列はほとんど役に立ちません。逆に、条件dReleaseState = N(新規、索引なし)は、わずかの行にしか一致しません。したがって、この列の索引は非常に役に立ちます。
使用例2: 表の「日付」または「数」列
日付または数を示す表の列は、状態またはステータスと同様の動作を示します。たとえば、条件dInDate < <$dateCurrent()$>は、大部分の表の行と一致し、このフィールドの索引は無意味になります。ただし、結合した条件dInDate < <$dateCurrent()$> AND dInDate > <$dateCurrent(-1)$>は通常、少量の行とのみ一致し、対応する索引をヒントとして使用するのが有益です。
この列は、ヒント・ルールが無効になっているかどうかを示します。表内のどのルールも、有効か無効のいずれかです。ヒント・ルールを無効にすると、「Y」の値が表示されます。既存のルールを無効にして、コンテンツ・サーバーの現在の状態に合せることができます。
たとえば、コンテンツ・サーバー・インスタンスに、異なるrevClassがわずかしかなくても、各revClassに数千のリビジョンがある場合があります。その結果、dRevClass_2索引は、あまり効果的ではありません。この場合、これに対応するヒント・ルールは無効にして、異なる優先順位を持つ1つ以上の新しいルールを追加する必要があります。
注意:
表内のすべてのルールは有効化または無効化できますが、削除できるのは「ヒント・ルール・フォームの編集」を使用して追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。
「ヒント・ルール・フォームの編集」を使用すると、「ヒント・ルールの構成」ページでルールの追加、削除、有効化または無効化ができます。新しいルールを追加して、新しい表と索引を反映できます。既存のルールを削除または無効化して、コンテンツ・サーバー・インスタンスの現在の状態に合せることができます。ヒント・ルール表からヒント・ルールを選択した場合は、該当する値が「ヒント・ルール・フォームの編集」の各フィールドに自動的に移入されます。
「ヒント・ルール・フォームの編集」は、「ヒント・ルールの構成」ページのヒント・ルール構成表の隣に表示されます。
ヒント・ルール構成表は、毎晩、および新しいルールが追加されるか既存のルールが変更されるたびに、再ロードするようにスケジュールされています。ヒント値は、再ロードのたびに再計算されます。
表内のすべてのルールは有効または無効にできますが、削除できるのは「ヒント・ルール・フォームの編集」を通じて追加されたルールのみです。OracleQueryOptimizerコンポーネントに含まれるデフォルトのヒント・ルールは無効化のみ可能です。これらのルールは削除できません。
Oracle Query Optimizerには、動的に生成されるヒントを格納するためのヒント・キャッシュも含まれます。たとえば、解析された問合せまたはデータ・ソースから導出されたヒントは、持続性を維持するためにキャッシュされます。このようにして、ヒント・キャッシュは、問合せやデータ・ソースを安定したものにします。
ヒント・キャッシュは、最適化プロセスで、Oracleまたはコンテンツ・サーバーのヒントが含まれていない問合せにヒントを選択するために使用されます。ヒント・キャッシュは、問合せヒントを微調整するメカニズムを提供します。さらに、管理者は実行時に、キャッシュのチェックまたは編集、および問合せのヒントの変更ができます。
ヒント・キャッシュは、2時間ごとにディスクに格納され、コンテンツ・サーバー・インスタンスの起動時に再ロードされます。
ヒント・キャッシュには次の特性があります。
同じ問合せは、新しい値がヒント・ルールの条件を満たさない場合を除いて、その値に関係なく、同じキャッシュ・エントリに一致します。次の2つの例では、同じヒント・キャッシュ・エントリが、複数の問合せにどのように使用できるか、できないかを説明しています。
例1: 類似のヒント・キャッシュ・エントリの使用
次の2つの問合せでは、両方の問合せがヒント・ルールの要件に一致するため、同じヒント・キャッシュ・エントリが使用されています。
問合せA:
SELECT *
FROM Revisions
WHERE dDocName = 'name1'
問合せB:
SELECT *
FROM Revisions
WHERE dDocName = 'name2'
例2: 異なるヒント・キャッシュ・エントリの使用
次の2つの問合せでは、問合せBがdReleaseStateヒント・ルールの要件に違反しているため、同じヒント・キャッシュ・エントリを使用できません。dReleaseStateヒント・ルールでは、dReleaseStateの値がY(リリース済)でもO(旧リビジョン)でもないことが必要です。
問合せA:
SELECT * FROM Revisions WHERE dReleaseState = 'U' AND dStatus = 'DONE'
問合せB:
SELECT * FROM Revisions WHERE dReleaseState = 'Y' AND dStatus = 'DONE'
ヒント・キャッシュでは、「ヒント・キャッシュ更新機能」ページを使用して、新規エントリの追加、既存エントリの編集または削除を行えます。ヒント・キャッシュ・エントリの追加または編集の際には、コンテンツ・サーバーのヒント構文を使用する必要があります。ヒント・キャッシュの管理機能は、問合せヒントの微調整に非常に役立ちます。次の例は、ヒント・キャッシュ・エントリの微調整の利点を示しています。
例: 索引のないコンテンツのバッチロード
100KBのコンテンツ・アイテムをコンテンツ・サーバーにバッチロードしたばかりで、まだ索引を付けていない場合、先ほど(「例2: 異なるヒント・キャッシュ・エントリの使用」)使用した索引ベースの問合せは、バッチロードされたすべてのドキュメントに一致します。
問合せA:
バッチロードされたドキュメントの大部分にまだ索引が付いていない場合、この問合せで使用されるdReleaseState索引は最良の選択ではありません。この場合で最良の結果を得るには、ヒント・キャッシュ・エントリでdReleaseState索引とdStatus索引の両方を使用するように微調整する必要があります。ヒント・キャッシュ・エントリを更新するには、「ヒント・キャッシュ更新機能」ページを使用してください。
SELECT dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in (N'DONE', N'RELEASED', N'DELETED') AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
問合せB:
ヒント・キャッシュ・エントリの更新後、新たに最適化された問合せは、次のとおりです。
SELECT/*+ LEADING(revisions) INDEX (revisions dReleaseState dStatus)*/ dID
FROM Revisions
WHERE Revisions.dReleaseState = N'N' AND Revisions.dStatus in (N'DONE', N'RELEASED', N'DELETED') AND Revisions.dInDate<={ts '2005-02-23 17:46:38.321'}
デフォルトでは、ヒント・キャッシュの最大容量は1000ヒントです。ヒント・キャッシュでは、OracleおよびMySQLで使用されるのと同様の中央挿入最小使用頻度(LRU)アルゴリズムが使用されます。新規エントリはキューの中央に挿入され、副問合せを実行するごとに、エントリは1つ上に上昇します。
キャッシュ内のヒント数が最大容量を超えると、キューの一番下のエントリがキャッシュから削除されます。こうして、LRUアルゴリズムにより、最後に実行された問合せヒントは必ずキューの上位に残るようになります。
ヒント・キャッシュ・キーは、正規化された問合せから生成されます。「ステージ3: 正規化」を参照してください。キャッシュ・キーは、修飾済の列(表またはエイリアス名で修飾された列)と、ヒント・ルールが定義された列から成ります。キャッシュ・キーにより、結合または副問合せを含む条件は除外されます。
次の例では、キャッシュ・キーがどのように指定の問合せから生成されるかを示しています。
SELECT DocMeta.*, Documents.*, Revisions.* FROM DocMeta, Documents, Revisions WHERE DocMeta.dID = Revisions.dID AND Revisions.dID=Documents.dID AND Revisions.dDocName='abc' AND Revisions.dStatus<>'DELETED' AND (Revisions.dReleaseState='U' OR Revisions.dReleaseState='I' OR Revisions.dReleaseState='Y') AND Documents.dIsPrimary<>0
生成されたキャッシュ・キーは次のようになります。
documents.disprimary:notequal:documents|revisions.ddocname:equal:revisions|revisions.dreleasestate:in:revisions|revisions.dstatus:notequal:revisions
ヒント・ルールを使用するには、次の作業が必要です。
「ヒント・ルール・フォームの編集」にアクセスするには、「管理」→「Oracle Query Optimizer」→「ヒント・ルールの構成」を選択します。「ヒント・ルール・フォームの編集」が含まれる「ヒント・ルールの構成」ページが表示されます。
ヒント・ルール表に新規ルールを追加するには、次のようにします。
「ヒント・ルール表」の既存のヒント・ルールを編集するには、次のようにします。
表内のすべてのルールは有効化および無効化できますが、削除できるのは「ヒント・ルールの構成」ページを通じて追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。
「ヒント・ルール表」のヒント・ルールを無効にするには、次のようにします。
Y」が表示されます。表内のすべてのルールは有効化および無効化できますが、削除できるのは「ヒント・ルールの構成」ページを通じて追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。
「ヒント・ルール表」で無効のヒント・ルールを有効にするには、次のようにします。
表内のすべてのルールは有効化および無効化できますが、削除できるのは「ヒント・ルールの構成」ページを通じて追加されたルールのみです。Oracle問合せ最適化機能に含まれるデフォルトのヒント・ルールは無効化のみ可能で、削除はできません。
「ヒント・ルール表」からヒント・ルールを削除するには、次のようにします。
「問合せコンバータ」を使用して、変換済の問合せの結果を表示したり、WHERE句に条件を追加したりWHERE句の条件を編集または削除することにより、変換済の問合せを変更できます。変換済の問合せを変更すると、問合せが発行されたときに実際にどのような処理が実行されるかがわかります。必要に応じて、変換済の問合せにデータ・ソースを含めることもできます。
問合せコンバータを使用する際には、次の作業が必要です。
「問合せコンバータ」ページにアクセスするには:
データ・ソース問合せを変換するには、次の手順を実行します。
問合せを変換するには、次のようにします。
データ・ソースまたは問合せが変換されると、「データ・ソースの使用」チェック・ボックスの上に結果が表示されます。変換プロセスによりフィールドがクリアされるため、変換済問合せはフィールドに新しい情報を入力しないと変更できません。データ・ソースまたは問合せの情報を編集するには、「データ・ソースの変換」の該当する項を参照してください。
ヒント・キャッシュを更新する際には、次の作業が必要です。
「ヒント・キャッシュ更新機能」ページにアクセスするには:
データ・ソースを使用してヒント・キャッシュをチェックするには、次のようにします。
データ・ソースを使用してヒント・キャッシュ問合せを変更するには、次のようにします。
問合せを使用してヒント・キャッシュを変更するには、次のようにします。
ヒント・キャッシュ・データ・ソース・エントリを削除するには、次のようにします。
この項には、検索パフォーマンスの向上に関する情報が含まれます。
「タイトル」フィールドの検索を頻繁に行い、サイトに100万件を超えるレコードがあり、データベース検索を使用する場合、dDocTitleおよびdReleaseStateに基づいて索引を作成することをお薦めします。
各問合せが検索結果セットの各エントリ部分に対するフォルダ・パスを特定しているために、トリガーされている不要なSQL問合せがあることが見つかり、フォルダ・パス情報が必要ではない場合、config.cfgファイルの「追加の構成変数」部分のFolderPathInSearchResults構成変数をオフにすることにより、パフォーマンスを向上させることができます。詳細は、ブログ記事「WebCenter Content Web Search Performance: Do you really need that folder path info?」を参照してください。
