ワークグループエンジンの詳細

サーバーおよびワークグループ製品には同一のネットワークコンポーネントが含まれています。したがって、ワークグループエンジンをサーバーエンジンにアップグレードすることが可能です。クライアント側のリクエスターはいずれのタイプのエンジンにも接続することができます。

PSQL ネットワークサービスレイヤーは、以前サポートされていた名前付きパイプ、DNS および NDS などのプロトコルと同様に、NetBIOS を使用してネットワーク上でエンジンを検索します。NetBIOS および DNS プロトコルは、ワークグループエンジンと交信するのに使用することができます。Windows 上のサーバーエンジンは名前付きパイプを使用して自身をアドバタイズするため、NetBIOS は必要ありません。

クライアントのリクエスターが IP、SPX、または NetBEUI アドレスを見つけると、その転送プロトコルを使用して MicroKernel エンジンに接続を確立しようとします。

クライアント側の MicroKernel ルーターは、完全に確立されたアルゴリズムに従ってファイルのゲートウェイオーナーシップを見つけます。

表 28 ゲートウェイ検索の優先順位
優先順位	手順
1	データファイルと同一のコンピューター上でデータベースエンジンに接続を試みます。
2	ローカルエンジン（クライアントマシン上の）を使用してデータファイルのオープンを試みます。
3	ファイルを所有するゲートウェイエンジンを見つけて接続を試みます。

クライアント側のルーターが常に最初に試みることは、データと同じコンピューター上のエンジンに接続することです。このため、データが存在する場所でエンジンが実行されていることは常に非常に効果的です。

PSQL ネットワークサービスレイヤーは、リモートデータベースエンジンを検索し接続するために多種多様な方法を用いるため、データベースエンジンが実行されていないファイルサーバー上のファイルを最初に開こうとするときに時間がかかることがあります。ゲートウェイ一貫性保持をオンにすると、ルーターがエンジンの位置を特定するのに失敗した各マシンを記憶するので、その後その接続は試行されません。

リモートファイルサーバー上のエンジンに接続できなかった場合、ルーターはローカルエンジンがリモートファイルを開くことを許可します。ローカルエンジンはまず新しいロケーターファイルを作成し、リモートディレクトリのオーナーシップをとることを試みます。既にほかの MicroKernel がそのディレクトリを所有している場合、ローカルエンジンはルーターにステータスコード 116 を返します。

最後に、ルーターはゲートウェイコンピューターを探そうとします。ロケーターファイルを開き、ゲートウェイエンジンの名前を読み取ります。それからエンジンにリクエストを送ります。ルーターは MicroKernel からステータスコード 116 を受け取らなければロケーターファイルを読み取らないことに注意してください。この動作は、ゲートウェイ機能を使用するためにはローカルワークグループエンジンがインストールされている必要があることを示しています。ローカルエンジンがないためにローカルエンジンを使用してリモートファイルを開くことに失敗した場合、ルーターはロケーターファイルを読み取らず、ゲートウェイエンジンを見つけることができません。

サーバーエンジンとワークグループエンジンにはいくつかの重要な相違点があります。このセクションではその違いについて説明します。

サーバーエンジンは、Windows、Linux、および OS X 用の 64 ビット版を提供します。ワークグループエンジンの場合は 32 ビット Windows 版のみです。ワークグループエンジンを 64 ビット Windows オペレーティングシステムで実行することはできますが、アドレス領域が 4 GB に制限されているため、一般的に 64 ビットシステムでインストールされる（2 GB を超える）大量のメモリを活用することはできません。ワークグループエンジンを 32 ビットオペレーティングシステムにインストールする場合、アドレス領域の上限は 2 GB です。

Windows の場合、サーバーエンジンは常に Windows のサービスとして実行するようにインストールされます。ワークグループエンジンは、アプリケーションまたはサービスのどちらとしてインストールするかを設定できます。新規インストールの場合、デフォルトでは、サービスとしてインストールされますアプリケーションとして実行するようにインストールした場合は、タスクバーの通知領域にあるアイコンをインターフェイスとして使用します。『Getting Started with PSQL』のワークグループエンジンのセットアップを参照してください。

サーバーエンジンでは、オペレーティングシステムにおけるファイルのアクセス許可を適用します。ワークグループエンジンは自身でユーザーの認証を行いません。ワークグループエンジンがネットワーク上のコンピューターにアクセスすることができれば、そのデータに到達できます。この緩和されたセキュリティは、セキュリティよりも使いやすさを優先する小規模のオフィスを対象としています。

