10g リリース2（10.1.2）
B15741-01
 目次 |
 索引 |
| Oracle® Ultra Search 管理者ガイド 10g リリース2（10.1.2） B15741-01 |
|
この章では、次の項目について説明します。
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 Administrationツールでクローラ統計を監視し、最も多くクロールされているURLおよびWebサーバーを確認します。特定のサイトやURLに、膨大な数のURLアクセスがあることを発見した場合は、次のいずれかを実行してください。
「クローラ」タブでパラメータを変更した後は、必ずクローラを再起動してください。設定の変更は、クローラを再起動するまで反映されません。
この項では、Oracle Ultra Searchの問合せパフォーマンスを改善する方法をいくつか説明します。問合せのパフォーマンスは通常、レスポンス時間とスループットの影響を受けます。
DB_CACHE_SIZE初期化パラメータのチューニングデータベースのバッファ・キャッシュには、データ・ファイルから頻繁にアクセスするデータが保存されています。 このバッファ・キャッシュを効率よく使用することによって、Oracle Ultra Searchの問合せパフォーマンスを改善できます。 キャッシュ・サイズはDB_CACHE_SIZE初期化パラメータによって制御されます。
クローラによる大規模な更新の後は、Oracle Ultra Searchの索引を最適化してください。そのためには、索引の最適化を定期的にスクジューリングします。索引の最適化中は、問合せパフォーマンスが大幅に低下するため、最適化はピーク時以外にスケジュールしてください。
Oracle Ultra Searchの索引は、頻繁に検索されるトークンに基づいて最適化してください。問合せをログに記録するには、Administrationツールを使用して問合せ統計の収集をオンにします。 頻繁に検索されるトークンをトークン・モードでCTX_DDL.OPTIMIZE_INDEXに渡すことができます。 Oracle Ultra Searchの索引名はWK$DOC_PATH_IDXです。
検索のレスポンス時間は、使用されたOracle Text問合せ文字列によって直接影響を受けます。 Oracle Ultra Searchには、ユーザー入力をOracle Textの問合せに拡張するデフォルトの機能がありますが、拡張が簡単であれば検索時間を大幅に削減できます。
|
関連資料
|
共有プールには、ライブラリ・キャッシュとディクショナリ・キャッシュが格納されています。 ライブラリ・キャッシュには、最近実行されたSQLとPL/SQLコードが格納されています。データ・ディクショナリ・キャッシュやライブラリ・キャッシュでのキャッシュ・ミスは、バッファ・キャッシュでのミスに比較してはるかにコストがかかります。このため、共有プールには、頻繁に使用されるデータが確実にキャッシュされるように、サイズを指定する必要があります。 共有プールのサイズは、SHARED_POOL_SIZE初期化パラメータによって制御されます。
Oracle Ultra Search中間層は、JDBCを介してデータベースに接続しています。JDBCでの接続の作成には時間がかかるため、問合せのレスポンス時間を削減するためにオープン接続のプールが使用されます。 Oracle Application Serverでは、OC4Jによってアプリケーション用の接続プールを管理できます。
最小サイズ、最大サイズおよびプールの割当アルゴリズムは、OC4Jのdata-sources.xml構成ファイルで指定できます。
次に、最小2、最大30のオープン接続数を持つデータ・ソース定義の例を示します。各接続は30秒の非アクティブ後にクローズし、新規の接続が負荷に従って動的に作成されます。 その他のキャッシュ・スキームには、FIXED_WAIT_SCHEMEおよびFIXED_RETURN_があります。
NULL_SCHEME
<data-source class="oracle.jdbc.pool.OracleConnectionCacheImpl" name="UltraSearchDS" location="jdbc/UltraSearchPooledDS" username="user" password="pass" url="jdbc:oracle:thin:@hostname:1521:oracle_sid" min-connections="2" max-connections="30" inactivity-timeout="30" > <property name="cacheScheme" value="1" /> </data-source>
頻繁に使用するパッケージは、共有メモリー・プール内に確保してください。確保されたパッケージは、プールの使用状況やアクセス頻度に関係なく、メモリー内に残ります。 パッケージの確保には、提供されているパッケージのDBMS_SHARED_POOLを使用できます。
Oracle Ultra Searchの問合せに使用するPL/SQLパッケージは、WKSYS.WK_QRYです。
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ベースのランチャを起動するスクリプトを実行すると、これらが起動されます。
RMIレジストリおよびデーモン・ポートには柔軟性がありません。 このため、同じホストで他のRMIサービスを実行している場合は、RMIベースのリモート・クロールを使用できません。 また、RMIポート上で両者が競合するので、RMIベースのランチャを2つ実行することはできません。
JDBCベースのリモート・クロールでは、ランチャが起動および実行中である必要があります。
ランチャは、バックエンド・データベースへの2つの永続的なJDBC接続を保守します。 いつでもいずれかの接続が停止すると、JDBCランチャは接続を再度確立しようとします。 接続の再確立の試行回数は、コマンドライン・パラメータとして構成できます。 次の試行までの待機時間も構成できます。
リモート・クローラを起動するとき、Oracle Ultra Searchのバックエンド・データベースは、Java Remote Method Invocation（RMI）またはJDBCを使用してリモート・コンピュータと通信します。
Oracle Ultra SearchはすべてのRMI通信を暗号化します。 ただし、JDBCランチャはOracleシンJDBCドライバを使用します。 セキュリティが問題となる場合、OracleシンJDBCドライバを保護して、すべてのJDBCトラフィックを暗号化します。
Oracle Ultra Searchスケジュールは、それぞれ1つのクローラに関連付けられます。クローラは、Oracleデータベース・ホストまたはリモート・ホストでローカルに実行できます。実行できるスケジュールの数に制限はありません。同様に、実行できるリモート・クローラ・ホストの数に制限はありません。 ただし、各リモート・クローラ・ホストに、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接続経由を選択すると、このオプションを選択できます。
リモート・クローラ・プロファイルを編集するには、「クローラ」タブの「リモート・クローラ・プロファイル」サブタブに進み、編集するリモート・クローラ・プロファイルの「編集」アイコンをクリックします。定義した共有クローラ・リソース用のマウント・ポイントをすべて手動で入力して、リモート・クローラ・プロファイルを編集します。
キャッシュおよびメール・アーカイブ・ディレクトリ。 バックエンド・データベース・ホストとリモート・クローラ・ホストが共有ファイル・システム（NFSなど）上にある場合は、キャッシュ・ファイル・アクセス・モードの設定で「マウントされているファイル・システム経由」を選択します。 次のパラメータの値を指定します。
リモート・クローラ・ホストとバックエンド・データベース・ホストの間に共有ファイル・システムがない場合は、キャッシュ・ファイル・アクセス・モードの設定で「JDBC接続経由」を選択する必要があります。 この場合、次のパラメータの値を指定します。
クローラ・ログ・ディレクトリ。リモート・クローラ・ログ・ディレクトリは、バックエンドのOracle Ultra Searchデータベースからアクセスできる中央位置のNFSマウントである必要はありません。 ただし、中央位置にあるすべてのクローラ・ログ（ローカルおよびリモートのクローラ）を監視する場合には効果的です。
さらに、クロールを始める前に、次のクローラ・パラメータを指定する必要があります。
Javaクラスパス。 通常、このクラスパスは指定する必要がありません。 リモート・クローラ・プロセスが使用するクラスパスは、RMIサブシステムから継承されます。 RMIサブシステム・クラスパスは、それを起動するために使用されたスクリプトによって構成されます。 JavaクラスパスがRMIサブシステムのクラスパスとは別であることが必要な特別な場合にのみ、このクラスパスを変更する必要があります。
スケジュールとデータ・ソースを作成します。 各スケジュールに1つ以上のデータ・ソースを割り当てます。
各スケジュールは、リモート・クローラまたはローカル・クローラに割り当てる必要があります。（ローカルクローラは、Oracleのローカル・データベース・ホスト上で実行されるクローラです。） スケジュールをリモート・クローラ・ホストまたはローカル・データベース・ホストに割り当てるには、「スケジュール」ページにあるスケジュールのホスト名をクリックします。
各スケジュールに対するリモート・クローラ機能を停止し、スケジュールを使用して特定のリモート・クローラ・ホストのかわりにローカル・データベース・ホスト上のクローラを起動することもできます。 リモート・クローラ機能を停止するには、「同期スケジュール」ページのスケジュールのホスト名をクリックします。 リモート・クローラ・ホストを選択すると、RMIベースのリモート・クローラ・ホスト名（またはJDBCベースのランチャ名）が表示されます。 これをローカル・データベース・ホストに変更し、リモート・クロールを使用不可にします。
起動するには、$ORACLE_HOME/tools/remotecrawler/scripts/operating_のスクリプトを使用します。
system
$ORACLE_HOME/tools/remotecrawler/scripts/unix/runall.shを実行します。 JDBCベースのリモート・クロールの場合は、runall_jdbc.shを実行します。
%ORACLE_HOME%¥tools¥remotecrawler¥scripts¥
winnt¥runall.batファイルを実行します。 JDBCベースのリモート・クロールの場合は、runall_jdbc.batを実行します。
RMIベースのリモート・クロールの場合、runallスクリプトは次の処理を順に実行します。
define_envが起動され、必要な環境変数が定義されます。
runregistryが起動され、RMIレジストリが起動されます。
runrmidが起動され、RMIデーモンが起動されます。
register_stubが起動され、必要なJavaクラスがRMIサブシステムに登録されます。JDBCベースのリモート・クロールの場合、runall_jdbcスクリプトは次の処理を順に実行します。
-name: ランチャ名（このランチャの登録に使用した名前）
-url: バックエンドOracle Ultra SearchデータベースへのJDBC接続URL
-user: 接続するデータベース・ユーザー
-password: データベース・ユーザー・パスワード
-rw: JDBC接続の再確立試行間の待機時間(秒単位)
-ra: JDBC接続の再確立を試みる最大回数
-kw: キープ・アライブ・シグナル間の待機時間(ミリ秒単位)
スクリプトを実行する前に、runall_jdbcスクリプトのコンテンツを編集し、各パラメータの値を指定する必要があります。
スケジュールのステータスは、「スケジュール」タブにリストされます。 リモート・クローラの起動プロセスで障害が発生した場合は、ステータスがLAUNCHINGからFAILEDに変更されるまで最大90秒かかります。
スケジュールのステータスを表示するには、スケジュール・リストのクローラのステータスをクリックします。障害が発生したイベントの詳細を表示するには、スケジュールのステータスをクリックします。詳細なスケジュールのステータスが表示されます。
要件のいずれかが満たされていない場合、RMIベースのリモート・クローラは起動できません。次に例を示します。
要件のいずれかが満たされていない場合、JDBCベースのリモート・クローラは起動できません。次に例を示します。
リモート・クローラの起動後は、次のいずれかの方法で、リモート・クローラが実行されていることを確認してください。
psなどのオペレーティング・システムのコマンドを使用することです。 アクティブなJavaプロセスを検索します。
Oracle Ultra Searchは、Real Application Clustersシステムの記憶域アクセスの構成によって、固定ノードまたは任意のノードをクロールできます。必要に応じて、クローラを実行するノードを指定するためのPL/SQL APIが用意されています。 Oracle Ultra Search AdministrationおよびOracle Ultra Searchの検索アプリケーションの場合、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 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シン・ドライバ、およびhostname: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 Ultra Searchクローラで使用される接続文字列は、インストール時に初期化され、WK_ADM.SET_LAUNCH_INSTANCE APIを使用して変更できます。ノードの追加や削除など、システム構成が変更されると、接続文字列も自動的に変更されます。
Oracle Ultra Search管理者は、JDBC OCIドライバを使用してデータベースにログオンするように、ローカル・クローラをオプションで構成できます。これは、次のPL/SQL APIを使用して実行されます。
WK_ADM.SET_JDBC_DRIVER(driver_type)
ここで、
このAPIには、スーパー・ユーザー権限が必要です。 変更はすべてのOracle Ultra Searchインスタンスに影響します。
次の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 Ultra Searchには、表ソースのクロールを最適化するためのロギング機能があります。このロギング機能を使用すると、新たに更新されたドキュメントのみがクロール・プロセスで再検査されます。ソース・データベースがOracleデータベースではない場合、この機能を使用するには、一連の処理を行う必要があります。
ログ表とログ・トリガーを作成する前に、Oracle Ultra Searchインスタンス・スキーマにCREATE ANY TABLEとCREATE ANY TRIGGERのシステム権限があることを確認してください。Oracleデータベースにある表の場合は、データ定義言語（DDL）文を指定して次のものを作成します。
ログ表には、実表に対して行われた変更が保存されます。 Oracle Ultra Searchクローラでは、変更情報を使用して、再クロールする必要がある行を特定します。 たとえば、Oracle Ultra Searchが生成したログ表には、WK$LOGなどの名前が付きます。
ログ表の構造のルールは、次のとおりです。
VARCHAR2(1000)です。
CHAR(1型を持つmarkという名前の列は、1つである必要があります。
たとえば、実表employeesの構造は、次のとおりです。
| 列名 | 列型 |
|---|---|
ID |
NUMBER |
NAME |
VARCHAR2(200) |
ADDRESS |
VARCHAR2(400) |
TELEPHONE |
VARCHAR2(10) |
USERNAME |
VARCHAR2(24) |
employees表の主キーがID列とNAME列で構成されている場合、ログ表WK$LOG（表名は自動的に生成されます）の構造は、次のようになります。
| 列名 | 列型 |
|---|---|
|
|
|
|
|
|
ログ表を作成する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以外のリモート・データベースにある表の場合は、次の手順を実行する必要があります。
|
 Copyright © 2005 Oracle Corporation. All Rights Reserved. |
|