| Oracle Ultra Search管理者ガイド 11gリリース1（11.1） E05790-02 |
|
 戻る |
 次へ |
この章では、次の項目について説明します。
Oracle Ultra Searchクローラは、組織のイントラネット内のWebサイトに関する情報を検出する強力なツールです。この機能は、特にWebクロールに適しています。その他のデータ・ソース（表または電子メール・データ・ソースなど）については、ユーザーが認識していない可能性のある他のドキュメントへのリンクを、クローラでたどらないように定義されています。
Webクロールの方針は、組織内の他のイントラネット・サイトへのリンクを含む主要なサイトのみを認識するだけという簡単な方針にできます。この方針は、これらのサイトを索引付けせずにクロールするとテストできます。初回のクロール後、イントラネットにあるホストについて、どう対処すればよいか見当がつきます。これによって、各Webソースを定義でき、各サイトのクロールおよび索引付けが簡単になります。
ただし、イントラネットの検出とクロール・プロセスはインタラクティブで、クロール結果の定期的な分析と、クロール・プロセスを指示するクロール・パラメータの変更を特徴としています。たとえば、クローラがあるWebホストのクロールにより多くの時間を費やしている場合、そのホストのクロールを除外するかクロールの深さを制限できます。
次の方法を組み合せて、クロール・プロセスを監視します。
管理ツールを使用して、スケジュール・ステータスを監視します。
管理ツールを使用して、スケジュールの進行状況をリアルタイムに監視します。
管理ツールを使用して、クローラ統計を監視します。
現行スケジュールのログ・ファイルを監視します。
URLルーピングとは、同一ドキュメントを指す一意のURLが、なんらかの理由により多数存在する場合のことです。1つのサイトに大量のページがあり、それぞれが同一サイト内にある他のページへリンクされていたとしても、クローラは、最終的にはそのサイト内のすべてのドキュメントを分析するため、このような状況が問題になることはありません。
ただし、Webサーバーには、生成されたURLにパラメータを付加することで、リクエストされた情報を追跡するものもあります。このようなWebサーバーは、同一ドキュメントを指す一意のURLを多数生成することがあります。
たとえば、http://mycompany.com/somedocument.html?p_origin_page=10は、http://mycompany.com/somedocument.html?p_origin_page=13と同じドキュメントを参照する場合がありますが、参照するページが異なるため、p_origin_pageパラメータはリンクごとに異なります。多数のパラメータが指定されており、参照するリンクも多数ある場合、1つの一意のドキュメントに対して参照元のリンクが無数になります。このような場合に、URLルーピングが発生する可能性があります。
Oracle Ultra Search管理ツールでクローラ統計を監視し、最も多くクロールされているURLおよびWebサーバーを確認します。特定のサイトやURLに、膨大な数のURLアクセスがあることを発見した場合は、次のいずれかを実行してください。
Webサーバーの除外: 該当するホストでのクローラによるURLのクロールを停止します（ホストの固有ポートを除外するようには制限できません）。
クロールの深さの制限: クローラがたどる参照リンクのレベル数を制限します。特定のホストでURLルーピングが影響していることを発見した場合は、画面から調査を行い、そのサイトのリーフ・ページの深さを見積ります。リーフ・ページとは、他のページへのリンクがないページのことです。一般的なガイドラインとしては、リーフ・ページの深さに3を加えた値をクロールの深さに設定します。
「「クローラ」タブでパラメータを変更した後は、必ずクローラを再起動してください。設定の変更は、クローラを再起動するまで反映されません。
この項では、Oracle Ultra Searchの問合せパフォーマンスを改善する方法をいくつか説明します。問合せのパフォーマンスは通常、レスポンス時間とスループットの影響を受けます。
DB_CACHE_SIZE初期化パラメータのチューニング
データベースのバッファ・キャッシュには、データ・ファイルから頻繁にアクセスするデータが保存されています。このバッファ・キャッシュを効率よく使用することによって、Oracle Ultra Searchの問合せパフォーマンスを改善できます。キャッシュ・サイズは、DB_CACHE_SIZE初期化パラメータによって制御されます。
|
関連項目: このパラメータのチューニング方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
索引の最適化
クローラによる大規模な更新の後は、Oracle Ultra Searchの索引を最適化してください。そのためには、索引の最適化を定期的にスケジューリングします。索引の最適化中は、問合せパフォーマンスが大幅に低下するため、最適化はピーク時以外にスケジュールしてください。
トークンに基づく索引の最適化
Oracle Ultra Searchの索引は、頻繁に検索されるトークンに基づいて最適化してください。問合せをログに記録するには、管理ツールを使用して問合せ統計の収集をオンにします。頻繁に検索されるトークンをトークン・モードでCTX_DDL.OPTIMIZE_INDEXに渡すことができます。Oracle Ultra Searchの索引名はWK$DOC_PATH_IDXです。
|
関連項目: OPTIMIZE_INDEXの詳細は、『Oracle Textリファレンス』を参照してください。 |
問合せ拡張の簡素化
検索のレスポンス時間は、使用されたOracle Text問合せ文字列によって直接影響を受けます。Oracle Ultra Searchには、ユーザー入力をOracle Textの問合せに拡張するデフォルトの機能がありますが、拡張が簡単であれば検索時間を大幅に削減できます。
|
関連項目:
|
共有プールのサイズ指定
共有プールには、ライブラリ・キャッシュとディクショナリ・キャッシュが格納されています。ライブラリ・キャッシュには、最近実行されたSQLとPL/SQLコードが格納されています。データ・ディクショナリ・キャッシュやライブラリ・キャッシュでのキャッシュ・ミスは、バッファ・キャッシュでのミスに比較してはるかにコストがかかります。このため、共有プールには、頻繁に使用されるデータが確実にキャッシュされるように、サイズを指定する必要があります。共有プールのサイズは、SHARED_POOL_SIZE初期化パラメータによって制御されます。
|
関連項目: このパラメータのチューニングについては、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
Oracle Ultra Search中間層は、JDBCを介してデータベースに接続しています。JDBCでの接続の作成には時間がかかるため、問合せのレスポンス時間を削減するためにオープン接続のプールが使用されます。Oracle Application Serverでは、OC4Jによってアプリケーション用の接続プールを管理できます。
最小サイズ、最大サイズおよびプールの割当アルゴリズムは、OC4Jのdata-sources.xml構成ファイルで指定できます。
次に、最小2、最大30のオープン接続数を持つデータ・ソース定義の例を示します。各接続は30秒の非アクティブ後にクローズし、新規の接続が負荷に従って動的に作成されます。その他のキャッシュ・スキームには、FIXED_WAIT_SCHEMEおよびFIXED_RETURN_NULL_SCHEMEがあります。
|
注意: DYNAMIC_SCHEME = 1、FIXED_WAIT_SCHEME = 2、およびFIXED_RETURN_NULL_SCHEME = 3 |
<data-source
class="oracle.jdbc.pool.OracleConnectionCacheImpl"
name="UltraSearchDS"
location="jdbc/UltraSearchPooledDS"
username="user"
password="pass"
url="jdbc:oracle:thin:@host:1521:oracle_sid"
min-connections="2"
max-connections="30"
inactivity-timeout="30" >
<property name="cacheScheme" value="1" />
</data-source>
問合せパッケージのメモリー内への確保
頻繁に使用するパッケージは、共有メモリー・プール内に確保してください。確保されたパッケージは、プールの使用状況やアクセス頻度に関係なく、メモリー内に残ります。パッケージの確保には、提供されているパッケージのDBMS_SHARED_POOLを使用できます。
|
関連項目: 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』 |
Oracle Ultra Searchのリモート・クローラがない場合は、Oracle Databaseと同じホストでOracle Ultra Searchクローラを実行する必要があります。大規模なデータ・セットの場合は、Oracle Databaseとは別の1つ以上のホストでOracle Ultra Searchクローラを実行すると、パフォーマンスが向上します。Oracle Ultra SearchクローラはPure Javaアプリケーションで、JDBCを介してOracle Databaseと通信します。Oracle Ultra Searchのスケジューリング・メカニズムはOracle Database内で動作するため、データベースの高可用性が自動的に反映されます。Oracle Databaseは、リモート・クローラ・ホストへの起動リクエストの送信に、2つのメカニズムのいずれかを使用します。1つは、Java Remote Method Invocation（RMI）です。もう1つは、Java Database Connectivity（JDBC）です。どちらのメカニズムも、リモート・ホスト上で起動サブシステムを確立します。起動サブシステムは、概念的にはRMIまたはJDBCのいずれかを使用して起動リクエストをリスニングするプロセスとして考えることができます。（この章では起動サブシステムをランチャと呼びます）。
起動リクエストを受け取ると、ランチャは新しいJavaプロセスを起動します。このプロセスが、実際のリモート・クローラです。
ネットワークの制限などの理由でRMIを使用しない場合は、JDBCベースのリモート・クロールを使用します。
ランチャは、起動リクエストをリスニングし、リモート・クローラ・プロセスを起動するサブシステムです。リモート・クローラ（RMIベースまたはJDBCベース）を登録すると、実際にはOracle Ultra Searchバックエンドにランチャが登録されます。ランチャを登録すると、Oracle Ultra Search環境内のすべてのOracle Ultra Searchインスタンスで使用できるようになります。したがって、登録後、管理者またはOracle Ultra Searchインスタンスはランチャを関連付け、そのランチャで起動されるようにスケジュールを指定できます。ランチャを特定のOracle Ultra Searchインスタンスに制限する方法はありません。一度登録すると、すべてのOracle Ultra Searchインスタンスが使用できます。ただし、ランチャはリモート・クローラ・プロセスを起動するためのサブシステムにすぎません。起動するために複数のインスタンスが同じランチャを使用しても、通常、セキュリティの問題は発生しません。RMIランチャもJDBCランチャも単なるJavaプロセスです。これらのランチャは、コマンドラインから起動します。Oracleでは、これらのランチャを起動するためのスクリプトが提供されています。スクリプトについては、次の項で説明します。また、JDBCランチャは起動イベントをリスニングするために、Oracle Ultra Searchのバックエンド・データベースへのJDBC接続を確立する必要があります。登録するときは、起動ユーザー（またはロール）を指定します。新しいデータベース・ユーザー（またはロール）を作成して、リモート・クローラの起動専用にすることを強くお薦めします。このユーザー（またはロール）をその他の目的で使用しないでください。
RMIベースのリモート・クロールは、標準のRMIインフラストラクチャに依存しています。そのため、各リモート・クローラ・ホストでは、RMIレジストリおよびRMIデーモンを実行する必要があります。RMIベースのランチャを起動するスクリプトを実行すると、これらが起動されます。
クロール・スケジュールがアクティブになると、Oracle Ultra Searchスケジューラは、データベース・ホスト上の個別のプロセスとしてJavaプログラムを起動します。このJavaプログラムは、ActivationClientと呼ばれます。
このプログラムは、インストール時に指定されたRMIレジストリ・ポートを使用してリモート・クローラ・ホストへの接続を試みます。接続に成功すると、ActivationClientはリモート・ホストで実行中のJavaオブジェクトへのリモート参照を受け取ります。このリモートJavaオブジェクトは、ActivatableCrawlerLauncherと呼ばれます。
ActivationClientは、ActivatableCrawlerLauncherを使用してリモート・ホスト上のOracle Ultra Searchクローラを起動します。Oracle Ultra Searchクローラは、ActivatableCrawlerLauncherによってリモート・ホスト上の個別のJavaプロセスとして起動します。
RMIレジストリおよびデーモン・ポートには柔軟性がありません。このため、同じホストで他のRMIサービスを実行している場合は、RMIベースのリモート・クロールを使用できません。また、RMIポート上で両者が競合するので、RMIベースのランチャを2つ実行することはできません。
JDBCベースのリモート・クロールでは、ランチャが起動および実行中である必要があります。
クロール・スケジュールがアクティブのとき、Oracle Ultra Searchスケジューラは、メッセージをランチャに送信します。
ランチャが実行中で、適切なランチャ・ユーザー（またはロール）としてデータベースに正しく接続されている場合は、起動メッセージを受け取ることができます。そうでない場合は、30秒後にメッセージがタイム・アウトし、起動エラーがレポートされます。
ランチャは次に起動メッセージをディスパッチし、Oracle Ultra Searchクローラをリモート・ホスト上の個別のJavaプロセスとして起動します。
ランチャは、バックエンド・データベースへの2つの永続的なJDBC接続を保守します。いつでもいずれかの接続が停止すると、JDBCランチャは接続を再度確立しようとします。接続の再確立の試行回数は、コマンドライン・パラメータとして構成できます。次の試行までの待機時間も構成できます。
|
注意: JDBCランチャは、keep-aliveシグナルを定期的にトリガーするように構成できます。ファイアウォールが原因でJDBC接続が意図せずに終了するのを防ぐ際に役立ちます。次のシグナルまでの時間は、コマンドライン・パラメータで構成できます。 |
リモート・クローラを起動するとき、Oracle Ultra Searchのバックエンド・データベースは、Java Remote Method Invocation（RMI）またはJDBCを使用してリモート・コンピュータと通信します。
Oracle Ultra SearchはすべてのRMI通信を暗号化します。ただし、JDBCランチャはOracle Thin JDBCドライバを使用します。セキュリティが問題となる場合、Oracle Thin JDBCドライバを保護して、すべてのJDBCトラフィックを暗号化します。
|
関連項目: Thin JDBCのサポートの詳細は、『Oracle Advanced Security管理者ガイド』を参照してください。 |
Oracle Ultra Searchスケジュールは、それぞれ1つのクローラに関連付けられます。クローラは、Oracleデータベース・ホストまたはリモート・ホストでローカルに実行できます。実行できるスケジュールの数に制限はありません。同様に、実行できるリモート・クローラ・ホストの数に制限はありません。ただし、各リモート・クローラ・ホストに、Oracle Ultra Search中間層がインストールされている必要があります。
いくつかのリモート・クローラ・ホストを使用し、スケジュールを特定のホストに割り当てることによって、クロール・プロセス全体のスケーラビリティおよびロード・バランシングが実現します。
リモート・クローラを実行する各ホストに、Oracle Ultra Searchのバックエンド・サーバー・コンポーネントおよびサーバー・コンポーネントがインストールされていることを確認します。
キャッシュおよびメール・アーカイブ・ディレクトリについて理解します。
すべてのリモート・クローラは、クロールされたデータを共通のファイル・システムの位置（バックエンドのOracle Ultra Searchデータベースがアクセス可能な位置）にキャッシュする必要があります。同様に、電子メール・ソースをクロールするとき、すべての電子メールを共通の中央の位置に保存する必要があります。これを実現する最も簡単な方法は、リモート・クローラが参照するキャッシュおよびメール・アーカイブ・ディレクトリを、Oracle Ultra Searchバックエンド・データベースが使用するキャッシュおよびメール・ディレクトリを指すようにNFSでマウントすることです。
たとえば、Oracle Ultra Search環境が、Oracle Ultra Searchのバックエンドがインストールされ、Solaris上のデータベース・サーバー（ホストX）、Windows上のリモート・クローラ・ホスト（ホストY1）、Solaris上のリモート・クローラ・ホスト（ホストY2）、そしてLinux上のリモート・クローラ・ホスト（ホストY3）の4つのホストで構成されているとします。
この例では、UNIXのexportコマンドを使用して、ホストX上の共有ディレクトリをエクスポートします。次に、ホストY2およびY3上でUNIXのmountコマンドを使用して、エクスポートされたディレクトリをマウントします。ホストY1の場合は、Windows用のサード・パーティのNFSクライアントを購入し、そのクライアントを使用して共有ディレクトリをマウントする必要があります。ホストXがLinuxサーバーの場合は、Samba共有ディレクトリを作成してWindows上にマウントできるため、サード・パーティのソフトウェアは不要です。
なんらかの理由でデータベースとリモート・クローラ・ホストの間に共有ファイル・システムがない場合は、JDBCを使用してすべてのキャッシュおよびメール・アーカイブ・データをデータベース・ホストに転送するようにリモート・クローラに指示できます。このとき、ファイルはデータベース・ホストにローカルに保存できます。次の手順のキャッシュ・ファイル・アクセス・モードの設定でJDBC接続経由を選択すると、このオプションを選択できます。
Oracle Ultra Search管理ツールを使用して、リモート・クローラを構成します。
リモート・クローラ・プロファイルを編集するには、「クローラ」タブの「リモート・クローラ・プロファイル」サブタブに進み、編集するリモート・クローラ・プロファイルの「編集」をクリックします。定義した共有クローラ・リソース用のマウント・ポイントをすべて手動で入力して、リモート・クローラ・プロファイルを編集します。
キャッシュおよびメール・アーカイブ・ディレクトリ: バックエンド・データベース・ホストとリモート・クローラ・ホストが共有ファイル・システム（NFSなど）上にある場合は、キャッシュ・ファイル・アクセス・モードの設定で「マウントされているファイル・システム経由」を選択します。次のパラメータの値を指定します。
リモート・クローラによって参照されるキャッシュ・ディレクトリ・パス用のマウント・ポイント
リモート・クローラによって参照されるメール・アーカイブ・パス用のマウント・ポイント（Oracle Ultra Searchメーリング・リスト機能を使用している場合）
リモート・クローラ・ホストとバックエンド・データベース・ホストの間に共有ファイル・システムがない場合は、キャッシュ・ファイル・アクセス・モードの設定で「JDBC接続経由」を選択する必要があります。この場合、次のパラメータの値を指定します。
バックエンド・データベース・ホストのローカル・クローラによって参照されるローカル・キャッシュ・ディレクトリ
バックエンド・データベース・ホストのローカル・クローラによって参照されるローカル・メール・アーカイブ・ディレクトリ
クローラ・ログ・ディレクトリ: リモート・クローラ・ログ・ディレクトリは、バックエンドのOracle Ultra Searchデータベースからアクセスできる中央位置のNFSマウントである必要はありません。ただし、中央位置にあるすべてのクローラ・ログ（ローカルおよびリモートのクローラ）を監視する場合には効果的です。
さらに、クロールを始める前に、次のクローラ・パラメータを指定する必要があります。
リモート・クローラがドキュメント収集用に使用するクローラ・スレッドの数
リモート・クローラ・ホスト上のプロセッサの数
初期Javaヒープ・サイズ
最大Javaヒープ・サイズ
Javaクラスパス: 通常、このクラスパスは指定する必要がありません。リモート・クローラ・プロセスが使用するクラスパスは、RMIサブシステムから継承されます。RMIサブシステム・クラスパスは、それを起動するために使用されたスクリプトによって構成されます。JavaクラスパスがRMIサブシステムのクラスパスとは別であることが必要な特別な場合にのみ、このクラスパスを変更する必要があります。
Oracle Ultra Search管理ツールを使用して、クローラの構成を完了します。
スケジュールとデータ・ソースを作成します。各スケジュールに1つ以上のデータ・ソースを割り当てます。
各スケジュールは、リモート・クローラまたはローカル・クローラに割り当てる必要があります。（ローカル・クローラは、Oracleのローカル・データベース・ホスト上で実行されるクローラです。）スケジュールをリモート・クローラ・ホストまたはローカル・データベース・ホストに割り当てるには、「スケジュール」ページにあるスケジュールのホスト名をクリックします。
各スケジュールに対するリモート・クローラ機能を停止し、スケジュールを使用して特定のリモート・クローラ・ホストのかわりにローカル・データベース・ホスト上のクローラを起動することもできます。リモート・クローラ機能を停止するには、「同期スケジュール」ページのスケジュールのホスト名をクリックします。リモート・クローラ・ホストを選択すると、RMIベースのリモート・クローラ・ホスト名（またはJDBCベースのランチャ名）が表示されます。これをローカル・データベース・ホストに変更し、リモート・クロールを使用不可にします。
各リモート・クローラ・ホストで、サブシステムを起動するリモート・クローラを起動します。
起動するには、$ORACLE_HOME/tools/remotecrawler/scripts/operating_systemのヘルパー・スクリプトを使用します。
リモート・クローラがUNIXプラットフォーム上で実行されているとき、RMIベースのリモート・クロールの場合は、sourceコマンドを使用してBourneシェル・スクリプト$ORACLE_HOME/tools/remotecrawler/scripts/unix/runall.shを実行します。JDBCベースのリモート・クロールの場合は、runall_jdbc.shを実行します。
リモート・クローラがWindowsホスト上で実行されているとき、RMIベースのリモート・クロールの場合は、%ORACLE_HOME%\tools\remotecrawler\scripts\winnt\runall.batを実行します。JDBCベースのリモート・クロールの場合は、runall_jdbc.batを実行します。
RMIベースのリモート・クロールの場合、runallスクリプトは次の処理を順に実行します。
define_envが起動され、必要な環境変数が定義されます。
runregistryが起動され、RMIレジストリが起動されます。
runrmidが起動され、RMIデーモンが起動されます。
register_stubが起動され、必要なJavaクラスがRMIサブシステムに登録されます。
|
注意: runregistry、runrmidおよびregister_stubは、個別に起動できます。ただし、最初にdefine_envを起動して必要な環境変数を定義する必要があります。 |
JDBCベースのリモート・クロールの場合、runall_jdbcスクリプトは次の処理を順に実行します。
define_envが起動され、必要な環境変数が定義されます。
Javaプロセスを呼び出すコマンドラインで、JDBCランチャを開始します。JDBCランチャ用に次のコマンドライン引数があります。
-name: ランチャ名（このランチャの登録に使用した名前）
-url: バックエンドOracle Ultra SearchデータベースへのJDBC接続URL
-user: 接続するデータベース・ユーザー
-password: データベース・ユーザー・パスワード
-rw: JDBC接続の再確立試行間の待機時間(秒単位)
-ra: JDBC接続の再確立を試みる最大回数
-kw: キープ・アライブ・シグナル間の待機時間(ミリ秒単位)
スクリプトを実行する前に、runall_jdbcスクリプトのコンテンツを編集し、各パラメータの値を指定する必要があります。
管理ツールからリモート・クローラを起動し、実行されていることを確認します。
スケジュールのステータスは、「スケジュール」タブにリストされます。リモート・クローラの起動プロセスで障害が発生した場合は、ステータスがLAUNCHINGからFAILEDに変更されるまで最大90秒かかります。
スケジュールのステータスを表示するには、スケジュール・リストのクローラのステータスをクリックします。障害が発生したイベントの詳細を表示するには、スケジュールのステータスをクリックします。詳細なスケジュールのステータスが表示されます。
要件のいずれかが満たされていない場合、RMIベースのリモート・クローラは起動できません。次に例を示します。
RMIレジストリが、インストール時に指定したポートで実行またはリスニングされていない場合
RMIデーモンが、インストール時に指定したポートで実行またはリスニングされていない場合
必要なJavaオブジェクトが、各RMIレジストリに正常に登録されていない場合
要件のいずれかが満たされていない場合、JDBCベースのリモート・クローラは起動できません。次に例を示します。
JDBCランチャが起動されていない場合
JDBCランチャは起動されているが、指定された接続ユーザー（ロール）が正しくない場合
リモート・クローラの起動後は、次のいずれかの方法で、リモート・クローラが実行されていることを確認してください。
RMIベースのクロールの場合は、リモート・クローラ・ホスト上のアクティブなJavaプロセスを確認します。リモート・クローラがリモート・クローラ・ホスト上で実行されていることを確認する簡単な方法は、UNIXシステム上でpsなどのオペレーティング・システムのコマンドを使用することです。アクティブなJavaプロセスを検索します。
JDBCベースのクロールの場合は、ランチャが起動しエラーが発生していないことを確認します。JDBCベースのランチャを起動すると、出力テキストが標準出力になります。出力をファイルにリダイレクトすることもできます。この出力でエラーがないかを監視します。
スケジュール・ログ・ファイルの内容を監視します。リモート・クローラが正常に実行されている場合は、スケジュール・ログ・ファイルの変更内容を定期的に確認する必要があります。スケジュール・ログ・ファイルは共有ログ・ディレクトリ内にあります。
Oracle Ultra Searchは、Real Application Clustersシステムの記憶域アクセスの構成によって、固定ノードまたは任意のノードをクロールできます。必要に応じて、クローラを実行するノードを指定するためのPL/SQL APIが用意されています。Oracle Ultra Search AdministrationおよびOracle Ultra Searchの問合せアプリケーションの場合、Real Application Clustersの任意のノードに接続するように、接続文字列を構成できます。
|
関連項目: Oracle Database Real Application Clustersのマニュアル |
Real Application Clustersシステムの任意のノードのディスクは、共有（クラスタ・ファイル・システム）または非共有（RAWディスク）にできます。クラスタ・ファイル・システム（CFS）上のReal Application Clustersの場合、任意のノード上のクローラによって生成されたキャッシュ・ファイルは任意のOracleインスタンスに表示され、索引同期を実行するOracleインスタンスによって索引付けできます。ディスクを共有しない場合はクローラを特定のOracleインスタンスで実行し、すべてのキャッシュ・ファイルが索引付けされるようにする必要があります。
これは、Oracle Textの索引付けの性質によるものです。Oracle Textの索引付けでは、異なるセッションによって1つの表に挿入された行は同じペンディング・キューに入り、索引同期を開始したユーザーが、挿入されたすべての行を索引付けします。この制限によりCFSでは、Oracle Ultra Searchは任意のデータベース・インスタンスでクローラを起動するように構成されます。CFS以外の場合、Oracle Ultra Searchは、INSTANCE_NUMBER = 1のデータベース・インスタンスでクローラを起動します。
Oracle Ultra Search管理者は、次のPL/SQL APIを使用してクローラを実行するインスタンスを構成できます。
WK_ADM.SET_LAUNCH_INSTANCE(instance_name, connect_url);
instance_nameは起動インスタンスの名前（任意のノードで起動される場合はデータベース名）、connect_urlは接続記述子です。
単一のデータベース・インスタンスに接続する場合、記述子は略式のhost:port:SID、または接続記述子（Oracle Netのキーワード値ペア）にできます。次に例を示します。
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=cls02a)(PORT=3999)))(CONNECT_DATA=( SERVICE_NAME=acme.us.com)))
任意のデータベース・インスタンスに接続するには、完全なデータベース接続記述子を使用する必要があります。次に例を示します。
(DESCRIPTION=(LOAD_BALANCE=yes)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=cls02a)(PORT=3999 ))(ADDRESS=(PROTOCOL=TCP)(HOST=cls02b)(PORT=3999)))(CONNECT_DATA=(SERVICE_NAME=acme.us.com)))
|
関連項目: 構成の詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。 |
クラスタ・ファイル・システム以外のノードでクローラを起動するように、Oracle Ultra Searchを構成することはできません。
既存の起動インスタンス構成を問い合せるには、次のPL/SQL APIを使用します。
WK_ADM.GET_LAUNCH_INSTANCE RETURN VARCHAR2;
これにより起動インスタンスの名前、またはデータベース名（任意のノードがクローラを起動する場合）が戻されます。
Oracle Ultra Searchのリモート・クローラでは、索引付けのためにリモート・ファイル・システムをOracleインスタンスにマウントする必要があります。
クラスタ・ファイル・システムのReal Application Clustersの場合、リモート・コンピュータのファイル・システムは、システムの全ノードにNFSでマウントされる必要があります。
クラスタ・ファイル・システム以外のReal Application Clustersの場合、NFSマウントは、Oracleインスタンスがリモート・クローラを提供している特定のノードに制限されます。すべてのノードにリモート・ファイル・システムをマウントしても効果はありません。ノードが停止したときに、古いNFSハンドルになる可能性があります。別のOracleインスタンスに移動するように構成が変更された場合、リモート・ファイル・システムはそれに従って、新しいノードにNFSでマウントする必要があります。
Oracle Ultra Searchのすべてのコンポーネントは、JDBC Thinドライバ、およびhost_name:port:SIDで構成される接続文字列、またはtnsnames.oraで参照される完全な接続記述子を使用します。
管理中間層は、ultrasearch.propertiesファイルに指定されたJDBC接続を使用して、Oracleデータベースに接続します。クライアントが使用しているノードが停止した場合は、別のOracleインスタンスに接続するように、ultrasearch.propertiesファイルを手動で編集する必要があります。
問合せコンポーネントは、Real Application Clustersを十分に活用する必要があります。Real Application Clusters内の任意のOracleインスタンスに接続できるように、JDBC接続文字列をデータベース接続記述子として指定できます。次に例を示します。
"jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=yes)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=cls02a)(PORT=3999 ))(ADDRESS=(PROTOCOL=TCP)(HOST=cls02b)(PORT=3999)))(CONNECT_DATA=(SERVICE_NAME=acme.us.com)))"
|
関連項目: 『Oracle Database JDBC開発者ガイドおよびリファレンス』 |
Oracle Ultra Searchクローラで使用される接続文字列は、インストール時に初期化され、WK_ADM.SET_LAUNCH_INSTANCE APIを使用して変更できます。ノードの追加や削除など、システム構成が変更されると、接続文字列も自動的に変更されます。
Oracle Ultra Search管理者は、JDBC OCIドライバを使用してデータベースにログオンするように、ローカル・クローラをオプションで構成できます。これは、次のPL/SQL APIを使用して実行されます。
WK_ADM.SET_JDBC_DRIVER(driver_type)
設定は次のとおりです。
Thinドライバ（デフォルト）の場合、driver_type = 0
OCIドライバの場合、driver_type = 1
このAPIには、スーパーユーザー権限が必要です。変更はすべてのOracle Ultra Searchインスタンスに影響します。
|
注意: OCIドライバでは、LD_LIBRARY_PATHおよびNLS_LANGなどの環境変数を、起動データベース・インスタンスに正しく設定する必要があります。クローラは、Oracleプロセスから環境設定を継承します。したがって、Oracleを起動する前に環境変数を正しく構成する必要があります。 |
|
関連項目: OCIドライバを使用する構成の詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。 |
次のPL/SQL APIにより、現在使用されているJDBCドライバの種類を判別します。
WK_ADM.GET_JDBC_DRIVER RETURN NUMBER;
RACがクラスタ・ファイル・システム（CFS）を使用している場合、いずれかのRACノードが起動および実行中であれば、任意のRACノードからOracle Ultra Searchクローラを起動できます。
RACがCFSを使用していない場合は、Oracle Ultra Searchクローラは必ず指定されたノードで実行します。このノードが処理を中止する場合は、wk0reconfig.sqlスクリプトを実行して、Oracle Ultra Searchを別のRACノードに移動する必要があります。
sqlplus wksys/wksys_passwd ORACLE_HOME/ultrasearch/admin/wk0reconfig.sql instance_name connect_url
指定要素は次のとおりです。
instance_nameは、Oracle Ultra Searchがクロールに使用するRACインスタンスの名前です。データベースに接続した後に、
SELECT instance_name FROM v$instance
を使用して、現行インスタンスの名前を取得します。
connect_urlは、指定されたインスタンスに対してのみ接続を保証するJDBC接続文字列です。次に例を示します。
"(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)
(HOST=<nodename>)
(PORT=<listener_port>)))
(CONNECT_DATA=(SERVICE_NAME=<service_name>)))"
クローラ・キャッシュを保持しているとき、Oracle Ultra SearchがあるRACノードから別のノードに切り替えられると、キャッシュの内容が失われます。インスタンスの切替え後は、ドキュメントの再クロールを実行します。
Oracle Ultra Searchクローラは、Oracle Ultra SearchがインストールされているOracleのローカル・データベース・インスタンスにあるデータベース表をクロールします。また、リモート・データベースがOracleのメイン・データベースにリンクされている場合は、そのリモート・データベースをクロールすることもできます。リモート・データベースは、データベース・リンクを経由してOracleのメイン・インスタンスにリンクされます。
|
関連項目: データベース・リンクの作成方法については、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Ultra Searchには、表ソースのクロールを最適化するためのロギング機能があります。このロギング機能を使用すると、新たに更新されたドキュメントのみがクロール・プロセスで再検査されます。ソース・データベースがOracleデータベースではない場合、この機能を使用するには、一連の処理を行う必要があります。
ログ表とログ・トリガーを作成する前に、Oracle Ultra Searchインスタンス・スキーマにCREATE ANY TABLEとCREATE ANY TRIGGERのシステム権限があることを確認してください。Oracleデータベースにある表の場合は、データ定義言語（DDL）文を指定して次のものを作成します。
ログ表には、実表に対して行われた変更が保存されます。Oracle Ultra Searchクローラでは、変更情報を使用して、再クロールする必要がある行を特定します。たとえば、Oracle Ultra Searchが生成したログ表には、WK$LOGなどの名前が付きます。
ログ表の構造のルールは、次のとおりです。
実表のすべての主キー列について、ログ表に列を作成します。
実表は、主キー列を最大8列持つことができます。
主キー列に対応するログ表の各列の名前には、Kx（xは、1から8の数字）を指定する必要があります。
主キー列に対応するログ表の各列の型は、VARCHAR2(1000)です。
CHAR(1)型を持つmarkという名前の列は、1つである必要があります。
markという列のデフォルト値はFです。
たとえば、実表employeesの構造は、次のとおりです。
| 列名 | 列型 |
|---|---|
ID |
NUMBER |
NAME |
VARCHAR2(200) |
ADDRESS |
VARCHAR2(400) |
TELEPHONE |
VARCHAR2(10) |
USERNAME |
VARCHAR2(24) |
employees表の主キーがID列とNAME列で構成されている場合、ログ表WK$LOG（表名は自動的に生成されます）の構造は、次のようになります。
| 列名 | 列型 |
|---|---|
K1 |
NUMBER |
K2 |
VARCHAR2(200) |
ログ表を作成するSQL文は、次のとおりです。
CREATE TABLE WK$LOG( K1 VARCHAR2(1000), K2 VARCHAR2(1000), MARK CHAR(1) default 'F');
INSERTトリガー、UPDATEトリガーおよびDELETEトリガーが作成されます。Oracleトリガーは、次のように定義されます。
実表employeesに行が挿入されるたびに、INSERTトリガーによって、1行がログ表に挿入されます。ログ表の行には、k1列とk2列に、idとnameの新しい値がそれぞれ記録されます。Fがmark列に挿入され、この行には処理が必要であることがクローラに示されます。
次に例を示します。
CREATE TABLE employees (id NUMBER, name VARCHAR2(10));
CREATE OR REPLACE TRIGGER wk$ins
AFTER INSERT ON employees
FOR EACH ROW
BEGIN
INSERT INTO WK$LOG(k1,k2,mark)
VALUES(:new.id,:new.name,'F');
END;
/
実表employeesで行が更新されるたびに、UPDATEトリガーによって、2行がログ表に挿入されます。ログ表の最初の行には、k1列とk2列に、idとnameの更新前の値がそれぞれ記録されます。Fがmark列に挿入され、この行には処理が必要であることがクローラに示されます。ログ表の2番目の行には、k1列とk2列に、idとnameの新しい値がそれぞれ記録されます。
次に例を示します。
CREATE OR REPLACE TRIGGER wk$upd
AFTER UPDATE ON employees
FOR EACH ROW
BEGIN
INSERT INTO WK$LOG(k1,k2,mark)
VALUES(:old.id,:old.name,'F');
INSERT INTO WK$LOG(k1,k2,mark)
VALUES(:new.id,:new.name,'F');
END;/
実表employeesから行が削除されるたびに、DELETEトリガーによって、1行がログ表に挿入されます。ログ表の行には、k1列とk2列に、idとnameの削除前の値がそれぞれ記録されます。Fがmark列に挿入され、この行には処理が必要であることがクローラに示されます。
次に例を示します。
CREATE OR REPLACE TRIGGER wk$del
AFTER DELETE ON employees
FOR EACH ROW
BEGIN
INSERT INTO WK$LOG(k1,k2,mark)
VALUES(:old.id,:old.name,'F');
END;/
Oracle以外のリモート・データベースにある表の場合は、次の手順を実行する必要があります。
ログ表を手動で作成します。このログ表は、前述のログ表のルールに従う必要があります。また、実表と同じスキーマおよびデータベース・インスタンスにあることが必要です。
実表に挿入、更新および削除を記録する3つのトリガーを作成します。これらのトリガーは、Oracle表の場合に示したトリガーと同様に動作する必要があります。
ログ表を関連付けます。これらの処理が終了した後で、Oracle Ultra Searchの表データ・ソースの作成時に、「ロギング機能使用可能(Oracle以外の表)」オプションを選択します。このオプションを選択すると、Oracle Ultra Search管理ツールによって、リモート・データベースのログ表の名前を入力するプロンプトが表示されます。Oracle Ultra Searchは、このログ表と実表を関連付けます。Oracle Ultra Searchでは、手順1と手順2が正しく実行されていることが想定されています。