ワークグループエンジン用のオペレーティングシステム認証がないということは、Btrieve の "混合" セキュリティポリシーと "クラシック" セキュリティポリシーが同じであることを意味します。セキュリティポリシーの違いは、サーバーエンジンとワークグループエンジン間の動作の違いです。詳細については、PSQL セキュリティを参照してください。

ワークグループエンジンは、ローカル、リモート共にファイルを開いたすべての場所にロケーターファイルを作成することにより、ワークグループエンジンがゲートウェイのオーナーシップを絶えず動的に適合できるようにします。デフォルトで、ワークグループエンジンはほかのコンピューターやネットワークデバイスで認証されるユーザー ID でも実行されます。このため、ワークグループエンジンはゲートウェイ環境での使用に最適です。『Getting Started with PSQL』のゲートウェイ構成のセットアップを参照してください。

サーバーエンジンは必ずしもゲートウェイロケーターファイルを作成する、または引き受けるわけではありません。このため、サーバーエンジンをゲートウェイ環境で使用するような設計やテストを行っていません。そのため、ワークグループ環境でワークグループエンジンに代わってサーバーエンジンをゲートウェイとすることはサポートしていません。

Windows 版のサーバーエンジンは非同期 I/O を使用します。また、データベースページの書き込みの結合はサーバーエンジンでのみ行われます。これらの機能によって、I/O の負荷が高いときは、ワークグループエンジンに比べサーバーエンジンが大きなパフォーマンスの利点を得ることができます。

いくつかのデータベース設定（キャッシュサイズやシステムキャッシュなど）のデフォルト値は、サーバーエンジンとワークグループエンジンでそれぞれ異なります。ワークグループエンジン設定用のデフォルト値は、システムリソースの消費をより抑えるよう設定されます。設定リファレンスを参照してください。

PSQL Server および PSQL Workgroup ではユーザーカウントライセンスモデルを使用します。PSQL Vx Server では容量ベースライセンスモデルを使用します。『PSQL User's Guide』のライセンスモデルを参照してください。

このセクションでは、ワークグループ環境での問題の解決に役立つヒントを提供します。

最初のファイルオープンリクエストが発行されるときに何度も遅延が起きるのであれば、次の方法が役に立つかどうか調べてください。

ファイルオープンのリクエストをどこに送るかを決定するとき、クライアントが最優先で行う方法は、データが存在する同じマシン上のエンジンに接続することです。ワークグループエンジンがアプリケーションとして実行されるのを確実にするため、次のコマンドを使用してエンジンのアイコンをスタートアップフォルダーに入れます。

もう 1 つの方法としては、ワークグループエンジンをサービスとしてインストールします。『Getting Started with PSQL』を参照してください。また、PSQL ファイルのデフォルトの場所については、『Getting Started with PSQL』のPSQL ファイルはどこにインストールされますか？を参照してください。

データが存在する場所でエンジンを実行できない場合、最初の接続の待ち時間はより重要な問題になります。試してみることがいくつかあります。

1 クライアントの設定で［サポートプロトコル］を減らし、ネットワークで使用されていないプロトコルの使用が試みられないようにします。

2 ゲートウェイ一貫性保持を使用します。ゲートウェイ一貫性保持はクライアントの設定で、ゲートウェイ環境で最初の接続を確立するときの待ち時間をほとんどなくすことができます。［ゲートウェイ一貫性保持］がオンに設定されていると、クライアントルーターがエンジンの実行されていないコンピューター名をレジストリに書き込むようにします。接続に失敗すると、ルーターはこのサーバー名を実行中のみ保存するのではなく、レジストリに保存します。次回アプリケーションが起動したとき、データのある場所のエンジンへの接続は試行されません。直ちに現在のゲートウェイを決定する次の段階に進みます。

この設定は PCC で切り替えることができます。PCC の PSQL エクスプローラーで［ローカルクライアント］ノードを展開し、［MicroKernel ルーター］を右クリックします。［プロパティ］をクリックし、［アクセス］を選択します。［ゲートウェイ一貫性保持］オプションをクリックしてオンに設定し（チェックマークは、その設定が「オン」であることを表します）、［OK］をクリックします。

