前へ     目次     索引     DocHome     次へ     
iPlanet Directory Server 5.1 管理者ガイド



第 10 章   インデックスの管理


『iPlanet Directory Server 導入ガイド』には、インデックス作成の概念、そのコストと利点、および iPlanet Directory Server に実装されているさまざまなインデックスのタイプについて記載されています。この章では、インデックスメカニズムの導入にあたり、まず検索アルゴリズムについて説明し、続けてインデックスの作成、削除、管理方法について説明します。この章は、次の節で構成されています。



インデックスについて

ここでは、Directory Server におけるインデックス作成の概要について、次の項目ごとに説明します。


インデックスのタイプについて

インデックスは、ディレクトリデータベース内のファイルに格納されます。ファイル名は、ファイルに含まれているインデックスのタイプではなく、インデックス付き属性に基づいて付けられています。特定の属性に複数のインデックスが付けられている場合、インデックスファイルにさまざまなタイプのインデックスが含まれることがあります。たとえば、共通名属性に付いているインデックスはすべて cn.db3 ファイルに保持されます。

Directory Server でサポートされているインデックスのタイプは次のとおりです。

  • 実在インデックス (pres)

    実在インデックス (presence index) には、特定の属性を含むエントリのリストが含まれます。たとえば、アクセス制御情報を含むすべてのエントリを調べる場合などは、このインデックスを使用すると便利です。実在インデックスを含む aci.db3 ファイルを生成すると、ACI=* を効率的に検索して、サーバ用のアクセス制御リストを生成することができます。

    実在インデックスは、ベースオブジェクトの検索には使用できません。

  • 等価インデックス (eq)

    等価インデックス (equality index) では、特定の属性値を含むエントリを効率的に検索することができます。たとえば、cn 属性の等価インデックスを使用すると、cn=Babs Jensen をはるかに効率的に検索することができます。

  • 近似インデックス (approx)

    近似インデックス (approximate index) では、類似または似た音の用語を探すのに有効な近似検索を行うことができます。たとえば、あるエントリに属性値 cn=Robert E Lee が含まれる可能性があるとします。この場合、近似検索を使用して、cn~=Robert Lee、cn~=Robert、または cn~=Lee を検索し、この値を返すことができます。同様に、l~=San Fransisco (スペルミスに注目) を検索すると、l=San Francisco を含むエントリが返されます。

  • 部分文字列インデックス (sub)

    部分文字列インデックス (substring index) は、維持管理にコストがかかるインデックスですが、エントリ内の部分文字列の検索に効果的です。

    たとえば、次のような形式の検索を実行します。

    cn=*derson

    この場合、次のような文字列を含む共通名にマッチします。

    Bill Anderson
    Jill Anderson
    Steve Sanderson

    同様に、次のエントリを検索します。

    telephonenumber= *555*

    この場合、ディレクトリのエントリから、555 を含む電話番号がすべて返されます。


    注  

    部分文字列インデックスとして、各エントリの 2 文字以上を指定する必要があります。  

  • 国際化インデックス

    国際化インデックス (international index) を使用すると、国際化ディレクトリにある情報の検索を高速化することができます。国際化インデックスの作成手順は、通常のインデックス作成手順と似ていますが、属性がインデックス化されるために属性とロケール (locale) (OID) を関連付けて、マッチング規則 (matching rule) を適用します。

    サポートされるロケールと関連付けられた OID のリストについては、付録 D「国際化」を参照してください。追加のマッチング規則 (matching rule) が使用できるように Directory Server を構成する場合には、iPlanet プロフェッショナルサービスにお問い合わせください。

  • ブラウズ (仮想リスト表示) インデックス

    ブラウズインデックス (browsing index) (別名、仮想リスト表示インデックス (virtual list view index)) を使用すると、Directory Server Console でエントリの表示を高速化することができます。ou=people 分岐などのように、ディレクトリの分岐に数百ものエントリが含まれている場合には、特にこのインデックスが有効です。表示性能を向上させるために、ディレクトリツリーのすべての分岐点でブラウズインデックスを作成することができます。この操作は、Directory Server Console または vlvindex コマンド (Solaris 9 プラットフォームの directoryserver vlvindex) を使用して行います。


デフォルトインデックス、システムインデックス、および標準インデックスについて

Directory Server をインストールすると、データベースインスタンスごとに、デフォルトインデックスとシステムインデックス (system index) のセットが 1 組作成されます。これらのインデックスを維持するために、ディレクトリは標準インデックス (standard index) を使用します。


デフォルトインデックスの概要

インデックス作成の要件に応じて、デフォルトインデックス (default index) を修正することができますが、インデックスを削除する前に、企業内のサーバプラグインやその他のサーバが、このインデックスに依存していないことを確認する必要があります。

次の表に、ディレクトリとともにインストールされるデフォルトインデックスのリストを示します。


表 10-1 デフォルトインデックス 

属性

等価

属性

部分文字列

目的

cn  

X  

X  

X  

もっとも一般的なタイプのユーザディレクトリ検索の性能を向上させる  

givenName  

X  

X  

X  

もっとも一般的なタイプのユーザディレクトリ検索の性能を向上させる  

mail  

X  

X  

X  

もっとも一般的なタイプのユーザディレクトリ検索の性能を向上させる  

mailHost  

X  

 

 

iPlanet Messaging Server で使用される  

member  

X  

 

 

iPlanet サーバの性能を向上させる。このインデックスは、参照整合性検査プラグインでも使用される。詳細については、「参照整合性の管理」を参照  

owner  

X  

 

 

iPlanet サーバの性能を向上させる。このインデックスは、参照整合性検査プラグインでも使用される。詳細については、『iPlanet Directory Server 管理者ガイド』を参照  

seeAlso  

X  

 

 

iPlanet サーバの性能を向上させる。このインデックスは、参照整合性検査プラグインでも使用される。詳細については、「参照整合性の管理」を参照  

sn  

X  

X  

X  

もっとも一般的なタイプのユーザディレクトリ検索の性能を向上させる  

telephoneNumber  

X  

X  

X  

もっとも一般的なタイプのユーザディレクトリ検索の性能を向上させる  

uid  

X  

 

 

iPlanet サーバの性能を向上させる  

uniquemember  

X  

 

 

iPlanet サーバの性能を向上させる。このインデックスは、参照整合性検査プラグインでも使用される。詳細については、「参照整合性の管理」を参照  


システムインデックスの概要

システムインデックスは、削除や修正ができないインデックスです。ディレクトリを適切に機能させるためには、システムインデックスが必要です。次の表に、ディレクトリとともにインストールされるシステムインデックスのリストを示します。


表 10-2 システムインデックス 

属性

等価

属性

目的

aci  

 

X  

Directory Server が、データベースに維持されているアクセス制御情報を速く取得できるようにする  

dnComp  

X  

 

ディレクトリのサブツリー検索を高速化するために使用される  

objectClass  

X  

 

