ワークグループ エンジンの詳細
 
このページをシェアする                  
ワークグループ エンジンの詳細
ワークグループ エンジンの技術的な詳細および高度な処理
この章では、ワークグループ エンジンの最も特徴的な機能を利用する方法について説明します。
ネットワーク
サーバーとワークグループの技術的な相違
ワークグループ の問題のトラブルシューティング
リダイレクト ロケーター ファイルの作成
ネットワーク
サーバーおよびワークグループ製品には同一のネットワーク コンポーネントが含まれています。 したがって、ワークグループ エンジンをサーバー エンジンにアップグレードすることが可能です。 クライアント側のリクエスターはいずれのタイプのエンジンにも接続することができます。
NetBIOS
PSQL ネットワーク サービス レイヤーは、以前サポートされていた名前付きパイプ、DNS および NDS などのプロトコルと同様に、NetBIOS を使用してネットワーク上でエンジンを検索します。NetBIOS および DNS プロトコルは、ワークグループ エンジンと交信するのに使用することができます。Windows 上のサーバー エンジンは名前付きパイプを使用して自身をアドバタイズするため、NetBIOS は必要ありません。
クライアントのリクエスターが IP、SPX、または NetBEUI アドレスを見つけると、その転送プロトコルを使用して MicroKernel エンジンに接続を確立しようとします。
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 セキュリティ ポリシー
サーバー エンジンでは、オペレーティング システムにおけるファイルのアクセス許可を適用します。ワークグループ エンジンは自身でユーザーの認証を行いません。ワークグループ エンジンがネットワーク上のコンピューターにアクセスすることができれば、そのデータに到達できます。この緩和されたセキュリティは、セキュリティよりも使いやすさを優先する小規模のオフィスを対象としています。
ワークグループ エンジン用のオペレーティング システム認証がないということは、Btrieve の "混合" セキュリティ ポリシーと "クラシック" セキュリティ ポリシーが同じであることを意味します。セキュリティ ポリシーの違いは、サーバー エンジンとワークグループ エンジン間の動作の違いです。詳細については、PSQL セキュリティを参照してください。
ゲートウェイのサポート
ワークグループ エンジンは、ローカル、リモート共にファイルを開いたすべての場所にロケーター ファイルを作成することにより、ワークグループ エンジンがゲートウェイのオーナーシップを絶えず動的に適合できるようにします。デフォルトで、ワークグループ エンジンはほかのコンピューターやネットワーク デバイスで認証されるユーザー ID でも実行されます。このため、ワークグループ エンジンはゲートウェイ環境での使用に最適です。『Getting Started with PSQL』のゲートウェイ構成のセットアップを参照してください。
サーバー エンジンは必ずしもゲートウェイ ロケーター ファイルを作成する、または引き受けるわけではありません。このため、サーバー エンジンをゲートウェイ環境で使用するような設計やテストを行っていません。そのため、ワークグループ環境でワークグループ エンジンに代わってサーバー エンジンをゲートウェイとすることはサポートしていません。
非同期 I/O
Windows 版のサーバー エンジンは非同期 I/O を使用します。また、データベース ページの書き込みの結合はサーバー エンジンでのみ行われます。これらの機能によって、I/O の負荷が高いときは、ワークグループ エンジンに比べサーバー エンジンが大きなパフォーマンスの利点を得ることができます。
デフォルトの設定
いくつかのデータベース設定(キャッシュ サイズやシステム キャッシュなど)のデフォルト値は、サーバー エンジンとワークグループ エンジンでそれぞれ異なります。ワークグループ エンジン設定用のデフォルト値は、システム リソースの消費をより抑えるよう設定されます。設定リファレンスを参照してください。
ライセンス モデル
PSQL Server および PSQL Workgroup ではユーザー カウント ライセンス モデルを使用します。PSQL Vx Server では容量ベース ライセンス モデルを使用します。『PSQL User's Guide』のライセンス モデルを参照してください。
ワークグループ の問題のトラブルシューティング
このセクションでは、ワークグループ環境での問題の解決に役立つヒントを提供します。
最初の接続での待ち時間
最初のファイル オープン リクエストが発行されるときに何度も遅延が起きるのであれば、次の方法が役に立つかどうか調べてください。
可能であれば、データが存在する場所でエンジンが実行されるようにしてください。
ファイル オープンのリクエストをどこに送るかを決定するとき、クライアントが最優先で行う方法は、データが存在する同じマシン上のエンジンに接続することです。ワークグループ エンジンがアプリケーションとして実行されるのを確実にするため、次のコマンドを使用してエンジンのアイコンをスタートアップ フォルダーに入れます。
W3dbsmgr.exe
もう 1 つの方法としては、ワークグループ エンジンをサービスとしてインストールします。『Getting Started with PSQL』を参照してください。また、PSQL ファイルのデフォルトの場所については、『Getting Started with PSQL』のPSQL ファイルはどこにインストールされますか?を参照してください。
ゲートウェイ トポロジを実行している場合
データが存在する場所でエンジンを実行できない場合、最初の接続の待ち時間はより重要な問題になります。試してみることがいくつかあります。
1 クライアントの設定で[サポート プロトコル]を減らし、ネットワークで使用されていないプロトコルの使用が試みられないようにします。
2 ゲートウェイ一貫性保持を使用します。ゲートウェイ一貫性保持はクライアントの設定で、ゲートウェイ環境で最初の接続を確立するときの待ち時間をほとんどなくすことができます。[ゲートウェイ一貫性保持]がオンに設定されていると、クライアント ルーターがエンジンの実行されていないコンピューター名をレジストリに書き込むようにします。接続に失敗すると、ルーターはこのサーバー名を実行中のみ保存するのではなく、レジストリに保存します。次回アプリケーションが起動したとき、データのある場所のエンジンへの接続は試行されません。 直ちに現在のゲートウェイを決定する次の段階に進みます。
この設定は PCC で切り替えることができます。PCC の PSQL エクスプローラーで[ローカル クライアント]ノードを展開し、[MicroKernel ルーター]を右クリックします。[プロパティ]をクリックし、[アクセス]を選択します。[ゲートウェイ一貫性保持]オプションをクリックしてオンに設定し(チェック マークは、その設定が「オン」であることを表します)、[OK]をクリックします。
メモ:この機能はトポロジを固定するため、デフォルトではオフになっています。データが存在する場所にサーバー エンジンまたはワークグループ エンジンを追加した場合、この設定をオンにした各クライアントでオフに戻す必要があります。この設定をオフに戻すと、エンジンが実行されていないコンピューターのレジストリを消去するので、その後すぐにオンにすると新しいトポロジに基づいた新しいリストが生成されます。
ステータス コード 116
ステータス 116 は MicroKernel のステータス コードで、ゲートウェイとして動作する別の MicroKernel エンジンによってファイルが使用されていることを示します。アプリケーションがステータス コード 116 を受け取った場合、MicroKernel ルーターはロケーター ファイルを読むことができたけれどもゲートウェイ コンピューター上で実行されているエンジンと交信できなかったことを示します。
最初にしなければならないことは、ゲートウェイがどれかを見極めることです。この作業は Gateway Locator ユーティリティを使用して行うことができます。
次に PSA ネットワーク テストを使用してそのコンピューターに接続してみます。PSA は問題を分離するための役に立つ情報を提供します。
これが起こる 1 つの状況は、2 つのコンピューターがルーターで分けられていて、両方ともファイル サーバーを見ることができるが、互いを見ることができない場合です。
リダイレクト ロケーター ファイルの作成
ゲートウェイ エンジン操作のこの機能は、複数ディレクトリのデータベースのトランザクション アトミシティを保証し、また複数のデータ ディレクトリにわたるゲートウェイ エンジンの名前の変更を容易にします。
PSQL クライアントがリモート データ ファイルにアクセスする際に次の方法を使用することを思い出してください。
1 データ ファイルと同一のコンピューター上でデータベース エンジンに接続を試みます。
2 次に、そのリモート マシンでデータベース エンジンが使用可能でない場合、ローカル エンジンを使用してリモート ディレクトリのオーナーシップをとり、ロケーター ファイルを作成します。ゲートウェイ ロケーター ファイルが既に存在する場合、ローカル エンジンは使用されません。
3 3 番目に、指定されたゲートウェイ エンジンを使用することを試みます。
ゲートウェイ設定は、データ ファイルが存在するコンピューター上に使用可能なデータベース エンジンがない場合にのみ有効になることを覚えておいてください。
この機能により、同一ボリューム上の複数ディレクトリのデータベースのトランザクションの一貫性を保持しながら動的(変動)ゲートウェイ エンジンを使用することができます。この利点は、別のゲートウェイ ロケーター ファイルを指示する新しいゲートウェイ ロケーター ファイルによってもたらされました。新しいタイプはリダイレクト ロケーター ファイルと呼びます。ディレクトリ D のロケーター ファイルを指示するリダイレクト ロケーター ファイルをディレクトリ A、B、C に持つことにより、ディレクトリ D のロケーター ファイルが指定するゲートウェイ エンジンが、ほかのディレクトリにあるデータ ファイルのサービスも確実に提供することができるようになります。
ディレクトリ D のロケーター ファイルが固定ゲートウェイを指定しているか、これらのファイルを最初に開いたエンジンによって動的に作成されるかにかかわらず、このアーキテクチャは指定されたすべてのディレクトリが必ず同一のゲートウェイ エンジンを使用します。同様に、いくつかのディレクトリの固定ゲートウェイを変更しようとする場合、リダイレクト ロケーター ファイルを使用すると、すべてのロケーター ファイルではなく、たった 1 つのロケーター ファイルを変更するだけで済みます。したがって、一定のハード ドライブ上のすべてのデータ ファイルが固定ゲートウェイを指定しているといないにかかわらず、同一ゲートウェイ エンジンを使用するように指定することができます。
リダイレクト ロケーター ファイルの要件
リダイレクト ロケーター ファイルの最初の行は "=>" で始め、その後に必ず同一ドライブ上にある別のロケーター ファイルのパスを指定する必要があります。パス名にはスラッシュおよび円記号の任意の組み合わせを使用することができます。スラッシュはすべてローカル オペレーティング システムの使用するタイプの区切り文字に変換されます。
スラッシュで終わるパスを指定した場合、データベース エンジンはパスの最後にデフォルトのロケーター ファイル名(~PVSW~.LOC)を追加します。指定したパスがスラッシュで終わっていない場合、データベース エンジンはパスにファイル名が含まれているものと見なします。
次の表は、リダイレクト ロケーター ファイルのパスの指定方法の一覧です。
表 29 リダイレクト ロケーター ファイル パスの記述方法
パス
説明
=>\path_name
現在のロケーター ファイルが格納されているルート ドライブからパスを指定します。
=>.\path_name
現在のディレクトリからの相対パスを指定します。
=>..\path_name
現在のディレクトリの親ディレクトリからの相対パスを指定します。
これらのロケーター ファイルに複数レベルのリダイレクトを割り当てることができます。たとえば、最初のロケーター ファイルが 2 番目のロケーター ファイルを指示し、2 番目のロケーター ファイルが 3 番目のロケーター ファイルを指示するという具合です。各ワークグループ エンジンはそれぞれのロケーター ファイルを順に開き、実際のゲートウェイ名を探します。"=>" で始まらないロケーター ファイルを見つけると検索は中止されます。エンジンはこのロケーター ファイルがゲートウェイ エンジンを指定しているものと見なします。
リダイレクト ロケーター ファイルの作成
ほかのロケーター ファイルと同様、リダイレクト ロケーター ファイルは普通のテキスト ファイルです。リダイレクト ロケーター ファイルは手作業でもプログラムからでも作成することができます。リダイレクト ロケーター ファイルには読み取り専用フラグを設定しておかないと、そのディレクトリにあるデータ ファイルに最初にアクセスを試みたエンジンによって上書きされてしまいます。
リダイレクト ロケーター ファイルを作成するには
1 メモ帳またはテキスト エディターを開き、新規テキストファイルを開きます。
2 完了時にファイルをどこに保存するかを決定します。別のロケーター ファイルにリダイレクトしようとするデータ ファイルと同じディレクトリにファイルを保存します。
たとえば、C:\data にあるデータ ファイルが、確実にほかのデータ ファイルと同じゲートウェイ エンジンによってアクセスされるようにするには、C:\data を忘れないようにしておきます。
3 => と次のロケーター ファイルのパス名を入力します。前の手順の例で続けると、C:\data にある現在のデータ ファイルが、C:\moredata にあるロケーター ファイルで指定されたゲートウェイ エンジンに属するようにしたい場合、次のように入力します。
=>..\moredata\ (推奨)または
=>\moredata\ (推奨しません)
最初のケースでは現在のディレクトリからの相対パスを指定しています。2 番目のケースは現在のドライブからの絶対パスを指定しています。この例の場合では、両方とも同じ目的のディレクトリを解決することができます。
メモ:リダイレクト ロケーター ファイルでは相対パス( .\ または ..\ で始まる)を使用し、同じデータにアクセスするすべてのワークステーションで同じ共有名を使用することを強くお勧めします。この 2 つの忠告に従えば、マップ ドライブでのネットワーク パス名の解決で起こるエラーを防ぐことができます。
4 ゲートウェイ エンジンを指定したいデータ ファイルが存在するディレクトリに ~PVSW~.LOC という名前でファイルを保存します。
5 メモ帳またはテキスト エディターを閉じます。
6 このテキスト ファイルに読み取り専用フラグを設定します。
Windows でファイルを読み取り専用にするには、Windows エクスプローラーでファイル アイコンを右クリックして[プロパティ]ダイアログ ボックスを使用するか、[プログラム]の DOS セッションかプログラムで ATTRIB コマンドを使用します。
ATTRIB +R ~PVSW~.LOC
固定ゲートウェイで多数のデータ ディレクトリの同期をとるには
1 手作業または Gateway Locator プログラムを使用して、リダイレクトしない読み取り専用の(固定)ロケーター ファイルを作成します。ゲートウェイとして使用するワークグループ エンジンを指定する必要があります。
たとえば、ロケーター ファイルに workgroup1 というコンピューター名をゲートウェイ エンジンとして指定し、ファイルが C:\DATA\DB1 にあるとします。
2 前の手順で指定したゲートウェイ エンジンを使用しようとする、その他のデータ ディレクトリごとに、リダイレクト ロケーター ファイルを作成する必要があります。各リダイレクト ロケーター ファイルは前の手順で作成したファイルを示す必要があります。
前の例でいうと、C:\DATA\DB2 および C:\DATA\DB3 にあるリダイレクト ロケーター ファイルは次のテキストを含みます。
=>..\DB1\
これにより、このファイルを読み取ったエンジンはすべて相対パスに従って、指定された C:\DATA\DB1 で別のロケーター ファイルを検索します。この場合、指定したディレクトリには workgroup1 をゲートウェイ コンピューターとして挙げているロケーター ファイルがあります。
動的ゲートウェイで多数のデータ ディレクトリの同期をとるには
1 上記の手順に従いますが、手順 1 でロケーター ファイルが固定的に割り当てられないように書き込み可能にするだけです。
この場合、リダイレクト階層内にあるデータ ファイルにどのエンジンもアクセスしていなければ、目的のディレクトリにはロケーター ファイルがないということを覚えておいてください。この状態は正常です。動的ロケーター ファイルはエンジンの最初のデータ アクセスによって各セッションに作成され、最後のユーザー セッションが終了したときに削除されます。ロケーター ファイルが存在しないデータ ディレクトリを示すリダイレクト ロケーター ファイルを持つことは問題ありません。この場合、データ ファイルを最初に開いたエンジンがロケーター ファイルを作成します。
4 に示したロケーター ファイルの例を使用すると、左側のリダイレクト ロケーター ファイルはデータベース エンジンに 1 つ上のディレクトリに行き、そのサブディレクトリの newdir でデフォルト名(~PVSW~.LOC)を持つ別のロケーター ファイルを探すように指示しています。今度は、このロケーター ファイルが ntserver1 という名前のコンピューター上にあるワークグループ エンジンがゲートウェイ エンジンであることを指定します。その結果、mydir ディレクトリにあるデータ ファイルにアクセスするために、ntserver1 にあるデータベース エンジンが使用されます。
図 4 リダイレクト ロケーター ファイルの例