Pervasive Software Pervasive.SQL 2000 ワークグループ版の理解を深めるために − 1 - Pervasive Software 目次 概 略 ......................................................... 3 主なメリット .................................................. 3 どのような場合、 ワ ー ク グ ル ー プエ ン ジ ン を 使 用 す る メ リ ッ ト が あ る の か ？ 複 数 エ ン ジ ン で の フ ァ イ ル 共 有( M E F S ) .......................3 ..............................................3 M E F Sを 置 き 換 え た 理 由 １ （ パ フ ォ ー マ ン ス の 向 上 ）. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 M E F Sを 置 き 換 え た 理 由 ２（ デ ー タ ベ ー ス の 信 頼 性 の 向 上 ） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 ワークグループ エンジンの特徴 .................................... 4 ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 OS レ ベ ル の セ キ ュ リ テ ィ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 ユーザ カウント ............................................................. 5 ゲートウェイ機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 GatewayLocator ユ ー テ ィ リ テ ィ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 ゲートウェイMicroKernel エンジンの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 M i c r o K e r n e lル ー タ ー の 判 断 ア ル ゴ リ ズ ム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ワークグループの設定 ........................................... 7 推奨されるネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 推奨されないネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ワークグループ エンジンとサーバエンジンの比較 ...................... 8 何が違うのか？ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 何が同じなのか？ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 トラブルシューティング .......................................... 9 最初の接続における遅延 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 ス テ ー タ ス 116 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 バ ー ジ ョ ン6.15か ら の マ イ グ レ ー シ ョ ン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 ま と め . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 2 - Pervasive Software 概略 この技術文書は、以下の項目について解説します。 ・ワークグループの主要なメリット ・どのような場合ワークグループ エンジンを使用するメリットがあるのか？ ・重要な機能についての詳細 ・ Pervasive.SQL 2000 ワークグループ環境の最適化およびトラブルシューテ ィングの秘訣 主なメリット Pervasive.SQL 2000 ワークグループ版は、ハイパフォーマンスな性能、信頼性、およびデータ整合性を、ネット ワークサーバが存在しない、もしくは、サーバベースのデータベースエンジンに代替するエンジンを必要とする複数 ユーザ環境に対し提供されています。 このエンジンは、サーバエンジンと同等のアーキテクチャーを持つため、他の （サーバ）エンジンで提供されるものと同範囲のトランザクショナルおよびリレーショナル・インターフェイス機能 を有しています。また、すべての P e r v a s i v e . S Q L エンジンのように、リコンパイルを必要とすることなく既存の Btrieve アプリケーションと完全な互換性を保っています。 どのような場合、 ワークグループ エンジンを使用するメリットがあるのか？ ワークグループ エンジンに対し、推奨される三つの環境があります。 ・データ共有の範囲が限られている場合 ワークグループ エンジンは、同時に 3 ユーザまで接続可能なようにライセンスされており、小規模なクライアン ト‐サーバ環境と同等な機能を持ちます。 ・個々のワークステーションに、データが分散している場合 ワークステーションのトポロジーは、Peer-to-Peer です。Peer-to-Peer のトポロジーは、個々のアプリケーショ ンが、そのデータの殆どをローカルドライブに格納している環境で、他のワークステーションから、そのデータに アクセスが必要な場合や、他のマシンとデータを共有する場合に使用されます。 ・MicroKernel エンジンをインストールしていないファイル共有サーバに、 データを格納する必要がある場合 このケースでは、他のコンピュータ上にあるディレクトリ内のファイルを、最初にオープンする MicroKernel が、 そのディレクトリ内の個々のファイルに対しゲートウェイとなります。他のワークステーションは、ゲートウェイ を介して、クライアント‐サーバのように、データにアクセスします。 複数エンジンでのファイル共有 (MEFS) MEFS は、ワークグループ エンジンでデータファイル共有のため、10 年以上使用されてきた技術です。これには、 他のエンジンに対し、個々のエンジンが独立して機能するという論理的なメリットがあります。しかしながら、個々 のエンジンは、OS レベルのロックを使用して、ロックファイル中のバイトをロックすることで、自身の操作とファイ ルを共有するその他すべてのエンジンとの同期をとる必要がありました。弊社は、いくつかの固有問題により、MEFS 技術を継続しないことを選択しました。例えば、MEFS では、複数のデータベースエンジンによりデータへのアクセス の同期をとるため、ネットワークトラフィックに大きな負荷がかかります。MEFSはまた、ネットワーク上で、他のエ ンジンが素早く変更箇所にアクセスするためには、変更をディスクに保存する必要があり、そのため MicroKernel の キャッシュは、十分に活用されません。 MEFSを置き換えた理由１（パフォーマンスの向上） ワークグループ エンジンのパフォーマンスは、MEFS を使用する 6.15 のワークステーション エンジンと比較し、 飛躍的に向上しています。新しいワークグループのソリューションは、一度に一つのエンジンのみがファイルをオー プンするように Pervasive のクライアント‐サーバの技術を導入しています。複数のエンジンにより共有されたファ − 3 - Pervasive Software イルに対するオペレーションの変更は、100 倍以上速くなりえます。単一のエンジンでのみデータにアクセスするた め、ファイルに対し度重なるチェックポイント設置の必要がないうえ、MicroKernel のキャッシュの活用を最適に出 来ます。ページがキャッシュにより長く残されるため、ディスクに書き込む前に、ページを複数回変更できるように なります。ディスク I/O は格段に軽減され、データ不整合の可能性も減少します。 上記のチャートは、Pentium 333 Mhzのワークステーションを使用して 10 万行のデータベースに対し行われたTPCB ベンチマークテストの結果を示しています。TPC-B は、データベースエンジンが、データベースをどの位速く更新出 来るかを測る集中変更テストです。TPS は、Transactions Per Second の頭文字です。TCP-B テストの、個々のトラ ンザクションは、一つの行の挿入および三つの行の更新からなっています。表から、一つのクライアントで MEFSを実 行している Btrieve 6.15 ワークステーションのパフォーマンスが、Pervasive.SQL 2000 と同じであることが見てと れます。しかしながら、データが共有されるとMEFS のパフォーマンスは急激に落ち、低いレベルにとどまります。パ フォーマンスは、またコンピュータの性能により違います。ファイルサーバは、ロックレンジが使用可能であれば、 取得した最初のリクエストをロックします。よって、MEFS環境によるロックの配分は、時間に非常に依存しています。 ワークステーションは、テストのすべてを実行している間に、時折ファイルのロックアウトを起こします。この チャートは、データ共有のためのクライアント‐サーバ技術の優位性を示しており、なぜ、それを弊社ワークグルー プ ソリューションで使用したのかをご理解頂けるものと思います。 MEFSを置き換えた理由２（データベースの信頼性の向上） MEFS では、他のエンジンへアクセスを提供するべくデータベースページが変更されるとすぐに、データベースペー ジがファイルに書き込まれるため、データベースの変更を失う可能性があります。これは、非常に多くのデータペー ジが、ネットワークを介し、エンジンとデータファイルの間を行き来することを意味し、それらのページに対しての 不整合の確率を高めてしまいます。 ワークグループ エンジンの特徴 パーベイシブ・ソフトウェアは、ワークグループ エンジンの作成にあたり、以下の特徴をシングルユーザ エン ジンに対し付加しました。 1.NetBIOS - パーベイシブ ネットワークサービス層。Windows 95 または 98 上では、クライアントのリクエスタと MicroKernel データベースエンジン通信 サーバ間の通信プロトコルとして、NetBIOS が使用可能です。 2. サーバエンジンのように、User Count Manager がリモート接続を監視出来ます。 3. リモートファイルに対しゲートウェイ エンジンとなることが可能で、クラ イアントリクエスタがゲートウェイを探す機能を持ちます。 Pervasive.SQL 2000 ワークグループ = シングルユーザ ワークステーション エンジン + NetBIOS でのネットワーク - 4 - Pervasive Software + ユーザカウント マネージャ + ゲートウェイ サポート ネットワーク サーバとワークグループ製品の両方が、同じネットワーク コンポーネントと供に出荷されています。ですから、ワー クグループ エンジンをサーバにアップグレードすることが可能です。クライアント側のリクエスタは、どちらのタイ プのエンジンにも接続可能です。 NetBIOS パーベイシブ ネットワークサービス層は、以前にサポートされていたプロトコルやメソッドに加え、NetBIOS を使 用してのネットワーク上でのエンジンの検索を可能にしました。ルーターは、以下のテクニックを使用し、ネットワー ク上の MicroKernel を検索します。 ・Windows NT MicroKernel により作成される名前付きパイプ ・DNS (Dynamic Name Service for TCP/IP) ・NDS (NetWare ディレクトリ サービス) ・NetWare バインダリ NetBIOS と DNS プロトコルを、ワークグループ エンジンに接続するために使用出来ます。Windows NT 上のサーバ エンジンは、名前付きパイプで自身を公示するため、NetBIOS は必要ありません。Windows 95 と 98 上では、SPX が使 用出来ますが、Microsoft Windows で使用される唯一のプロトコルにはなり得ません。Windows では、NetBIOS は、SPX アドレスを解決するため SPX/IPX にバインドされている必要があります。一度クライアントリクエスタが、IP、SPX、 または NetBEUI のアドレスを見つけると、そのトランスファー プロトコルで MicroKernel エンジンに接続します。 OSレベルのセキュリティ NetWare と Windows NT 上において、MicroKernel は、クライアント リクエスタからユーザネームを取得しファイ ルアクセスの権限を判断するため、あたかもそのユーザように振舞います。MicroKernel は、クライアントがファイル をオープンする度、それらの権限を行使します。この機能は、Windows 95 と 98 上では提供されていません。そのた め、ワークグループ エンジンのセキュリティは、ログインユーザネームに割り当てられた権限に基づいており、OS レベルのファイルセキュリティは強制しません。 ワークグループ エンジンが一般的である小規模なオフィスでは、この特殊なセキュリティが無いことは、利点であ ると考えることが出来ます。なぜなら、そのようなオフィスは、ネットワークのエキスパートを持たず、データにア クセスするための障壁が少なければ少ない程、データアクセスが簡単になるからです。しかしながら、ファイルレベ ル・セキュリティが、Pervasive.SQL 2000 の唯一の認証・承認機能ではありません。ワークグループ エンジンは、 Btrieve のオーナや SQL のログイン・セキュリティを含む、提供された他のセキュリティ機能も続けて行使します。 ユーザ カウント Pervasive.SQL 2000 のワークグループ版は、データベースに対し、3 ユーザの同時接続を許可するようライセンス されています。このライセンスは、インストールの際、個々のワークグループ エンジンに適用され、リモート接続 数を 3 に限定します。お気づきかもしれませんが、ローカルアプリケーションからエンジンへの接続は、ユーザ カウ ントに数えられません。これは、すべての Pervasive MicroKernel エンジンについて当てはまります。3 つのクライ アント・コンピュータがワークグループ エンジンに接続している状態で、もう一つの“クライアント”を、データ を共有しているコンピュータ上で、技術的に起動させることが出来ます。3ユーザのワークグループ エンジンに対し、 4 つのアプリケーションが同じデータにアクセス可能ということになります。 それでは、なぜワークグループがデータ共有を 3ユーザにのみライセンスしているのに、4つのクライアントで同時 にデータ共有が可能なのでしょうか？ネットワーク ファイルサーバにデータを格納し、アプリケーションを 3つのク ライアント コンピュータから実行したい場合、ワークグループ エンジンをネットワーク ファイルサーバにインス トールし、高パフォーマンスの共有データアクセスを提供するサーバエンジンのように稼動させることが出来ます。こ の付加的な接続は、ワークグループの設定に柔軟性を持たせるために存在し、データに同時に 4 つの Pervasive.SQL 2000 クライアント アプリケーションをアクセスさせるために存在する訳ではありません。 もし 4 台以上のコンピュータで同時にデータを共有したい場合、ユーザ カウントライセンスを追加して下さい。追 加のワークグループ ユーザカウントは、エンジンが起動中にも追加でき、エンジンを停止することなく、新規のユー − 5 - Pervasive Software ザカウントが登録されます。この機能は、サーバエンジンにも搭載されています。また、個々のユーザカウント アッ プグレードは、ワークグループ エンジンを1 台以上のコンピュータにインストールすることを許可しているので、結 果としてワークグループ内のコンピュータの台数を増やすことが出来ます。それから、ユーザ カウントをワークグ ループ内の個々のエンジンに対し、ユーザカウントの追加が出来ます。 ユーザ カウントの追加は、ユーティリティを使用し簡単に行うことが出来ます。このユーティリティは、フロッ ピーディスクで供給されるユーザ カウントキーと呼ばれる小さなファイルを参照します。これは、コマンドライン・ モードのユーティリティを呼び出すことにより、プログラム的にも実行可能です。 ゲートウェイ機能 ゲートウェイ機能は、ワークステーションにリモート コンピュータへのアクセスを提供するように設計されてい ます。そのためには MicroKernel が、データファイルのディレクトリにロケーターファイルを作成して、自身をゲー トウェイとして認識する必要があります。その後、MicroKernel インターフェイスが、リクエストをどこに送るのか を特定します。ゲートウェイ コンピュータは、ファイルに対しての「読み込み」と「書き込み」のプロセスにおい て、ホスティング サーバエンジンのように稼動します。ファイルに対しページの書き込みを必要とするその他のエ ンジンが存在しないため、ゲートウェイ エンジンはキャッシュにより長くページを保持することが可能です。これ により、ゲートウェイ エンジンはキャッシュを最大限に活用します。 MicroKernel がディレクトリ中の最後のファイルをクローズする時、ルーターがロケーター ファイルを開放し、削 除します。そのクローズしたファイルをオープンする次のエンジンが、新しいゲートウェイになります。このことに より、コンピュータからコンピュータへ、ゲートウェイの割り当てを動的に、また自動的に行うことが出来ます。 ロケーターファイルは、ゲートウェイ コンピュータのネットワークネームを含むシンプルなテキストファイルで す。ロケーターファイルは、常に " PVSW .LOC" の形式で名前付けがなされ、MicroKernel は、開かれたファイルが あるディレクトリにロケーターファイルを作成します。よって、MicroKernel エンジンは、そのディレクトリ中のす べてのファイルにオーナーシップを付与します。ゲートウェイの割り当ては、このファイルの属性をリードオンリー にすることで、永続的なものに出来ます。 ATTRIB コマンドで、以下のように実行するとファイルの属性を変えられます。 C:\Data>ATTRIB +R ~PVSW~.LOC あるいは、以下に説明する Gateway Locator ユーティリティで、変更を永続的なものに出来ます。 もし、ワークグループにおいて永続的に割り当てられたゲートウェイと複数のコンピュータを使用する場合、ゲー トウェイの役割を果たすワークグループエンジンの代わりに、サーバエンジンをインストールすることを望まれるか も知れません。これは、Windows NT 版のサーバエンジンが、ゲートウェイとしても機能するため可能です。 Gateway Locator ユーティリティ Pervasive.SQLワークグループ エンジンは、ロケーター ファイルの内容を表示・変更するための非常に簡単なユー ティリティを保持しています。ただディレクトリを選択するだけで、現在、アクティブのゲートウェイを調べること ができます。もし、ディレクトリ中のファイルに対し永続的なゲートウェイを割り当てたいなら、変更ボタンをクリッ クして下さい。永続的なゲートウェイの割り当てを作成したり、削除したり出来ます。 ゲートウェイMicroKernelエンジンの設定 もし、MicroKernel エンジンをホスト（インストール）していないコンピュータ上にデータを保存する場合、この データに対してゲートウェイとして機能する他のコンピュータを選択する必要があります。どのワークグループのコ ンピュータからも Gateway Locator ユーティリティを使用して、選択したコンピュータを永続的なゲートウェイと して割り当てられます。もし、ゲートウェイ コンピュータを前もって割り当てない場合、日々、指定されたデータ ファイルを初めに開くコンピュータがその都度ゲートウェイとなります。そのディレクトリ中の最初のファイルがク ローズされるまで、そのコンピュータがゲートウェイとなります。その後、次のコンピュータがそれらのファイルに 再びアクセスした場合、そのコンピュータが新たなゲートウェイになります。 弊社では、コンピュータ間でゲートウェイを絶えず変更するより、永続的なゲートウェイを割り当てておくことを お勧めします。浮動ゲートウェイのトポロジーは、ワークグループ エンジンがキャッシュにあるゲートウェイ ア - 6 - Pervasive Software ドレスに接続出来なかった際、どのコンピュータが現在のゲートウェイであるか再び探す必要があるため、不意の遅延 が起こる場合が有り得ます。 MicroKernelルーターの判断アルゴリズム クライアント側の MicroKernel ルーターは、いずれのネットワーク ディレクトリにおいても、どのエンジンが現在 ファイルを所有しているか判断出来るよう機能強化されています。使用されているどこにリクエストを送るかを探る決 定アルゴリズムは、以下の優先順位によって行われています。 プライオリティ 1 - ファイルサーバ上で起動しているエンジンがある。 プライオリティ 2 - ローカルエンジンが、そのファイルをオープン出来る。 プライオリティ 3 - ゲートウェイ エンジンが、ディレクトリを所有している。 最初のプライオリティとして、ワークグループの環境においても、クライアント側のルーターが、ファイルサーバ上 でエンジンが稼動していると常に推測しています。これは、ディスク I/Oがより速い場合、どのデータベースエンジン もパフォーマンスが良くなるため、第一優先とすべきです。 パーベイシブ ネットワーク サービス層は、リモート MicroKernel エンジンに接続するために多数の異なる方法を 使用することから、アクティブな MicroKernel エンジンを持たないファイル サーバ上のファイルを開くためのプロセ スで、最初のトライアルで時間に遅延が生じることがあります。 しかしながら、その後、ルーターがそのコンピュータにアクティブなエンジンがないことを記憶しているので、その 接続は再試行されません。最初のプライオリティが失敗すると、ルーターは、ローカルエンジンが、そのファイルを開 くことが出来るものと推測します。ローカルエンジンは、初めに新規のロケーターファイルを作成し、オーナーシップ を取得しようと試みます。 しかしながら、もしディレクトリが既に他のMicroKernel エンジンで占有されている場合、ローカルエンジンからス テータス 116 が返されます。 「このファイルは、ゲートウェイとして機能している別の MicroKernel エンジンが所有 しています。」 最後に、ルーターが 3 番目のプライオリティを試します。ロケーターファイルを開き、だれの MicroKernel がゲート ウェイとして機能しているか調べるためコンピュータの名前を読みます。その後、そのエンジン（サーバまたは、ワー クグループ）に、リクエストを送ります。MicroKernelエンジンからステータス116 が返らない限り、ルーターがロケー ターファイルを読みにいくことはありません。よって、ゲートウェイの機能を使用するために、ローカルエンジンをイ ンストールしてある必要があります。ローカルエンジンは、ロケーター ファイルを読みに行きません。ゲートウェイ が見つからないため、アプリケーションがステータス116 を返します。 ワークグループの設定 ワークグループ エンジンの推奨トポロジーの要約を示します。 推奨されるネットワークトポロジー 第一は、個々のファイルがローカル MicroKernel エンジンによって共有される peer-to-peer のトポロジーです。こ れは、ファイルサーバ上で、エンジンが常に起動状態でなければならないことを意味します。常に起動状態にあるため には、プログラムのスタートアップのフォルダにワークグループ エンジンを登録しておくことをお勧めします。二番 目に推奨されるトポロジーは、先に説明したゲートウェイトポロジーです。ワークグループ エンジンは、ゲートウェ イとなる場合や、ローカルに共有しているファイルがある場合、前もって起動している必要があります。そうでない場 合は、エンジンが前もって起動している必要はありません。エンジンは、必要時にルーターにより自動的に起動されま す。 もし、一つのワークステーションに対し永続的なゲートウェイを設定した場合、MicroKernel が前もって起動してい る必要があります。 推奨されないネットワークトポロジー 浮動ゲートウェイを使用した peer-to-peer の形態は、推奨されないトポロジーです。ワークグループ エンジン版 の Pervasive.SQL 2000 は、コンピュータからコンピュータへゲートウェイを動的に変更出来るように設計されていま す。しかしながら、このトポロジーでは、ファイルを開く際、頻繁に遅延が生じる可能性があります。更に、ローカル のデータファイルを開くため、ルーターがリクエストをリモートエンジンに送る時、パフォーマンスに影響します。こ れは、以下の二つの方法で回避出来ます。 − 7 - Pervasive Software ・ユーザがログオン時にエンジンが稼動するように、Pervasive.SQL 2000 ワークグループの ショートカット アイコンをスタートアップ フォルダに置きます。 ・永続的なゲートウェイをローカル コンピュータに作成出来ます。これにより、エンジンが 起動していない時、他のコンピュータがゲートウェイになることを回避します。 ワークグループ エンジンとサーバエンジンの比較 何が違うのか？ 以下のリストは、サーバエンジンとワークグループ エンジンの差異のハイライトです。 機能 プラットフォーム ユーザ インターフェイス ネットワーク通信 認証 ゲートウェイ サポート ユーザ カウント ODBC クライアント/サーバ レプリケーション パフォーマンス 環境の安定 サーバ ワークグループ NetWare、Solaris、Linux版のエンジ ンは、サーバエンジンのみ供給されて います。（Solaris、Linuxは英語版 32-bit Windowsプラットフォームで稼動 のみ） します Windowsサーバエンジンは、NTワーク ステーションまたはNTサーバが必要で す。 インターフェイスのためトレイにアイコン を表示する通常のプロセスとして起動しま Windows NTサーバエンジンがサービス す。共有するためのデータがローカルにあ として起動します。 る場合、スタートアップのフォルダに ショートカットアイコンを置いておく必要 があります。 Windows NTサーバエンジンは、OSレ Windows 95/98は、名前付きパイプの作成 ベルのファイル セキュリティと接続 を許可しないため、ワークグループ エンジ 確立のため、名前付きパイプを使用し ンは、接続プロトコルとしてNetBIOSが利 ています。 用可能です。 前に説明したように、ワークグループ エン ジンは独自にユーザ認証をチェックしませ ん。ネットワーク上にコンピュータが見え Pervasive 2000サーバエンジンは、 る場合、ワークグループ エンジンでデータ そのOSでファイル アクセス権の設定 にアクセス出来ます。この緩いセキュリ を強制します。 ティは、セキュリティがあまり問題とされ ず、使い易さが先行して求められるスモー ルオフィスの環境に適合しています。 ワークグループ エンジンが日々、動的に ゲートウェイの所有先を変更できるよう 適応外 に、ロケーターファイルをファイルを開い た先すべてに作成します。 サーバエンジンは、同時接続ユーザ数 同時接続ユーザ数3から始まります。 が最低10から始まります。 Pervasive.SQL 2000 ODBC エンジンの サーバコンポーネントであるSQL接続マ ニュージャを含んでいません。サーバコン ポーネントは、ODBCエンジンがリモートの ODBCクライアントからリクエストを受け取 ることが出来るようにするものです。結果 として、Btrieveリクエストだけがネット ODBCサーバ コンポーネントと供に出 ワーク上を行き交う唯一のものとなりま 荷されます。 す。 ファットクライアント アプローチは、簡単 なクエリーやトランザクションにおいて、 完全なClient/Server ODBCと比較し高速 な場合がありますが、多数のレコードが読 まれ数少ない行が結合され結果セットを返 す複雑なクエリーを実行する場合、より遅 くなる場合があります。 レプリケーションは、サーバとワーク ワークグループ エンジンでは、レプリケー ステーション エンジンと供に使用す ションをサポートしていません。 るようにデザインされています サーバエンジンは、通常、ワークグ ループ エンジンより重い負荷を処理 するようにデザインされています。 Pervasive.SQL 2000クライアント/サーバ 製品は、重要なデータのやり取りに対し、 最も安定した環境を提供します。スピード やOSが異なるコンピュータに接続している 複数のルーターが存在する雑多のネット ワーク環境では、現在ゲートウェイである コンピュータを見つけ出すプロセスにリス クが伴います。 - 8 - Pervasive Software 何が同じなのか？ Pervasive.SQL 2000 ワークグループとサーバエンジンは、共通 Pervasive.SQL 2000 コードベースのテクノロジー を進歩・発展させています。共通コードベースは、エンジンの安定性、信頼性を保証するだけでなく、いくつかの異 なるセットの設定パラメタの管理、作成も容易にします。エンジンは、同じキャッシュ、クライアント、ファイル、 カーソル、ロック管理を持ちます。また、同一の完全なトランザクショナル API を持ちます。 エンジンは、一貫性保守に関し、トランザクション ロギング、アーカイブ ロギング、コンテニュアス オペレー ション、その他の機能を持っています。サーバとワークグループ エンジンは、同じODBC エンジンを共有します。ODBC エンジンは、ファイル、ユーザ、ODBC データソース アドミニストレータで設定されるシステムデータソースに依存 しています。同じ Pervasive Control Center (PCC)とすべての関連ユーティリティは、両製品に含まれています。 PCC は、以下のものを含む共通入門ツールです。 ・SQL Data Manager ・設定ユーティリティ ・Pervasive モニター ユーティリティ 設定ユーティリティとPervasive Monitorは、ローカルエンジンと同様にリモートのワークグループとワークステー ション エンジンのモニタリングと設定を行えます。 トラブルシューティング 問題が生じた場合、まず最初に最新のサービスパックを充てアップグレードされることをお勧めします。 最初の接続における遅延 最初のオープンリクエストが発せられた際、常に遅延が起こる場合、これを回避するためのいくつかのテクニック があります。 ・以下のコマンドを使用して、スタートアップ フォルダにエンジンのアイコンを作成し、ファイルサーバ上で MciroKernel エンジンが起動することを確実にして下さい。 C:\Pvsw\Bin\W3dbsmgr.exe -BTRV ・ Windows 95 と Windows 98 上の、もう一つのオプションは、以下のレジストリキーを追加することです。 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices] "Pervasive.SQL 2000 Workgroup" = "C:\\Pvsw\\Bin\\W3dbsmgr.exe -BTRV" このレジストリキーは、エンジンを、どのログオンよりも先にスタートします。この場合、トレイアイコンは表示 されません。ですから、その時点のエンジンの状態を示す目に見えるインターフェイスはありません。 もし、ファイルサーバ上でエンジンが起動していない環境で、ゲートウェイ トポロジーを利用している場合、最 初の接続にかかる時間の遅延が、重要な問題となってきます。以下のことが、対策として挙げられます。 ・ネットワークで使用していないプロトコルに対し試行しないようにするため、クライアント設定でサポートプロ トコルを絞る。例えば、NetWare 版の MicroKernel がシステム上にない場合、ほとんどワークグループ トポロジーに おいてそうなのですが、SPX/IPX をサポートプロトコルから外しても大丈夫です。 ステータス 116 ステータス 116は、新規に追加された MicroKernelのステータスコードです。このステータスコードは、ゲートウェ イとして機能している他の MicroKernelエンジンにより、ファイルが使用されていることを示唆しています。もし、ア プリケーションにステータス116が返ったなら、MicroKernelルーターがロケーター ファイルを読めるが、ゲートウェ イ コンピュータ上のエンジンに接続出来ないことを意味します。 この問題を解決するには、Gateway Locator により、ゲートウェイを識別します。InstallScout またはSmart Scout ユーティリティを使用し、そのコンピュータに接続します。この診断ユーティリティは、問題を切り分けるために貴 重な情報を提供します。 メモ: 上記のケースは、２台のコンピュータがルーターにより分離されていて、両方のコンピュータからファイ ルサーバは見えるが、お互いが見えない場合に起こり得ます。 − 9 - Pervasive Software バージョン6.15からのマイグレーション Pervasive.SQL 2000 ワークグループ リリースは、もちろんリコンパイルの必要なくすべての既存の Btreive アプ リケーションと互換性を持っています。しかしながら、もしアプリケーションをアップグレードされる場合、現在開 発キット（SDK ）で提供されている他の数多くのインターフェイスを利用することが可能です。詳しくは、「Btrieve 6.15 から Pervasive.SQL 7 または Pervasive.SQL 2000 へのアップグレード」の白書をご覧下さい。 まとめ ワークグループ リリースは、クライアント・サーバ技術を使用し、ネットワーク上のどこにあるデータに対して も接続する、低コスト、データベース管理者不要の、自動チューニングエンジンを提供します。より確かなデータの 信頼性はもとより、MEFS ベースのエンジンより高速なファイル共有を提供します。大規模クライアント・サーバ環境 ではなく、小さなオフィスやワークグループにおいてのニーズを満たすようデザインされています。 - 10 -
© Copyright 2024 Paperzz