ディレクトリのサブツリー検索を高速化するために使用される  

entryDN  

X  

 

DN 検索に基づくエントリの取得を高速化する  

parentID  

X  

 

1 レベル検索におけるディレクトリの性能を強化する  

numSubordinates  

 

X  

「ディレクトリ」タブの表示性能を強化するために、Directory Server Console で使用される  

nsUniqueID  

X  

 

特定のエントリの検索に使用される  


標準インデックスの概要

デフォルトインデックスとその他の内部インデックス作成メカニズムを維持する必要があるため、Directory Server では、いくつかの標準インデックスファイルも維持します。デフォルトで提供される標準インデックスは次のとおりです。これらのファイルを自分で生成する必要はありません。

  • id2entry.db3 : 実際のディレクトリデータベースのエントリが含まれる。その他のすべてのデータベースファイルは、このファイルから作成し直すことができる

  • id2children.db3 : 1 レベル検索、つまりあるエントリのすぐ下の子だけを調べるように、検索の範囲を制限する

  • dn.db3 : サブツリー検索、つまりあるエントリと、そのエントリの下にあるサブツリーのすべてのエントリを調べるように、検索の範囲を制御する

  • dn2id.db3 : エントリの識別名を ID 番号に割り当てることにより、すべての検索を効果的に開始する


検索アルゴリズムの概要

インデックスは、検索を高速化するために使用されます。検索アルゴリズムを理解していると、ディレクトリでどのようにインデックスが使用されるかを理解する上で役立ちます。各インデックスには、cn、共通名、属性などの属性リストと、それぞれの値に対応するエントリへのポインタが含まれます。Directory Server では、次のように検索要求が処理されます。

  1. Netscape Communicator や Directory Server Console などの LDAP クライアントアプリケーションから、ディレクトリに検索要求が送信されます。

  2. ディレクトリは、受信された要求を調べ、指定されたベース DN が、そのデータベースやデータベースリンクに含まれる接尾辞とマッチするかどうかを確認します。

    • マッチする場合、ディレクトリは要求を処理する

    • マッチしない場合、ディレクトリはクライアントに対し、接尾辞がマッチしないことを表すエラーを返す。cn=config の nsslapd-referral 属性でレフェラルが指定されている場合、ディレクトリはそのリクエストの続行をクライアントが試みることができる LDAP URL も返す

  3. 各データベース属性に対する検索要求が単一のインデックスによって満たされた場合は、サーバはこのインデックスを読み込み、マッチする可能性のあるエントリのリストを生成します。属性に対するインデックスがない場合、ディレクトリはデータベースにあるエントリをすべて含めて候補エントリのリストを生成するため、検索速度は大幅に低下します (サーバが使用するインデックスキー (index key) 用に、All ID のトークンが設定されている場合は、ディレクトリでも同じ処理が行われます。All ID については、「インデックスの管理」を参照してください)。

    検索要求に複数の属性が含まれている場合、ディレクトリは複数のインデックスに問い合わせ、候補となるエントリの結果リストをバインドします。

  4. 属性に対するインデックスが存在する場合、ディレクトリは、一連のエントリ ID 番号の形式で、インデックスファイルからマッチする候補を取得します。

  5. ディレクトリは、返されたエントリ ID 番号を使用して、id2entry.db3 ファイルから対応するエントリを読み込みます。次に、Directory Server が候補エントリを 1 つずつ調べ、検索条件とマッチするものがあるかどうかを確認します。マッチするエントリが見つかるたびに、ディレクトリはそのエントリを返します。

    候補エントリがすべて調べられるか、次の属性の 1 つで設定されている制限に達するまで、ディレクトリは検索を続行します。

    • nsSizeLimit : 検索操作から返されるエントリ数の最大値を指定する。この制限値に達すると、ディレクトリはそれまでに見つかった、検索要求とマッチするすべてのエントリとともに、制限サイズを超えたことを示すエラーを返す

    • nsTimeLimit : 検索要求に対して割り当てる最大時間を、秒単位で指定する。この制限値に達すると、ディレクトリはそれまでに見つかった、検索要求とマッチするすべてのエントリとともに、制限時間を超えたことを示すエラーを返す

    • nsLookthroughLimit : 検索要求に応答して候補エントリを調べるときにチェックするエントリ数の最大値を指定する

これらの属性については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

また、ディレクトリでは、メタフォン音声アルゴリズムのバリエーションを使用して、近似インデックスの検索を行います。各値は一連の単語として扱われ、各単語について音声コードが生成されます。


注  

Directory Server 5.0 の Metaphone 音声アルゴリズムでは、US-ASCII 文字だけがサポートされています。したがって、近似インデックスは英語の値だけで使用してください。  

近似検索に入力された値も同様に、一連の音声コードに変換されます。次の条件の両方が満たされる場合は、エントリは照会にマッチするとみなされます。

  • すべての照会文字列が、エントリ文字列で生成されたコードとマッチする

  • すべての照会文字列が、エントリ文字列コードと同じ順序で並べられている

たとえば、次の表は、音声コードが ALS B SRT であるエントリ名 Alice B. Sarette と複数の照会をマッチさせる方法を示しています。


表 10-3 音を使用した近似検索 

照会文字列

音声コード

マッチ / コメント

Alice Sarette  

ALS SRT  

マッチ。コードは正しい順序で指定されている  

Alice Sarrette  

ALS SRT  

マッチ。Sarette のスペルは間違っているが、コードの指定順序は正しい  

Surette  

SRT  

マッチ。Sarette のスペルは間違っているが、生成されたコードが元の名前にある  

Bertha Sarette  

BR0 SRT  

マッチしない。比較される名前に BR0 はない  

Sarette, Alice  

SRT ALS  

マッチしない。コードの指定順序が正しくない  


インデックス付けの利点とコストの比較

新しいインデックスを作成する前に、インデックスを維持する利点とコストのバランスを検証します。次の点に注意してください。

  • 電話番号のように、一般に数字が含まれる属性については、近似インデックスは効果的ではない

  • バイナリ属性については、部分文字列インデックスは機能しない。暗号化されたデータを含むパスワードや、写真を格納するための属性などのように、値が大きくなる場合は、等価インデックスも避ける必要がある

  • 検索であまり使用されない属性のインデックスを保持しても、負荷が高くなるだけで、グローバル検索の性能は改善されない

  • インデックスが付いていない属性も検索要求で指定できるが、検索のタイプによっては、検索の性能が大幅に低下する場合がある

  • 保持するインデックスの数が多くなるほど、必要となるディスク容量も増える

次の例は、どのような場合にインデックスの時間がかかるかを示しています。次のような手順で特定の属性を作成していると想定します。

  1. Directory Server は、追加または修正操作を受け取る

  2. Directory Server はインデックスが付いている属性を調べて、この属性値に対するインデックスが維持されているかどうかを特定する

  3. 作成された属性値にインデックスが付いている場合、Directory Server は新しいインデックスエントリを生成する

  4. サーバによるインデックスの生成が完了すると、クライアントの要求に応じて、実際の属性値が作成される