メモ：この機能はトポロジを固定するため、デフォルトではオフになっています。データが存在する場所にサーバーエンジンまたはワークグループエンジンを追加した場合、この設定をオンにした各クライアントでオフに戻す必要があります。この設定をオフに戻すと、エンジンが実行されていないコンピューターのレジストリを消去するので、その後すぐにオンにすると新しいトポロジに基づいた新しいリストが生成されます。

ステータス 116 は MicroKernel のステータスコードで、ゲートウェイとして動作する別の MicroKernel エンジンによってファイルが使用されていることを示します。アプリケーションがステータスコード 116 を受け取った場合、MicroKernel ルーターはロケーターファイルを読むことができたけれどもゲートウェイコンピューター上で実行されているエンジンと交信できなかったことを示します。

最初にしなければならないことは、ゲートウェイがどれかを見極めることです。この作業は Gateway Locator ユーティリティを使用して行うことができます。

次に PSA ネットワークテストを使用してそのコンピューターに接続してみます。PSA は問題を分離するための役に立つ情報を提供します。

これが起こる 1 つの状況は、2 つのコンピューターがルーターで分けられていて、両方ともファイルサーバーを見ることができるが、互いを見ることができない場合です。

ゲートウェイエンジン操作のこの機能は、複数ディレクトリのデータベースのトランザクションアトミシティを保証し、また複数のデータディレクトリにわたるゲートウェイエンジンの名前の変更を容易にします。

PSQL クライアントがリモートデータファイルにアクセスする際に次の方法を使用することを思い出してください。

2 次に、そのリモートマシンでデータベースエンジンが使用可能でない場合、ローカルエンジンを使用してリモートディレクトリのオーナーシップをとり、ロケーターファイルを作成します。ゲートウェイロケーターファイルが既に存在する場合、ローカルエンジンは使用されません。

ゲートウェイ設定は、データファイルが存在するコンピューター上に使用可能なデータベースエンジンがない場合にのみ有効になることを覚えておいてください。

この機能により、同一ボリューム上の複数ディレクトリのデータベースのトランザクションの一貫性を保持しながら動的（変動）ゲートウェイエンジンを使用することができます。この利点は、別のゲートウェイロケーターファイルを指示する新しいゲートウェイロケーターファイルによってもたらされました。新しいタイプはリダイレクトロケーターファイルと呼びます。ディレクトリ D のロケーターファイルを指示するリダイレクトロケーターファイルをディレクトリ A、B、C に持つことにより、ディレクトリ D のロケーターファイルが指定するゲートウェイエンジンが、ほかのディレクトリにあるデータファイルのサービスも確実に提供することができるようになります。

ディレクトリ D のロケーターファイルが固定ゲートウェイを指定しているか、これらのファイルを最初に開いたエンジンによって動的に作成されるかにかかわらず、このアーキテクチャは指定されたすべてのディレクトリが必ず同一のゲートウェイエンジンを使用します。同様に、いくつかのディレクトリの固定ゲートウェイを変更しようとする場合、リダイレクトロケーターファイルを使用すると、すべてのロケーターファイルではなく、たった 1 つのロケーターファイルを変更するだけで済みます。したがって、一定のハードドライブ上のすべてのデータファイルが固定ゲートウェイを指定しているといないにかかわらず、同一ゲートウェイエンジンを使用するように指定することができます。

リダイレクトロケーターファイルの最初の行は "=>" で始め、その後に必ず同一ドライブ上にある別のロケーターファイルのパスを指定する必要があります。パス名にはスラッシュおよび円記号の任意の組み合わせを使用することができます。スラッシュはすべてローカルオペレーティングシステムの使用するタイプの区切り文字に変換されます。

スラッシュで終わるパスを指定した場合、データベースエンジンはパスの最後にデフォルトのロケーターファイル名（~PVSW~.LOC）を追加します。指定したパスがスラッシュで終わっていない場合、データベースエンジンはパスにファイル名が含まれているものと見なします。

次の表は、リダイレクトロケーターファイルのパスの指定方法の一覧です。

表 29 リダイレクトロケーターファイルパスの記述方法
パス	説明
=>\path_name	現在のロケーターファイルが格納されているルートドライブからパスを指定します。
=>.\path_name	現在のディレクトリからの相対パスを指定します。
=>..\path_name	現在のディレクトリの親ディレクトリからの相対パスを指定します。

