DATABASE Pervsive PSQL Workgroup のリリースについて Pervsive ソフトウェアホワイトペーパー 2006 年 2 月
目次 概要.................................................................................. 3 Workgroup を使用するケース........................................................... 3 MEFS ( マルチエンジンファイル共有 ) と Workgroupアーキテクチャ...................... 3 パフォーマンス..................................................................... 4 信頼性.............................................................................. 5 Workgroup エンジンの機能............................................................. 5 Workgroup ゲートウェイ............................................................. 5.. ゲートウェイの構成............................................................... 5.. 回避すべき構成................................................................... 6.. Workgroup がゲートウェイを識別する方法........................................ 6.. ゲートウェイロケータファイル................................................... 7.. Gtewy Loctor ユーティリティ.................................................... 7.. リダイレクトゲートウェイロケータファイル..................................... 8 License Administrtor.................................................................. 8 NetBIOS を使用したネットワーク.................................................... 9 トラブルシューティングおよび Workgroup の最適化.................................... 9 バージョン 6.15 からの移行........................................................... 10 まとめ............................................................................... 10 付録 A: Workgroup と Server の比較..................................................... 11 付録 B: PERVASIVE PSQL バージョン比較ガイド........................................ 12 連絡先............................................................................... 13 Pervsive PSQL Workgroup のリリースについて
概要 Pervsive PSQL v9 Workgroup エンジン (WGE) は シングルユーザー環境および小規模のマルチユーザー環境に配備されるアプリケーション または Pervsive PSQL データベースエンジンをサポートできないネットワーク環境にとって理想的なソリューションです PSQL Server エンジンと共通のアーキテクチャを共有することにより WGE は完全な機能を備えたエンジンとなり すべての PSQL アプリケーションと完全な互換性を持ちます これには すべての既存 Btrieve 6.15 アプリケーションのサポートも含まれます 本書は PSQL v9 Workgroup エンジンを評価し 前の世代の Btrieve および PSQL との比較を行います これには以下のようなトピックがあります Pervsive PSQL Workgroup エンジンを使用するケース テクノロジの向上 : MEFS と Workgroup Workgroup の重要な機能 Workgroup 環境の最適化およびトラブルシューティング Workgroup と Server の比較 Workgroup を使用するケース Pervsive PSQL Workgroup エンジンについては 以下の 3 通りの配備シナリオがあります 小規模なユーザーグループがある場合 Workgroup では 最大 5 つの同時接続がライセンスされています これは 小規模クライアント / サーバー構成と同様です 複数のコンピュータ上にデータが分散される場合これは ピアツーピアトポロジと呼ばれます 各アプリケーションではローカルのハードディスクにデータが保管されますが 他のワークステーションからデータにアクセスされるか 他のアプリケーションと定期的にデータを共有する必要がある場合に使用されます Pervsive PSQL データベースエンジンが動作できないコンピュータにデータを保管する必要がある場合オペレーティングシステムとの互換性がないなどの理由で アプリケーションデータを保管するコンピュータがデータベースエンジンをサポートできない場合 WGE がユーザーにリモート接続を提供します 別のコンピュータ上のディレクトリ内にあるファイルをオープンする最初の WGE は リモートコンピュータのデータベース全体にアクセスする他の用途に対応したゲートウェイとなります 他のコンピュータは このゲートウェイを介してクライアント / サーバー形式でデータにアクセスします MEFS ( マルチエンジンファイル共有 ) と Workgroup アーキテクチャ ファイル共有は 複数のクライアントが同じファイルを操作できる機能です 複数のクライアントが 1 つのファイルを共有して操作する場合 アクセス ロック 更新などを調整するために大量のオーバーヘッドが要求されます この仕組みは MEFS ( マルチエンジンファイル共有 ) と呼ばれ Btrieve 6.15 および Pervsive SQL 2000 よりも前の PSQL のバージョンで使用されていたテクノロジです MEFS は接続性を提供しますが キャッシュ使用の制限やネットワークトラフィックの増大など多くの制限があります Pervsive PSQL Workgroup のリリースについて
MEFS では 各データベースエンジンが独立して動作し ロックファイルおよびオペレーティングシステムレベルのロックによりデータアクセスを調整しています このような調整では ネットワークトラフィックのオーバーヘッドが高くなり パフォーマンス向上のために使用されるあらゆるタイプのキャッシュの使用が制限されます Pervsive PSQL Workgroup は クライアント / サーバーモデルに基づいて ファイルアクセスを制御し 調整します データベースに対するデータアクセスは 単一のデータベースエンジン ( ゲートウェイ ) によってすべて管理されます グループ内の他のクライアントは このゲートウェイを介してデータベースにアクセスします このアーキテクチャにより パフォーマンスと信頼性が向上しています 本書では Workgroup のリリースと Btrieve の以前のバージョンとの比較を中心に述べていますが Pervsive PSQL v9 にはさらに多くの利点が開発者やユーザー向けに用意されています 最新の Pervsive PSQL リリースと Btrieve の比較表については 本書の付録 B を参照してください パフォーマンスゲートウェイとして動作する Workgroup エンジンは データアクセスの中核ポイントを提供することによって ネットワークオーバーヘッドの軽減とデータベースキャッシュ利用率の改善を図り MEFS を使用する以前の Worksttion エンジンよりもパフォーマンスを大幅に向上させています データファイルへのアクセスをすべて調整することによって Workgroup エンジンは MEFS によって発生したネットワークトラフィックのオーバーヘッドを軽減し 読み取り 更新 削除などに関するデータベースの精度および保全性を保証しています MEFS では このオーバーヘッドが非常に大きくなります 図 1は MEFS 環境でワークステーションを増設した結果を示しています データベースキャッシュでは 最も頻繁にアクセスする最新のデータがメモリに保持され これによりディスクからデータを読み取る必要がなくなるため パフォーマンスに飛躍的な効果がもたらされます MEFS では 複数のクライアントが共有する共通のデータベースキャッシュはありません それに対して WGE 環境では ワークグループ内のすべてのクライアントが共通の ( ゲートウェイにある ) データベースキャッシュを共有します ネットワークトラフィックが軽減し キャッシュの利用率が改善され 結果的にディスクの入出力が減少するため PSQL Workgroup エンジンのパフォーマンスは MEFS で実行されている既存アプリケーションの 2 ~ 100 倍も向上します TPS MEFS 1 2 3 4 6 8 10 図 1. パフォーマンスの比較 - MEFS と Workgroup Pervsive PSQL Workgroup のリリースについて
図 1 は 100,000 行のデータベースに対する TPC-B ベンチマークテストの結果を示しています TPC-B は変更に重点を置いたテストで データベースエンジンがデータベースを変更できる速度が測定されます TPS は Trnsctions Per Second (1 秒あたりのトランザクションの数 ) を意味します TPC-B テストにおける各トランザクションでは 1 行が挿入され 3 行が更新されます クライアント 1 台では MEFS を実行している Worksttion エンジンのパフォーマンスは Pervsive PSQL Workgroup とほぼ同じであることがわかります しかし 複数のクライアントがデータに同時にアクセスする場合 MEFS のパフォーマンスは低下し 低い状態にとどまります 信頼性 単一の Workgroup ゲートウェイエンジンを使用してデータファイルへのアクセスをすべて調整することにより データベースの保全性も向上します まれなケースですが クラッシュが発生した場合には ファイルにアクセスする他のクライアントとファイルの更新を調整するために生じるオーバーヘッドにより MEFS ではデータの損失または破損の影響を受けやすくなります PSQL ゲートウェイエンジンを使用すると このオーバーヘッドが解消され より効率的で信頼性が高い方法でデータベースに変更がコミットされます Workgroup エンジンの機能 Btrieve 6.15 ( またはそれ以前の ) Worksttion エンジンのユーザーは PSQL v9 Workgroup エンジンの配備において 旧バージョンとの 3 つの大きな違いに気付くことでしょう 1. リモートファイルへのデータアクセスに使用するゲートウェイエンジンと そのゲートウェイを検索するクライアントリクエスタ 2. リモート接続を追跡するユーザーカウントマネージャー 3. NetBIOS - Pervsive の Network Services Lyer リモートクライアントとの接続に使用する NetBIOS 対応の通信サーバー Workgroup ゲートウェイゲートウェイエンジンは リモートファイルサーバー上の特定のディレクトリ内にあるすべてのデータファイルにアクセスするための唯一のポイントとなります データにアクセスする WGE は それ自身をゲートウェイとして識別するために ~PVSW~.LOC という名前のロケータファイルをデータファイルのディレクトリに作成します このファイルは ゲートウェイロケータファイルと呼ばれ ゲートウェイエンジンが配置されているコンピュータのネットワーク名が含まれています このデータファイルへのアクセスを試みる他の Workgroup エンジンは ロケータファイルを読み取って データアクセスのために通信する必要があるエンジンの名前を検索します ゲートウェイコンピュータは データファイルを読み書きするためのホスティングサーバーエンジンとして機能します 最後のユーザーがデータベースの使用を停止すると データベースエンジンはディレクトリ内の最後のデータファイルを閉じ ロケータファイルを解放して削除します そのデータファイルをオープンする次のエンジンが新しいゲートウェイになります これによって ゲートウェイの割り当てを 1 つのコンピュータから別のコンピュータへと動的に変更することができます ゲートウェイの構成 2 つの異なるゲートウェイ構成があります デフォルトは動的ゲートウェイ構成であり リモートデータファイルをオープンする最初のエンジンが ディレクトリ内のすべてのデータファイルが Pervsive PSQL Workgroup のリリースについて
閉じられるまでそのディレクトリのゲートウェイエンジンになります その後 リモートデータファイルを開く次のエンジンが 新しいゲートウェイになります この構成は最も柔軟ですが エンジンがさまざまなネットワークプロトコルを試行し 既存のゲートウェイエンジンをチェックするため データベースへの初回接続で遅延を引き起こす可能性があります 2 番目の構成は 固定ゲートウェイ構成または永続ゲートウェイ構成と呼ばれます この構成では ディレクトリのゲートウェイエンジンとして特定のエンジンが永続的に割り当てられます 別のエンジンがデータファイルにアクセスしようとしたときに 割り当てられたエンジンが起動していないと エラーコードが生成され そのデータファイルは利用できません Pervsive では コンピュータ間でゲートウェイを切り替えられるようにするのではなく 永続ゲートウェイコンピュータを選択することを推奨しています 動的ゲートウェイ トポロジでは Workgroup エンジンがキャッシュしたゲートウェイアドレスに接続できない場合 予期しない遅延が発生する可能性があり どのコンピュータが現在のゲートウェイであるかを再検出する必要があります コンピュータがゲートウェイとして使用される場合や 共有ローカルデータファイルがある場合に 他のコンピュータがデータファイルにアクセスするには Workgroup エンジンを起動しなければなりません また 必要な場合に Microkernel ルーターによって自動起動されるように構成することもできます Pervsive では [Workgroup エンジンの開始 ] メニュー項目をコンピュータ上のスタートアップフォルダに追加することを強く推奨しています 回避すべき構成複数の共有データソースを持つピアツーピア環境で動的ゲートウェイを使用するのはお勧めできません 複数のエンジンが複数のデータロケーション間でオーナーシップを切り替えられることは 大幅な接続遅延を引き起こす可能性があります データファイルと同じマシンで起動するエンジンがオペレーティングシステムでサポートされている場合は 動的 / 永続ゲートウェイをリモートマシンに作成しないようにしてください これによって ( ローカルユーザーの場合も ) すべてのデータへのアクセスがリモートゲートウェイ経由で行われることが回避されます 効率的な Workgroup 構成を確保するための最も良い方法は データファイルが常駐するコンピュータにローカルゲートウェイを グループ内のすべてのコンピュータに Workgroup エンジンをインストールすることです これは コンピュータの起動時に Workgroup エンジンが必ず起動されるようにすることによって 確実なアプローチとなります Workgroup がゲートウェイを識別する方法データファイルにアクセスするときに WGE はまず アクセス対象のデータファイルに既存のゲートウェイがあるかどうかを検出しようとします WGE がゲートウェイを検出するために使用する決定アルゴリズムには 以下の優先順位が適用されます 優先順位 1 - データが常駐するコンピュータ上で起動しているエンジンがある 優先順位 2 - ローカルエンジンが データファイルをオープンできる 優先順位 3 - ゲートウェイエンジンが ディレクトリを所有している 優先順位 1 の場合 WGE は データファイルがあるコンピュータ上でアクティブなエンジンが起動していると常に想定します これは ディスクの入出力が速くなればどのデータベースエンジンでもパフォーマンスが向上するため 常に最優先されます Pervsive Network Services Lyer は いくつかの異なる方法でリモートデータベースエンジンを検出し 接続します そのため アクティブなデータベースエンジンを持っていないファイルサ Pervsive PSQL Workgroup のリリースについて
ーバー上のデータファイルをオープンするためにプロセスで最初の試行が行われるときに 時間遅延が発生する可能性があります ゲートウェイの永続性がオンになっていると そのコンピュータ上にアクティブなエンジンがないことを Microkernel ルーターが記憶しているため 接続は再度試行されません 優先順位 1 が失敗すると Microkernel ルーターは優先順位 2 を試行し ローカルエンジンでそのデータファイルをオープンできると想定します ローカルエンジンは 新しいロケータファイルの作成とオーナーシップの取得を最初に試みます しかし そのディレクトリが別の Workgroup ( または Server) エンジンによってすでに所有されている場合 ローカルエンジンはステータス 116 ( ファイルはゲートウェイとして機能する別の MicroKernel エンジンによって所有されています ) を返します 最後に Microkernel ルーターは優先順位 3 ( ゲートウェイエンジンの検出 ) を試行します Microkernel ルーターは ロケータファイルをオープンし Workgroup エンジンがゲートウェイとして機能しているコンピュータの名前を読み取った後 そのエンジンに要求を送信します Microkernel ルーターは エンジンからステータス 116を受信していない限り ロケータファイルの読み取りを試行しません したがって ゲートウェイの機能を使用するには ローカルに Workgroup エンジンをインストールしている必要があります ローカルエンジンも データファイルにあるエンジンも存在しない場合 Microkernel ルーターは優先順位 3 を試行せずに処理を中止します ローカルファイルの読み取りが試行されないため ゲートウェイが検出されず アプリケーションはステータス 116を受信します ゲートウェイロケータファイルゲートウェイロケータファイルは ゲートウェイコンピュータのネットワーク名を含むテキストファイルです ロケータファイルの名前は常に "~PVSW~.LOC" であり MicroKernel はオープンされたファイルのディレクトリにロケータファイルを作成します このようにして MicroKernel エンジンには そのディレクトリ内の全データファイルのオーナーシップが与えられます ゲートウェイの割り当てを永続的にするには このファイルの属性を読み取り専用に変更します 読み取り専用に変更するには 以下のように ttribコマンドをコマンドラインから実行してください C:\Dt>ATTRIB +R ~PVSW~.LOC または 以下の Gtewy Loctor ユーティリティを使用して 永続的割り当てを設定および変更することもできます 永続的に割り当てられたゲートウェイを使用しており かつ Workgroup 内のコンピュータの数が増加した場合には Workgroup エンジンの代わりに Server エンジンをインストールし ゲートウェイとして機能させることもできます このことが可能なのは Windows 用の Pervsive PSQL Server エンジンが リモートデータファイルを開く要求を受け取ったときに Workgroup エンジンと同様にロケータファイルを作成および管理できるためです Gtewy Loctor ユーティリティ Pervsive PSQL Workgroup エンジンには ロケータファイルの内容を表示および変更するための非常に簡単なユーティリティが含まれています ディレクトリを選択するだけで 現在アクティブなゲートウェイを表示できます ディレクトリ内のファイルに固定ゲートウェイを割り当てる場合は [ 変更 ] をクリックしてください 固定ゲートウェイの割り当てを作成 / 削除することもできます Pervsive PSQL Workgroup のリリースについて
リダイレクトゲートウェイロケータファイルリダイレクトゲートウェイロケータファイルにより マルチディレクトリデータベースのトランザクションアトミシティが保証され 複数のデータディレクトリにまたがるゲートウェイエンジンの名前を容易に変更することができます リダイレクトロケータファイルは Workgroup エンジンを直接指定するのではなく Workgroup エンジンを指定するゲートウェイロケータファイルを指示します たとえば アプリケーションがディレクトリ A B C を使用しており これらの各ディレクトリに含まれているリダイレクトロケータファイルが ディレクトリ D にあるゲートウェイロケータファイルを指示しているとします ディレクトリ D にあるゲートウェイロケータファイルでは Workgroup エンジンが起動しているコンピュータを指定することによって ディレクトリ A B C D にあるすべてのデータベースのトランザクションアトミシティを保証します ディレクトリ D にあるロケータファイルが固定ゲートウェイを指定するか 最初のエンジンによって動的に作成されてそれらのファイルをオープンするかにかかわりなく すべての指定ディレクトリが同じゲートウェイエンジンを使用することが このアーキテクチャによって保証されます いくつかのディレクトリに対して永続的に割り当てられたゲートウェイエンジンを変更することを決定した場合 リダイレクトロケータファイルでそのような変更を行うには ロケータファイルを全部ではなく 1 つ変更するだけで済みます 固定ゲートウェイが指定されているかどうかにかかわらず 指定ハードドライブ上のすべてのデータが同じゲートウェイエンジンを使用しなければならないように指定することができます リダイレクトロケータファイルの詳細については Getting Strted with PSQL Workgroup のマニュアルを参照してください License Administrtor License Administrtor ユーティリティでは ライセンスキーの適用 ライセンスの削除 ライセンス情報の表示が可能です このユーティリティには GUI インターフェイスとコマンドラインインターフェイスが含まれています Pervsive PSQL ライセンスキーを使用すると Pervsive PSQL エンジンに一定数のコンピュータが同時にアクセスできます Pervsive PSQL for Workgroups では データベースに対する最大 5 つの同時接続がライセンスされています このライセンスは インストール時に各 Workgroup エンジンに適用し リモート接続の数を 5 までに制限します アプリケーションデータへのアクセスに使用されるシステムごとに Workgroup をインストールする必要があります Pervsive PSQL Workgroup のリリースについて
Pervsive PSQL にクライアントとしてアクセスする各コンピュータは 1 ユーザーとしてカウントされますが カウントされるユーザーにはローカル ( ホスト ) コンピュータ上のアプリケーションからのアクセスも含まれます 単一コンピュータ上の複数アプリケーションは 1 ユーザーとしてカウントされます ユーザーはネットワークアドレスによってカウントされます NetBIOS を使用したネットワーク Pervsive PSQL Server 製品と Workgroup 製品は どちらも同じネットワーキングコンポーネントとともに出荷されるため Workgroup エンジンを Server エンジンにアップグレードするのは簡単です クライアント側のリクエスタは いずれかのタイプのエンジンに接続します Pervsive Network Services Lyer は NetBIOS を使用して ネットワーク上のエンジンや サポートされている他のプロトコルとメソッドを検索できます Microkernel ルーターは 以下のいずれかの方法でネットワーク上のリモートエンジンを検出します Windows Server エンジンによって作成された名前付きパイプ DNS (TCP/IP 用の Dynmic Nme Service) NDS (Novell NetWre ディレクトリサービス ) NetWre バインダリ NetWre および Windows 2000/XP/2003 では エンジンがクライアントリクエスタからユーザー名を取得し そのユーザーのプロキシとして機能してファイルアクセス権を決定します クライアントがファイルをオープンするときには 常にエンジンがアクセス権を実行します この機能は Windows 98/Me では提供されていません したがって ログインユーザー名に割り当てられた権限に基づいて Workgroup エンジンがオペレーティングシステムレベルのファイルセキュリティを確保することはできません 小規模なオフィスは Workgroup エンジンに最適な環境であり ネットワーク専門家を必要とすることなく ユーザーが簡単にデータにアクセスできます ファイルレベルのセキュリティのみが 使用可能な認証 承認メカニズムというわけではありません PSQL v9 Workgroup には データに対するファイルレベルの権限を持つユーザーを使用せずにファイルにアクセスするためのサポートが含まれています 詳細については Advnced Opertions Guide, セキュリティモデルと概念 を参照してください トラブルシューティングおよび Workgroup の最適化 問題が発生している際にまず考慮すべき事柄の 1 つは 最新のサービスパックを実行しているかを確認することです Pervsive PSQL のサービスパックリリースには 問題解決につながる可能性のある機能強化およびアップデートが盛り込まれています 最新のサービスパックは AG- TECH Web サイト (http://www.gtech.co.jp/downlod/updte/pervsive/index.html) からダウンロードすることができます 最初の接続での時間遅延ここでは アプリケーションがファイルアクセスを初めて開始するときにいつも遅延が発生している場合に検討すべきいくつかの方法を示します 以下のコマンドを使用してスタートアップフォルダにエンジンアイコンを追加し ファイルサーバー上でデータベースエンジンが起動することを確実にします C:\Pvsw\Bin\W3dbsmgr.exe -SRDE Windows 98 マシンでは 以下のレジストリキーを追加します Pervsive PSQL Workgroup のリリースについて
[HKEY_LOCAL_MACHINE\Softwre\Microsoft\Windows\CurrentVersion\ RunServices] "Pervsive PSQL Workgroup" = "C:\\Pvsw\\Bin\\W3dbsmgr.exe -SRDE - SERVICE" このレジストリキーは ユーザーがログオンする前にエンジンを起動します この場合 トレイアイコンは表示されません ですから その時点のエンジンの状態を示す目に見えるインターフェイスはありません ゲートウェイトポロジを実行している場合に ファイルサーバーでエンジンが起動していないときには 初回接続時の時間遅延はより重要な問題となります 以下を実行できます クライアント設定でサポートされているネットワークプロトコルの数を減らし 未使用のプロトコルが試行されないようにします たとえば トポロジに NetWre エンジンがない場合 ( ほとんどの Workgroup トポロジに当てはまる ) サポートプロトコルから SPX/IPX を削除できます ゲートウェイの永続性を有効にします ゲートウェイ環境での初回接続で発生する遅延を実質的に排除するには コンピュータでエンジンが起動していない場合にレジストリに書き込むようにクライアント Microkernel ルーターに指示します 接続の失敗が記録されると Microkernel ルーターは コンピュータ名をレジストリに保管し アプリケーションが次回開始されるときにそのコンピュータ上にあるエンジンに接続を試行しないようにします Microkernel ルーターは 現在のゲートウェイを判別するための次のステップへと直ちに進みます 注意 : デフォルトでは ゲートウェイ一貫性保守は OFF に設定されていますが これはエンジンの数 配置の変更を許可しないようにするためです ファイルサーバーにサーバーエンジンを追加する場合は 設定ユーティリティを使用して Workgroup 内のコンピュータごとにゲートウェイ一貫性保守を OFF に設定する必要があります バージョン 6.15 からの移行 Pervsive PSQL Workgroup のリリースは 再コンパイルしなくても すべての Btrieve アプリケーションとの互換性を持つことは言うまでもありません 従来のアプリケーションでも 本書で説明した PSQL v9 の利点のほかに PSQL v9 のさまざまな機能強化 ( 強化されたセキュリティ OS のサポートなど ) を活用することができます まとめ Pervsive PSQL Workgroup のリリースでは 費用も管理も少なくて済む自己調整型のエンジンが提供され このエンジンがネットワーク上にあればユーザーは常にデータに接続されます これによってデータの信頼性が向上しますが 最も重要な点は Btrieve 6.15 MEFS ベースの古いエンジンよりもデータ共有がはるかに高速化されていることです 多数のクライアントとデータを共有しない小規模のオフィスおよびワークグループにとって Pervsive PSQL Workgroup は理想的なソリューションとなります Pervsive PSQL Workgroup のリリースについて 10
付録 A: Workgroup と Server の比較 Pervsive PSQL の Workgroup エンジンおよび Server エンジンは 共通の Pervsive PSQL コードベースのテクノロジを活用します この共通のコードベースは すべての PSQL v9 エンジンで同様に動作するため エンジンの安定性と信頼性を保証するだけでなく 構成にかかわらず管理および配備を簡素化します これらのエンジンでは API キャッシュ クライアント ファイル カーソルおよびロック管理が共通しており 永続性に関するトランザクションロギングのほか アーカイブログ Continuous オペレーション その他すべての MicroKernel 機能がサポートされています Pervsive PSQL Control Center (PCC) およびすべての関連ユーティリティは どちらの製品にも含まれています PCC は統合されたデータベース管理フレームワークであり ユーティリティ (SQL Dt Mnger Btrieve 要求テスト用の 32 ビットの Function Executor 設定ユーティリティ Pervsive Monitor ユーティリティなど ) を起動するためのプラットフォームとして動作します 機能 Server Workgroup データベースエンジンがインストールされていないファイルサーバー上のデータにアクセス可能 Windows 98 Me XP サポート Windows 2000 Server 2003 サポート Linux サポート 小規模グループのためのマルチユーザー 6 ~ 数千ユーザーの規模 1 ~ 5 までの同時ユーザー数のサポート インストール時にWindows サービスとして登録 OS レベルのセキュリティを確保 非同期 I/O Bckup Agent DtExchnge Btrieve ODBC OLE-DB JDBC PDAC ActiveX サポート リレーショナルサポート ( オンラインバックアップ セキュリティ 参照整合性 管理ツールなど ) 全てのプラットフォームおよびエンジンバージョンにまたがるバイナリ互換データファイル 簡便なプラグアンドプレイによるアップグレード アプリケーションの変更は不要 オンラインドキュメントの付属 Pervsive PSQL Workgroup のリリースについて 11
付録 B: PERVASIVE PSQL バージョン比較ガイド 機能 Btrieve 6.15 V8 v9 ~P.SQL 2000i Btrieve API 再構築された GUI ユーティリティ (Pervsive Control Center) フリーオンライン SDK 新 DDF 管理ツール (DDF Builder 4.0) ユーザー定義関数 - CREATE 関数 システムストアドプロシージャ SQL アウトラインビュー バルクデータユーティリティ 設定プロパティユーティリティ コマンドラインモニタユーティリティ データ定義言語 (DDL) ユーティリティ 可変レコードレイアウトに対する SQL サポート レコード内の配列に対する SQL サポート ODBC 3.51 準拠 64 GB のテーブルサイズ ( 注 :Btrieve 6.15では最大 4 GB) 256 GB のテーブルサイズ ( 注 :v9 SP1 では最大 128 GB) 256 GB の最大ファイルサイズ ( 注 :v9 SP1 では最大 128 GB) 16K のページサイズ ( 注 :v9 SP1 では最大 8 K) ファイルバージョンの自動アップグレード DtExchnge 対応 ( 複製 / 同期 ) Bckup Agent 対応 ( バックアップ ) Windows 2000/Server 2003 および Linux のサポート Pervsive PSQL Workgroup のリリースについて 12
連絡先 株式会社エージーテック 101-0054 東京都千代田区神田錦町 1-21-1 昭栄神田橋ビル 3F info@gtech.co.jp http://www.gtech.co.jp 2006 Pervsive Softwre Inc Pervsive.SQL Btrieve AuditMster Bckup Agent DtExchnge Pervsive のロゴ MicroKernel Dtbse Architecture MicroKernel Dtbse Engine Nvigtionl Client/Server および Sclble SQL は Pervsive Softwre Inc の商標または登録商標です 他のすべての製品名は それぞれの会社の商標です All rights reserved worldwide. Novell および NetWre は Novell, Inc の登録商標です Microsoft Windows Windows NT および Visul Bsic は 米国 Microsoft Corportion の登録商標または商標です 特記事項 : 本書に示されたパフォーマンスは 参照のみを目的としています 同様の構成においても そのようなパフォー.. マンスを保証するものではありません Pervsive PSQL Workgroup のリリースについて 13 WP0106B07