たとえば、Directory Server から次のようなエントリの追加が要求されたとします。

dn: cn=Bill Pumice, ou=People, o=siroe.com
objectclass: top
objectClass:person
objectClass: orgperson
objectClass: inetorgperson
cn: Bill Pumice
cn: Bill
sn: Pumice
ou: Manufacturing
ou: people
telephonenumber: 408 555 8834
description: Manufacturing lead for the Z238 line.

さらに、Directory Server で次のインデックスを維持しているとします。

  • 共通名属性と姓属性に対する、等価インデックス、近似インデックス、および部分文字列インデックス

  • 電話番号属性に対する、等価インデックスと部分文字列インデックス

  • 説明属性に対する、部分文字列インデックス

この場合、このエントリをディレクトリに追加するためには、Directory Server で次の処理を実行する必要があります。

  1. 「Bill」と「Bill Pumice」用に共通名の等価インデックスエントリを作成します。

  2. 「Bill」と「Bill Pumice」用に共通名の近似インデックスエントリを作成します。

  3. 「Bill」と「Bill Pumice」用に共通名の部分文字列インデックスエントリを作成します。

  4. 「Pumice」用に、姓の等価インデックスエントリを作成します。

  5. 「Pumice」用に、適切な姓の近似インデックスエントリを作成します。

  6. 「Pumice」用に、適切な姓の部分文字列インデックスエントリを作成します。

  7. 「408 555 8834」用に、電話番号の等価インデックスエントリを作成します。

  8. 「408 555 8834」用に、適切な電話番号の部分文字列インデックスエントリを作成します。

  9. 「Manufacturing lead for the Z238 line of widgets」用に適切な説明の部分文字列インデックスエントリを作成します。この文字列用には、大量の部分文字列エントリが生成されます。

この例のように、インデックスの作成にはコストがかかります。



インデックスの作成


ここでは、Directory Server Console とコマンド行を使用して、特定の属性の実在インデックス、等価インデックス、近似インデックス、部分文字列インデックス、および国際化インデックスの作成方法を説明します。またブラウズインデックスを作成する別の手順についても説明します。


注  

iPlanet Directory Server 5.1 は、単一データベース環境とマルチデータベース環境のどちらでも動作します。別のデータベースでは、新しいインデックスは自動的に作成されないので、すべてのデータベースインスタンスに新しいインデックスを必ず作成する必要があります。

ただし、デフォルトインデックスは後続のデータベースインスタンスに自動的に作成および維持されますが、既存のデータベースインスタンスには追加されません。言い換えれば、後続のデータベースでは、一番最後に作成されたデフォルトインデックスが使用されます。これは、2 番目のデータベースインスタンスにデフォルトインデックスを追加した場合、このインデックスは最初のデータベースインスタンスに維持されるのではなく、後続のインスタンスに維持されることを意味します。  

ここでは、次の手順について説明します。


Server Console を使用したインデックスの作成

Directory Server Console を使用して、特定の属性用に実在インデックス、等価インデックス、近似インデックス、部分文字列インデックス、および国際化インデックスを作成することができます。

インデックスを作成するには、次の手順を実行します。

  1. Directory Server Console で、「構成」タブを選択します。

  2. 「データ」ノードを展開し、インデックスを作成するデータベースの接尾辞を展開して、データベースを選択します。

  3. 右側の区画で「インデックス」タブを選択します。


    注  

    「データベースの設定」ノードはクリックしないでください。このノードをクリックすると、データベースごとにインデックスを構成するためのウィンドウではなく、「デフォルトインデックスの設定」ウィンドウが表示されてしまいます。  

  4. 「追加インデックス」テーブルにインデックスを作成する属性がリストされている場合は、手順 6に進みます。それ以外の場合は、「属性の追加」をクリックします。

    ダイアログボックスが開き、サーバスキーマにある使用可能な属性のリストが表示されます。

  5. インデックスを作成する属性を選択し、「OK」をクリックします。

    選択した属性が「追加インデックス」テーブルに追加されます。

  6. 各属性について、保持するインデックスのタイプに対応するチェックボックスを選択します。

  7. 英語以外の言語のインデックスを作成する場合は、「マッチング規則」フィールドで使用する照合順序 (collation order) の OID を入力します。

    複数の OID をコンマ (スペースではなく) で区切って指定することにより、属性に複数の言語を使用したインデックスを付けることができます。言語とその OID のリスト、および照合順序に関する詳しい説明については、付録 D「国際化」 を参照してください。

  8. 「保存」をクリックします。

    「インデックス」ダイアログボックスが表示されます。このダイアログボックスには、インデックスの作成状態と作成日時が表示されます。作成したインデックスの状態を表示するには、「状態ロゴ」ボックスをクリックします。インデックスの作成が完了したら、「閉じる」をクリックして、「インデックス」ダイアログボックスを閉じます。

追加されたすべての新規データおよびディレクトリ内の既存データに対して、新しいインデックスがすぐに有効になります。サーバを再起動する必要はありません。


コマンド行からのインデックスの作成

コマンド行を使用して、特定の属性の実在インデックス、等価インデックス、近似インデックス、部分文字列インデックス、および国際化インデックスを作成することができます。

コマンド行を使用したインデックスの作成は、次の 2 つのステップで行われます。

  • ldapmodify コマンド行ユーティリティを使用して、新しいインデックスエントリを追加するか、または既存のインデックスエントリを編集する

  • Perl スクリプト db2index.pl (Solaris 9 プラットフォームの directoryserver db2index-task) を実行して、サーバに保持される新しいインデックスのセットを生成する


    注  

    システムインデックスは、Directory Server にハードコードされているので、新しいシステムインデックスを作成することはできません。  

次の節では、インデックスの作成に必要な手順について説明します。


インデックスエントリの追加

ldapmodify を使用して、使用しているディレクトリに新しいインデックス属性を追加します。デフォルトインデックスの 1 つとなる新しいインデックスを作成する場合は、新しいインデックス属性を cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config エントリに追加します。

特定のデータベース用に新しいインデックスを作成するには、インデックスを cn=index,cn=instanceName,cn=ldbm database,cn=plugins,cn=config エントリに追加します。ここで、cn=instanceName はデータベース名を示します。


注  

dse.ldif ファイルの cn=config エントリの下には、エントリを作成しないようにしてください。単純で平面的な dse.ldif 構成ファイルの cn=config エントリは、通常のエントリと同じように拡張性が高いデータベースには格納されません。その結果、多くのエントリ、特に頻繁に更新されるエントリが cn=config の下に格納されている場合は、性能が低下します。

性能上の理由から、単純なユーザエントリを cn=config の下に格納することはお勧めできませんが、ディレクトリマネージャまたはレプリケーションマネージャ (サプライヤバインド DN) エントリなどの特別なユーザエントリを cn=config, の下に格納すると、構成情報を一元化できるため便利です。  