これらのロケーターファイルに複数レベルのリダイレクトを割り当てることができます。たとえば、最初のロケーターファイルが 2 番目のロケーターファイルを指示し、2 番目のロケーターファイルが 3 番目のロケーターファイルを指示するという具合です。各ワークグループエンジンはそれぞれのロケーターファイルを順に開き、実際のゲートウェイ名を探します。"=>" で始まらないロケーターファイルを見つけると検索は中止されます。エンジンはこのロケーターファイルがゲートウェイエンジンを指定しているものと見なします。

ほかのロケーターファイルと同様、リダイレクトロケーターファイルは普通のテキストファイルです。リダイレクトロケーターファイルは手作業でもプログラムからでも作成することができます。リダイレクトロケーターファイルには読み取り専用フラグを設定しておかないと、そのディレクトリにあるデータファイルに最初にアクセスを試みたエンジンによって上書きされてしまいます。

2 完了時にファイルをどこに保存するかを決定します。別のロケーターファイルにリダイレクトしようとするデータファイルと同じディレクトリにファイルを保存します。

たとえば、C:\data にあるデータファイルが、確実にほかのデータファイルと同じゲートウェイエンジンによってアクセスされるようにするには、C:\data を忘れないようにしておきます。

3 => と次のロケーターファイルのパス名を入力します。前の手順の例で続けると、C:\data にある現在のデータファイルが、C:\moredata にあるロケーターファイルで指定されたゲートウェイエンジンに属するようにしたい場合、次のように入力します。

最初のケースでは現在のディレクトリからの相対パスを指定しています。2 番目のケースは現在のドライブからの絶対パスを指定しています。この例の場合では、両方とも同じ目的のディレクトリを解決することができます。

メモ：リダイレクトロケーターファイルでは相対パス（ .\ または ..\ で始まる）を使用し、同じデータにアクセスするすべてのワークステーションで同じ共有名を使用することを強くお勧めします。この 2 つの忠告に従えば、マップドライブでのネットワークパス名の解決で起こるエラーを防ぐことができます。

Windows でファイルを読み取り専用にするには、Windows エクスプローラーでファイルアイコンを右クリックして［プロパティ］ダイアログボックスを使用するか、［プログラム］の DOS セッションかプログラムで ATTRIB コマンドを使用します。

1 手作業または Gateway Locator プログラムを使用して、リダイレクトしない読み取り専用の（固定）ロケーターファイルを作成します。ゲートウェイとして使用するワークグループエンジンを指定する必要があります。

たとえば、ロケーターファイルに workgroup1 というコンピューター名をゲートウェイエンジンとして指定し、ファイルが C:\DATA\DB1 にあるとします。

2 前の手順で指定したゲートウェイエンジンを使用しようとする、その他のデータディレクトリごとに、リダイレクトロケーターファイルを作成する必要があります。各リダイレクトロケーターファイルは前の手順で作成したファイルを示す必要があります。

これにより、このファイルを読み取ったエンジンはすべて相対パスに従って、指定された C:\DATA\DB1 で別のロケーターファイルを検索します。この場合、指定したディレクトリには workgroup1 をゲートウェイコンピューターとして挙げているロケーターファイルがあります。

この場合、リダイレクト階層内にあるデータファイルにどのエンジンもアクセスしていなければ、目的のディレクトリにはロケーターファイルがないということを覚えておいてください。この状態は正常です。動的ロケーターファイルはエンジンの最初のデータアクセスによって各セッションに作成され、最後のユーザーセッションが終了したときに削除されます。ロケーターファイルが存在しないデータディレクトリを示すリダイレクトロケーターファイルを持つことは問題ありません。この場合、データファイルを最初に開いたエンジンがロケーターファイルを作成します。

図 4 に示したロケーターファイルの例を使用すると、左側のリダイレクトロケーターファイルはデータベースエンジンに 1 つ上のディレクトリに行き、そのサブディレクトリの newdir でデフォルト名（~PVSW~.LOC）を持つ別のロケーターファイルを探すように指示しています。今度は、このロケーターファイルが ntserver1 という名前のコンピューター上にあるワークグループエンジンがゲートウェイエンジンであることを指定します。その結果、mydir ディレクトリにあるデータファイルにアクセスするために、ntserver1 にあるデータベースエンジンが使用されます。