エントリを追加するために必要な LDIF 更新文については、「LDIF 更新文」を参照してください。

たとえば、Siroe1 データベースに、sn (姓) 属性の実在インデックス、等価インデックス、および部分文字列インデックスを作成するとします。

最初に、次のユーティリティを含むデフォルトディレクトリに移動します。

Solaris 9 プラットフォーム

# cd /usr/iplanet/ds5/shared/bin

その他のプラットフォーム

# cd /usr/iplanet/servers/shared/bin

次のように ldapmodify コマンド行ユーティリティを実行します。

ldapmodify -a -h server.siroe.com -p 389 \
           -D "cn=Directory Manager" -w password

ldapmodify ユーティリティはサーバにバインドし、構成ファイルにエントリを追加する準備を行います。ldapmodify コマンド行ユーティリティについては、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

次に、新規インデックスに次のエントリを追加します。

dn: cn=sn,cn=index,cn=Siroe1,cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:nsIndex
cn:sn
nsSystemIndex:false
nsIndexType:pres
nsIndexType:eq
nsIndexType:sub
nsMatchingRule:2.16.840.1.113730.3.3.2.3.1

cn 属性には、インデックスを作成する属性名 (この例では、sn 属性) が含まれます。エントリは、nsIndex オブジェクトクラスのメンバーです。nsSystemIndex 属性は false で、Directory Server 操作にインデックスがなくてもかまわないことを示します。複数値 nsIndexType 属性には、実在 (pres) インデックス、等価 (eq) インデックス、および部分文字列 (sub) インデックスが指定されています。キーワードは、別々の行に入力する必要があります。nsMatchingRule 属性は、OID がブルガリア語の照会順序で指定されていることを示します。

インデックスエントリを指定し、nsIndexType 属性には何も指定しなかった場合、国際化インデックスを除くすべてのインデックスが、指定された属性で保持されます。たとえば、上記の例の代わりに、新しい sn インデックスに対して、次のエントリを指定したとします。

dn: cn=sn,cn=index,cn=instance,cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:nsIndex
cn:sn
nsSystemIndex:false
nsIndexType:

この新しいエントリによって、sn (姓) 属性用にすべてのインデックスが作成されます。

この属性用にインデックスを保持しないことを指定するには、nsIndexType 属性でキーワード none を使用します。たとえば、Siroe1 データベースで今作成した sn インデックスを一時的に無効にするとします。次のように nsIndexType を none に変更します。

dn: cn=sn,cn=index,cn=Siroe1,cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:nsIndex
cn:sn
nsSystemIndex:false
nsIndexType:none

照会順序と OID のリストについては、付録 D「国際化」 を参照してください。

インデックスの構成属性については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。


注  

インデックスを作成する場合は、属性のエイリアスではなく、プライマリ名を常に使用する必要があります。属性のプライマリ名は、スキーマでその属性にリストされた最初の名前です。たとえば、userid 属性では uid がプライマリ名になります。属性のプライマリ名とエイリアス名のリストについては、表 10-6 を参照してください。  


db2index.pl スクリプトの実行

インデックスが付いたエントリを作成するか、既存のインデックスエントリにインデックスのタイプを追加したら、db2index.pl スクリプト (Solaris 9 の directoryserver db2index-task) を実行して、Directory Server で維持される新しいインデックスセットを生成します。スクリプトを実行すると、使用するディレクトリに追加した新規データおよびディレクトリ内の既存データのすべてで、新しいインデックスセットが有効になります。

このスクリプトのコマンドは、プラットフォームごとに異なります。

Solaris 9 プラットフォーム

# /usr/sbin/directoryserver db2index-task

Windows プラットフォーム

installDir> bin¥slapd¥admin¥bin¥perl slapd-serverID¥db2index.pl

その他のプラットフォーム

# installDir/slapd-serverID/db2index.pl

この Perl スクリプトの使い方については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

次の例では、db2index.pl スクリプトを使用してインデックスを作成します。

Windows NT バッチファイル

iPlanet¥Servers¥bin¥slapd¥admin¥bin¥perl.exe
  iPlanet¥Servers¥slapd-siroe¥db2index.pl
    -D "cn=Directory Manager" -w password -n Database1 -t sn

UNIX シェルスクリプト

# use 'directoryserver db2index-task' on Solaris 9 plaforms
db2index.pl \
  -D "cn=Directory Manager" -w password -n Database1 -t sn

次の表に、これらの例で使用されている db2index.pl のオプションを示します。


表 10-4 例で使用した db2index.pl オプションの説明

オプション

内容

-D

 

ディレクトリマネージャの DN を指定する  
-w

 

ディレクトリマネージャのパスワードを指定する  
-n

 

インデックスを作成するエントリを含んだ、データベースの名前を指定する  
-t

 

インデックスを作成するデータベース上の、属性の名前を指定する  

Perl スクリプト db2index.pl については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。


Server Console を使用したブラウズインデックスの作成

Directory Server Console を作成してブラウズインデックスを作成するには、次の手順を実行します。

  1. Directory Server Console で「ディレクトリ」タブを選択します。

  2. 左側のナビゲーションツリーで、インデックスの作成対象のエントリ (People など) を選択し、「オブジェクト」メニューから「ブラウズインデックスの作成」を選択します。

    ナビゲーションツリーで、インデックスの作成対象のエントリをマウスの右ボタンでクリックし、ポップアップメニューから「ブラウズインデックスの作成」を選択します。

  3. 「ブラウズインデックスの作成」ダイアログボックスが開き、インデックス作成の状態が表示されます。作成したインデックスの状態を表示するには、「状態ロゴ」ボックスをクリックします。

  4. 「閉じる」をクリックして、「ブラウズインデックスの作成」ダイアログボックスを閉じます。

    ディレクトリに追加された新しいデータで、新しいインデックスがすぐに有効になります。サーバを再起動する必要はありません。


コマンド行からのブラウズインデックスの作成

コマンド行を使用したブラウズインデックス、または仮想リスト表示 (VLV) の作成は、次の 2 つのステップで行われます。

  • ldapmodify を使用して、新しいブラウズインデックスエントリを追加するか、または既存のブラウズインデックスエントリを編集する

  • vlvindex スクリプト (Solaris 9 プラットフォームの directoryserver vlvindex) を実行して、サーバに保持される新しいブラウズインデックスのセットを生成する

次の節では、ブラウズインデックスの作成に必要な手順について説明します。


ブラウズインデックスエントリの追加

作成するブラウズインデックスエントリのタイプは、高速化を望む ldapsearch の属性ソートのタイプによって異なります。次の項目を考慮することが重要です。

たとえば、ブラウズインデックスを作成して、Siroe1 データベース内のエントリ "dc=siroe,dc=com" で ldapsearch を高速化するとします。ここで、検索ベースには "dc=siroe,dc=com"、検索フィルタには (|(objectclass=*)(objectclass=ldapsubentry))、範囲には one、返される属性のソート順には cn、givenname、o、ou、および sn を指定します。

最初に、次のユーティリティを含むデフォルトディレクトリに移動します。

Solaris 9 プラットフォーム

# cd /usr/iplanet/ds5/shared/bin

その他のプラットフォーム

# cd /usr/iplanet/servers/shared/bin

次のように ldapmodify コマンド行ユーティリティを実行します。

ldapmodify -a -h server -p 389 -D "cn=directory manager" -w password

ldapmodify ユーティリティはサーバにバインドし、構成ファイルにエントリを追加する準備を行います。

次に、ブラウズインデックスを定義するブラウズインデックスエントリを 2 つ追加します。

最初のエントリでは、ブラウズインデックスのベース、範囲、フィルタを指定します。

dn: cn="dc=siroe,dc=com",cn=Siroe1,cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:vlvSearch
cn:"dc=siroe,dc=com"
vlvbase:"dc=siroe,dc=com"
vlvscope:one
vlvfilter:(|(objectclass=*)(objectclass=ldapsubentry))

cn にはブラウズインデックスを作成するエントリを示す、ブラウズインデックスの識別子が含まれます。この例では、"dc=siroe,dc=com" エントリです。ブラウズインデックス識別子には、エントリに dn を使用することをお勧めします。これは Directory Server Console で採用されたアプローチで、これによって同じブラウズインデックスが複数作成されることを回避することができます。エントリは、vlvSearch オブジェクトクラスのメンバーです。vlvbase 属性値は、ブラウズインデックスの作成先エントリを示します。この例では、"dc=siroe,dc=com" エントリ、つまりブラウズインデックス識別子になります。vlvscope 属性は one で、これは高速にする検索のベースが one (1 レベル) であることを示します。one という検索ベースは、エントリ自体ではなく、cn 属性で指定されたエントリすぐ下の子だけが検索されることを意味します。vlvfilter は検索で使用されるフィルタを示します。この例では、(|(objectclass=*)(objectclass=ldapsubentry)) です。

2 番目 のエントリは、返される属性のソート順を示します。

dn:cn=sort_cn_givenname_o_ou_sn,cn="dc=siroe,dc=com",cn=Siroe1,
cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:vlvIndex
cn:cn=sort_cn_givenname_o_ou_sn
vlvsort:cn givenname o ou sn

cn には、ブラウズインデックスのソート識別子が含まれます。作成したブラウズインデックスの検索ソート順を明確に示すソート識別子を使用することをお勧めします。この例では、明示的なソート識別子 cn=sort_cn_givenname_o_ou_sn が使用されています。エントリは、vlvIndex オブジェクトクラスのメンバーです。vlvsort 属性値は好みの属性のソート順を示します。上記の例では、cn、givenname、o、ou、sn の順にソートされます。


注  

この最初のブラウズインデックスエントリは、cn=instanceName,cn=ldbm database,cn=plugins,cn=config ディレクトリのノードに追加する必要があります。また、2 番目のエントリは最初のエントリの子になるようにする必要があります。  


vlvindex コマンドの実行

2 つのブラウズインデックスエントリを作成するか、既存のブラウズインデックスエントリに追加の属性タイプを追加したあと、vlvindex コマンド (Solaris 9 プラットフォームのdirectoryserver vlvindex) を実行して、Directory Server で維持される新しいブラウズインデックスセットを生成します。スクリプトを実行すると、使用するディレクトリに追加された新規データおよびディレクトリ内の既存データのすべてで、新しいブラウズインデックスセットが有効になります。

ブラウズインデックスを生成するには、次のコマンドを使用します。

Solaris 9 プラットフォーム

# /usr/sbin/directoryserver vlvindex

その他のプラットフォーム

# installDir/slapd-serverID/vlvindex

このスクリプトの使い方については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

次の例では、vlvindex コマンドを使用してブラウズインデックスが生成されます。

# vlvindex -n Database1 -T "dc=siroe,dc=com"


表 10-5 例で使用した vlvindex オプションの説明 

オプション

内容

-n

 

インデックスを作成するエントリを含んだ、データベースの名前を指定する  
-t

 

ブラウズインデックスの作成時に使用するブラウズインデックス識別子を指定します  

vlvindex コマンドについては、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。



インデックスの削除


ここでは、特定の属性の実在インデックス、等価インデックス、近似インデックス、部分文字列インデックス、国際化インデックス、およびブラウズインデックスを削除する方法を説明します。
注  

iPlanet Directory Server 5.1 は、シングルデータベース環境、マルチデータベース環境のどちらでも動作するので、すべてのデータベースインスタンスから不要なインデックスをすべて削除する必要があります。

削除するデフォルトインデックスは、既存のデータベースインスタンスにある以前のインデックスセットから削除されません。  

ブラウズインデックスの削除手順は異なるので、別の節で説明します。ここでは、次の手順について説明します。


Server Console を使用したインデックスの削除

Directory Server Console を使用して、作成したインデックス、Messaging Server や Calendar Server などほかの iPlanet サーバが使用しているインデックス、およびデフォルトインデックスを削除できます。システムインデックスは削除できません。

Directory Server Console を使用してインデックスを削除するには、次の手順を実行します。

  1. Directory Server Console で、「構成」タブを選択します。

  2. 「データ」ノードを展開し、インデックスが含まれるデータベースに関連付けられた接尾辞を展開します。削除するインデックスを含むデータベースを選択します。

  3. 削除するインデックスを含む属性を特定します。インデックスの下にあるチェックボックスの選択を解除します。

    特定の属性に保持されているすべてのインデックスを削除する場合は、「属姓名」の下にある属性セルを選択し、「属性の削除」をクリックします。

  4. 「保存」をクリックします。

    「インデックスの削除」警告ダイアログボックスが表示され、インデックスを削除するかどうかの確認が求められます。「はい」をクリックして、インデックスを削除します。

  5. 「ブラウズインデックスの削除」ダイアログボックスが開き、インデックス削除の状態が表示されます。削除したインデックスの状態を表示するには、「状態ロゴ」ボタンをクリックします。インデックスの削除が完了したら、「閉じる」をクリックして、「ブラウズインデックスの削除」ダイアログボックスを閉じます。


コマンド行からのインデックスの削除

次のように ldapdelete コマンド行ユーティリティを使用してインデックスを削除できます。

  • ldapdelete コマンド行ユーティリティを使用して、インデックスエントリ全体を削除するか、または既存のインデックスエントリから不要なインデックスのタイプを削除する

  • db2index.pl スクリプト (Solaris 9 プラットフォームの directoryserver db2index-task) を使用して残りのインデックスがサーバによって維持されるようにする

次の節では、インデックスの削除に必要な手順について説明します。


インデックスエントリの削除

インデックスエントリ全体、または既存のエントリから不要なインデックスのタイプを削除するには、ldapdelete コマンド行ユーティリティを使用します。

特定のデータベースのインデックスを削除するには、cn=index,cn=instanceName,cn=ldbm database,cn=plugins,cn=config エントリからインデックスエントリを削除します。ここで、cn=instanceName はデータベース名を示します。

デフォルトインデックスを削除するには、このインデックスを cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config エントリから削除します。

たとえば、Siroe1 データベースで、sn (姓) 属性の実在インデックス、等価インデックス、および部分文字列インデックスを削除するとします。

この場合、次のエントリを削除します。

dn: cn=sn,cn=index,cn=Siroe1,cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:nsIndex
cn:sn
nsSystemIndex:false
nsIndexType:pres
nsIndexType:eq
nsIndexType:sub
nsMatchingRule:2.16.840.1.113730.3.3.2.3.1

次のデフォルトディレクトリから ldapdelete コマンド行ユーティリティを実行します。

Solaris 9 プラットフォーム

# cd /usr/iplanet/ds5/shared/bin

その他のプラットフォーム

# cd /usr/iplanet/servers/shared/bin

次に、ldapdelete を実行します。

ldapdelete -h server.siroe.com -p 389 \
  -D "cn=Directory Manager" -w password \
  "cn=sn,cn=index,cn=Siroe1,dn=ldbm database,cn=plugins,dn=config"

ldapdelete コマンド行ユーティリティのオプションについては、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

このエントリを削除すると、sn 属性の実在インデックス、等価インデックス、部分文字列インデックスは、Siroe1 データベースでは維持されなくなります。


残りのインデックスの再生成

インデックスエントリを削除またはインデックスエントリからいくつかのインデックスタイプを削除した場合、Directory Server によって維持されるように残りのインデックスセットを再生成する必要があります。

インデックスを再生成するには、「db2index.pl スクリプトの実行」で説明されている手順に従います。スクリプトを実行すると、使用するディレクトリに追加した新規データおよびディレクトリ内の既存データのすべてで、新しいインデックスセットが有効になります。

db2index.pl Perl スクリプト (Solaris 9 プラットフォームのdirectoryserver db2index-task) については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。


Server Console を使用したブラウズインデックスの削除

Directory Server Console を使用して、ブラウズインデックスを削除するには、次の手順を実行します。

  1. Directory Server Console で、「データベース」タブを選択します。

  2. ナビゲーションツリーで、インデックスの削除対象のエントリ (People など) を選択し、「オブジェクト」メニューから「ブラウズインデックスの削除」を選択します。また、ナビゲーションツリーで削除するエントリをマウスの右ボタンでクリックして、ポップアップメニューから「ブラウズインデックスの削除」を選択します。

  3. 「ブラウズインデックスの削除」ダイアログボックスが表示され、インデックスを削除するかどうかの確認が求められます。「はい」をクリックして、インデックスを削除します。

  4. 「ブラウズインデックスの削除」ダイアログボックスが開き、インデックス削除の状態が表示されます。


コマンド行からのブラウズインデックスの削除

コマンド行を使用したブラウズインデックス、または仮想リスト表示 (VLV) の削除は、次の 2 つのステップで行われます。

  • ldapdelete コマンド行ユーティリティを使用して、ブラウズインデックスエントリを削除するか、または既存のブラウズインデックスエントリを編集する

  • vlvindexコマンド (Solaris 9 プラットフォームの directoryserver vlvindex) を実行して残りのインデックスを再生成する

次の節では、ブラウズインデックスの削除に必要な手順について説明します。


ブラウズインデックスエントリの削除

ブラウズインデックスエントリを削除したり、既存のブラウズインデックスエントリを編集するには、ldapdelete コマンド行ユーティリティを使用します。

特定のデータベースのブラウズインデックスを削除するには、cn=index,cn=instanceName,cn=ldbm database,cn=plugins,cn=config エントリからブラウズインデックスエントリを削除します。ここで、cn=instanceName はデータベース名を示します。

たとえば、Siroe1 データベース内のエントリ dc=siroe,dc=com で ldapsearch の操作を高速化するブラウズインデックスを削除するとします。ここで、検索ベースには dc=siroe,dc=com、検索フィルタには (|(objectclass=*)(objectclass=ldapsubentry))、範囲には one、返される属性のソート順には cn、givenname、o、ou、および sn となっています。

このブラウズインデックスを削除するには、次の 2 つの対応するブラウズインデックスエントリを削除する必要があります。

dn: cn="dc=siroe,dc=com",cn=Siroe1,cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:vlvSearch
cn:"dc=siroe,dc=com"
vlvbase:"dc=siroe,dc=com
vlvscope:one
vlvfilter:(|(objectclass=*)(objectclass=ldapsubentry))

および

dn:cn=sort_cn_givenname_o_ou_sn,cn="dc=siroe,dc=com",cn=Siroe1,
cn=ldbm database,cn=plugins,cn=config
objectClass:top
objectClass:vlvIndex
cn:cn=sort_cn_givenname_o_ou_sn
vlvsort:cn givenname o ou sn

次のデフォルトディレクトリから ldapdelete コマンド行ユーティリティを実行します。

Solaris 9 プラットフォーム

# cd /usr/iplanet/ds5/shared/bin

その他のプラットフォーム

# cd /usr/iplanet/servers/shared/bin

次に、ldapdelete を実行します。

ldapdelete -h siroe.server.com -p 389 -D "cn=Directory Manager" -w password \
  "cn="dc=siroe,dc=com",cn=Siroe1,cn=ldbm database,cn=plugins,cn=config" \
  "cn=sort_cn_givenname_o_ou_sn,cn="dc=siroe,dc=com",cn=Siroe1, \
cn=ldbm database,cn=plugins,cn=config"

ldapdelete コマンド行ユーティリティのオプションについては、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

検索ベースが dc=siroe,dc=com、検索フィルタが (|(objectclass=*)(objectclass=ldapsubentry))、範囲が one、返される属性のソート順が cn、givenname、o、ou、sn であるこれら 2 つのブラウズインデックスエントリを削除すると、Siroe1 データベースに格納されているエントリ dc=siroe,dc=com の ldapsearch 操作を高速化するためのブラウズインデックスは Siroe1 データベースでは維持されなくなります。


残りのインデックスの再生成

ブラウズインデックスエントリを削除するか、既存のインデックス参照エントリから不要なインデックスのタイプを削除したあと、Directory Server によって維持されるように残りのインデックスセットを再生成する必要があります。

ブラウズインデックスを再生成するには、「vlvindex コマンドの実行」で説明されている手順に従います。スクリプトを実行すると、使用するディレクトリに追加した新規データおよびディレクトリ内の既存データのすべてで、新しいインデックスセットが有効になります。

vlvindex コマンド (Solaris 9 プラットフォームの directoryserver vlvindex) については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。



インデックスの管理


ディレクトリが使用するインデックスは、インデックスキーのテーブルとマッチングの エントリ ID リスト (entry ID list) で構成されます。エントリ ID リストは、クライアントアプリケーションの検索要求とマッチする可能性がある候補エントリのリストを構築するために、ディレクトリが使用します (「インデックスについて」を参照)。

各エントリ ID リストに、nsslapd-allidsthreshold 属性で指定されたサイズ制限が適用されます。このサイズ制限はサーバによって管理されるすべてのインデックスキー全体に適用され、論理的にはすべての ID のしきい値 (All IDs Threshold) と呼ばれます。1 つの ID リストのサイズがこの制限値に達すると、その ID リストがすべての ID のトークンと置き換えられます。

すべての ID のトークンによって、ディレクトリエントリがすべてインデックスキーとマッチしているとサーバが認識します。実際には、すべての ID のトークン (All IDs token) によって、サーバは指定された検索のタイプで利用可能なインデックスが存在しないかのように動作します。ディレクトリは、サーバが検索要求の別の側面によって、要求を処理する前に候補リストを絞り込んでいると認識します。

次の節では、すべての ID メカニズムの長所と短所について説明します。また、すべての ID のしきい値の調整についてのアドバイスも示します。


すべての ID メカニズムの長所

すべての ID メカニズムは、検索結果がディレクトリエントリのほとんどまたは全体になる場合 (cn=* の検索など) に、検索性能を向上させる重要なメカニズムです。Directory Server から、すべてのエントリ ID が返された場合には、次のような仮定をします。

  • 無限に増加するエントリ ID リストを保持する必要がなくなり、Directory Server のディスク使用量を最小限にすることができる

  • すべての結果を含んだディレクトリエントリを返す検索要求に対応するために、不必要に大きいエントリ ID リストをメモリにロードする必要がなくなり、大量のディスク読み込み処理が減り、検索性能が向上する

  • 不必要に大きいエントリ ID リストをメモリに保持する必要がなくなり、大量の RAM が必要とされなくなる


すべての ID メカニズムの短所

ディレクトリのサイズと比べて、すべての ID のしきい値の設定が低すぎたり (ほとんどの場合は、これが問題となる)、高すぎたりすると、性能上の問題が発生します。


すべての ID のしきい値が低すぎる場合

すべての ID のしきい値の設定が低すぎると、必要以上に大量のインデックスキーにすべての ID のトークンが含まれるようになります。この結果、必要以上に多くのディレクトリですべてのエントリが調べられることになります。この検索によって性能に重大な影響が及びます。

たとえば、共通名 (cn) 属性で等価インデックスを管理しているとします。cn インデックスに格納されているインデックスキーの 1 つは cn=James です。対応するエントリ ID リストには、James に設定されている属性を含むすべてのエントリ ID 番号が含まれます。

ディレクトリにあるエントリの一部にしか cn=James は含まれないため、cn 属性の等価インデックスの維持は簡単です。検索要求に対応する場合、エントリ ID の一部だけを調べれば済むため、cn=James フィルタを使用する検索の性能は向上します。

ただし、ディレクトリは時間とともに大きくなり続ける可能性があります。このため、James が追加されていく可能性がありますが、ディレクトリエントリ全体に比べれば、その比率は同じく相対的に小さなものです。最終的に、cn=James エントリ ID リストは非常に大きくなる可能性がありますが、検索性能のためにはこのリストが必要です。すべての ID のしきい値に達するほどたくさんの cn=James エントリが追加されディレクトリが大きくなった場合、cn=James エントリ ID リストは、すべての ID トークンで置き換えられます。cn=James を検索するたびに、Directory Server は、検索要求に応じてディレクトリ内のすべてのエントリを調べます。

データベースが大きくなると、すべてのインデックスキーの大部分がすべての ID のしきい値に設定され、検索性能は大幅に低下します。


すべての ID のしきい値が高すぎる場合

すべての ID のしきい値の設定値が高すぎても、性能上の問題が発生します。すべての ID のしきい値が極端に高いと、検索要求に応答するために維持され、検索時にメモリに読み込まれるリストが、より大きくなります。極端に高く設定されたすべての ID のしきい値によって、すべての ID メカニズムの長所はすべて失われます (詳細は、「すべての ID メカニズムの長所」を参照)。


単一のエンタープライズディレクトリにおけるすべての ID のしきい値の調整に関するアドバイス

サーバで、デフォルトのすべての ID のしきい値を変更するときには、注意が必要です。このしきい値を適切でない値に変更すると、サーバの性能は向上せずに、かえって低下する結果になります。この調整に関するアドバイスは、80,000 エントリまでの単一のエンタープライズディレクトリを主に対象にしています。

ディレクトリサイズが一定の場合は、すべての ID のしきい値を、ディレクトリに格納されている総エントリ数の約 5 % に設定します。つまり、ディレクトリに 50,000 のエントリある場合は、すべての ID のしきい値を 2,500 に設定します。

将来、ディレクトリに大量のエントリを追加する予定がある場合は、すべての ID のしきい値を慎重に設定する必要があります。次の点を考慮してください。

  • すべての ID のしきい値を変更すると、データベースの再構築が必要となる。この操作には、コストがかかる可能性がある。特に、数百万ものエントリを含むディレクトリでは、かなりのコストがかかる

  • すべての ID のしきい値には、ディレクトリサイズの 5 % に設定することが推奨されているが、しきい値を現在のデータベースサイズの 0.5 % から 50 % までの間に設定しても、大きな性能上の問題は発生しない。しかし、できる限り、5 % 前後にすることを推奨する

現在のディレクトリの要件と将来の拡張計画のバランスを考えて計画することで、すべての ID のしきい値をあとから変更 (データベースの再構築が必要) しないで済むようにする必要があります。

たとえば、現在、ディレクトリに 50,000 エントリあるとします。しかし、数年後には、ディレクトリのサイズが 1,000,000 エントリまで大きくなることが予測されます。すべての ID のしきい値を 50,000 の 5 %、つまり 2,500 に設定した場合、ディレクトリが 1,000,000 エントリまで大きくなると、性能上の問題が発生します。1,000,000 エントリのデータベースにおけるしきい値の最小値は、1,000,000 の 0.5%、つまり 5,000 エントリなので、2,500 エントリでは少なすぎます。

将来、ディレクトリが大きくなることが予想される場合は、次のどちらかの方法を選択します。

  • すべての ID のしきい値を現在の最適値 (2,500) に設定しておき、このしきい値の設定では正常な動作が保証されないほどエントリ数が増加したときに、データベースを再構築する。データベースを再構築するには、再構築している間ディレクトリを停止するか、少なくともディレクトリを読み取り専用モードにする。また、該当する Directory Server によってエントリがレプリケートされるコンシューマサーバも、初期化し直さなければならない

  • 現在の要件と比べると高すぎるが、将来の要件を考えたときにも問題なく動作する値を見つける。たとえば、現在のディレクトリに 50,000 エントリに対して、すべての ID のしきい値を 20,000 に設定する。これは 50,000 の 40 % (現在のディレクトリの要件の範囲内) であり、1,000,000 の 2 % (将来のディレクトリの要件の範囲内) でもある

どちらの戦略を選ぶかは、ディレクトリを導入する際の要件によって決めます。データベース (および関連するコンシューマサーバ) の再構築にかかるコストと、すべての ID のしきい値を理想的な 5 % の設定から変更することによる性能への影響を比較検討してください。


注  

コンシューマサーバはさまざまな検索に対して応答するように調整されるため、コンシューマサーバのすべての ID のしきい値は、異なる値を設定するほうが適切な場合もあります。  

また、ディレクトリが大きくなる速度や、ディレクトリのサイズを大きくするのにかかる時間も考慮してください。ディレクトリが大きくなるのに何年もかかる場合は、データベースの再構築を計画します。数か月のうちに、ディレクトリが急速に大きくなる場合は、データベースを再構築する回数を最小限にできるように、すべての ID のしきい値を設定する方法を考えます。


サービスプロバイダおよびエクストラネットにおけるすべての ID のしきい値の調整に関するアドバイス

ホストサービスプロバイダ、エクストラネットのディレクトリ、およびエントリ数が 80,000 を超えるディレクトリの調整に関しては、iPlanet プロフェッショナルサービス にお問い合わせください。


すべての ID のしきい値のデフォルト値

デフォルトでは、Directory Server のすべての ID のしきい値は 4000 に設定されています。この値は、80,000 エントリまでのデータベースに適しています。データベースが 80,000 エントリを超える可能性がある場合は、データベースを実装する前に、すべての ID のしきい値を増やすことをお勧めします。


すべての ID のしきい値が適切でない場合の徴候

すべての ID のしきい値の設定が適切でないと、検索性能が低下します。しかし、その他の理由でも、検索性能が低下することがあります。たとえば、次のようにします。

  • インデックスを維持していないエントリに対して検索が頻繁に行われた

  • 使用しているデータベースのキャッシュサイズとエントリキャッシュサイズの設定が正しくない。 詳細は、「Directory Server の性能の調整」を参照

これらの可能性を慎重に検討してから、すべての ID のしきい値を変更してください。

すべての ID のしきい値が低すぎることが原因でサーバに問題があると思われる場合は、アクセスログを確認します (第 12 章「サーバとデータベースアクティビティの監視」 を参照)。すべてのエントリ ID を返す検索には、notes=U フラグが付きます。notes=U フラグは、次の検索に対して返されます。

  • インデックスが維持されてないエントリに対する検索

  • そのインデックスキーですべての ID のしきい値に達したために、ID リストが維持されていないエントリに対する検索

検索結果が、インデックスを作成しておくべき検索に属するかどうかを判断するには、RESULT 行の conn と op の値を、アクセスログファイルにある以前の SRCH 行と一致させる必要があります。SRCH 行には、検索要求で使用された検索フィルタが表示されます。指定された検索フィルタにインデックスが付いている場合は、notes=U フラグは、そのインデックスキーで、すべての ID のしきい値に達したことを示します。たとえば、次のようなアクセスログがあるとします。

[24/July/1998:15:12:20 -0800] conn=2 op=1 SRCH base="o=siroe.com" scope=0 filter="(cn=James)"

[24/July/1998:15:12:20 -0800] conn=2 op=1 RESULT err=0 tag=101 nentries=10000 notes=U

notes=U フラグは、cn 属性のインデックスに対してすべての ID のしきい値に達したことを示します。


すべての ID のしきい値の変更

使用しているサーバのすべての ID のしきい値を変更するには、次の手順を実行します。

  1. Directory Server を停止します。

  2. コマンド行を使用して、すべてのディレクトリデータベースを、LDIF にエクスポートします。

    詳細は、第 4 章「ディレクトリデータベースへのデータの実装」を参照してください。

  3. ldapmodify ユーティリティを使用して、nsslapd-allidsthreshold エントリを編集するか、任意のテキストエディタで次のファイルを編集します。

    Solaris 9 プラットフォーム

    		/var/ds5/slapd-serverID/config/dse.ldif

    その他のプラットフォーム

    		installDir/slapd-serverID/config/dse.ldif

  4. nsslapd-allidsthreshold 属性を探して、必要な値に変更します。

  5. ldif2db を使用して、すべてのデータベースを初期化します。

    第 4 章「ディレクトリデータベースへのデータの実装」 を参照。

  6. Directory Server を再起動します。

すべての ID のしきい値を増やしたあと、データベースのキャッシュサイズを確認してください。

すべての ID のしきい値を増やすと、エントリ ID リストも大きくなるので、より大きなメモリが必要になります。必要となるメモリの増加量は、維持しているインデックスの数とタイプによって異なりますが、nsslapd-allidsthreshold 属性値で増やした量よりも大きくなることはありません。つまり、nsslapd-allidsthreshold 属性値を 2 倍にした場合でも、データベースのキャッシュサイズを現在のサイズの 2 倍以上に増やす必要はありません。

すべての ID のしきい値を増やしたのと同じ割合でデータベースのキャッシュサイズを増やすのは、特殊な方法です。物理メモリが使用可能な場合は、nsslapd-allidsthreshold 値の増分の 25 % だけ、データベースのキャッシュサイズを増やしてください。たとえば、すべての ID のしきい値を 2 倍にしたときは、データベースのキャッシュサイズを 50 % 増やします。必要に応じて、サーバの性能に満足するまで、キャッシュサイズを徐々に増やしてください。

属性 nsslapd-dbcachesize を使用して、データベースのキャッシュサイズを設定します。詳細は、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』の nsslapd-dbcachesize 属性を参照してください。



属性名のクイックリファレンス


次の表に、プライマリ名 (実際の名前) とエイリアス名の両方を持つ属性のリストを示します。インデックスを作成する場合は、必ずプライマリ名を使用してください。


表 10-6 属性のプライマリ名とエイリアス

属性のプライマリ名  

属性のエイリアス名  
dn

 

 distinguishedName

 
cn

 

 commonName

 
sn

 

 surName

 
c

 

 countryName

 
l

 

 localityName

 
st

 

 stateOrProvinceName

 
street

 

 streetAddress

 
o

 

 organization

 
ou

 

 organizationalUnitName

 
facsimileTelephoneNumber

 

 fax

 
uid

 

 userId

 
mail

 

 rfc822mailbox

 
mobile

 

 mobileTelephoneNumber

 
pager

 

 pagerTelephoneNumber

 
co

 

 friendlyCountryName

 
labeledUri

 

 labeledUri

 
ttl

 

 timeToLive

 
dc

 

 domainComponent

 
authorCn

 

 documentAuthorCommonName

 
authorSn

 

 documentAuthorSurname

 
drink

 

 favoriteDrink

 


前へ     目次     索引     DocHome     次へ     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated February 26, 2002