PSQL コンポーネントのアーキテクチャ

PSQL は最適化されたメモリアーキテクチャを使用し、トランザクショナルアクセスとリレーショナルアクセスの両方に高いパフォーマンスを提供します。MicroKernel エンジンおよびリレーショナルエンジンは、共に同一プロセスアドレス空間でロードかつ動作し、それらの間の通信にかかる CPU 時間を最小限にします。

同時にたくさんの更新や書き込みが行われたり、長時間に渡ってトランザクションが開かれたままになる複数ユーザー環境では、行レベルのロックによってデータベースエンジンのパフォーマンスが向上します。

トランザクションはページ全体ではなく直接影響する行のみをロックします。クライアントはあるページのレコードの変更を、他のクライアントが同一ページの別のレコードを変更するのと同時に行うことができます。2 番目のアプリケーションは、最初のアプリケーションが現在ロックしているのとまったく同じレコードを変更しようとしたときにのみ、待つことが必要になります。したがって、行レベルのロックは複数ユーザー環境で総体的な待ち時間を減少させ、パフォーマンスを向上させます。

この機能は MicroKernel エンジン内で完全に透過です。この機能は常に動作していて、サポートされるすべてのオペレーティングシステムプラットフォームと同様、サーバー、ワークグループでサポートされます。この機能は、データファイル形式 v6.x 以降でサポートされます。

行レベルのロックはデータページに実装され、部分的にはキーページにも実装されます。可変ページには行レベルのロックは適用されません。キーページの一部分の変更によって、キーエントリが別のページに移動することがあります。その例として、キーページが分割または結合されるときがあります。これらの変更では、トランザクションが完了するまで完全なページロックが継続します。

MicroKernel エンジンは、PSQL アプリケーションに対し Btrieve API サポートを提供します。MicroKernel エンジンには、サーバーとワークグループという 2 種類のエンジンがあります。サーバーエンジンは、Windows、Linux、および OS X サーバー上で実行可能です。ワークグループエンジンは Windows 上でのみ実行できます。また、このエンジンはシングルユーザーや小規模のワークグループ構成向けに設計されています。

PSQL Sever および PSQL Workgroup は共に、エンジンと同じコンピューター上で実行されるローカルアプリケーションをサポートします。サーバーの MicroKernel エンジンは、ローカルアプリケーションとリモート（クライアント/サーバー）アプリケーションの両方をサポートします。ワークグループの MicroKernel エンジンは、リモートマシンで実行されるアプリケーションにも対応し、リモートマシン上の別のピアワークグループエンジンによるリクエストを処理します。

ワークグループエンジンは、デフォルトでは、Windows のログイン時に起動されるよう設定されています。ファイルが既にエンジンによって開かれている場合、ワークグループエンジンは、別のピアエンジンによるリクエストを処理できます。特定のマシンを設定してデータベースエンジンをゲートウェイとして使用することもでき、ほかのワークグループエンジンがファイルを開くことを回避します。

Windows のサーバーエンジンは、Windows のサービスとして実行するようにインストールされます。ワークグループエンジンは、アプリケーションまたはサービスのどちらで実行するようにインストールするかを設定できます。新規インストールの場合、デフォルトでは、サービスとして実行するようにインストールされます。アプリケーションとしてインストールされた場合は、ワークグループエンジンの実行中は、それを表すトレイアイコンが表示されます。ワークグループエンジンを実行していない場合、トレイアイコンは表示されません。サーバーエンジンの場合、またはワークグループエンジンがサービスとしてインストールされた場合、トレイアイコンは表示されません。サーバーとワークグループの技術的な相違も参照してください。

PSQL の Btrieve および ODBC API を使用することにより、アプリケーションからのローカルまたはリモートのデータベースエンジンへの接続情報が表示されない、分散型データベースアプリケーションを作成できます。このアーキテクチャを使用すると、アプリケーションは、そのアプリケーションがあるローカルのデータにアクセスすると同時に、リモートコンピューターのデータにもアクセスできます。さらに、SQL データベースは、ローカルの MicroKernel エンジンによって処理されるデータ辞書ファイル（DDF）、およびリモートの MicroKernel エンジンによって処理されるデータファイル（テーブル）を作成することにより、分散化が可能です。ローカルの MicroKernel エンジン以外のエンジンにも処理されるこのような SQL データベースは、「混合アクセスデータベース」と呼ばれます。

混合アクセスデータベースには、以下の制約があります。

•参照整合性の関係にかかわるテーブル、定義されているトリガーがあるテーブル、またはバインドされた名前付きデータベースにあるテーブルのデータファイルは、リモートの MicroKernel エンジンで開くことができません。

•ファイルを開く際、リレーショナルエンジンは、リクエストを処理する MicroKernel エンジンのバージョンを確認しません。バージョン 6.30 以降の MicroKernel エンジンの API サポート（たとえば、共有ロックなど）を必要とするオペレーションが、バージョン 6.30 より前のエンジンに対して発行された場合は、エラーコードが返されます。DDF を開く際、または DDF ファイルやデータファイルをバインドしようとする際に、リレーショナルエンジンでは、ローカルの MicroKernel エンジンがリクエストを処理していることを確認します。

サーバー版の Windows 用 MicroKernel エンジンは、ページをディスクに書き込む際に非同期 I/O を使用します。この機能はパフォーマンスを向上させます。MicroKernel は直ちに Windows システムキャッシュまたは MicroKernel のキャッシュにページを書き込みます。次に、Windows はページがディスク上にあると信号を送って、MicroKernel が効率的に書き込み操作を行えるようにします。

MicroKernel でたくさんの並行オペレーションが同時に行われる場合、特にデータセットがストライプセットのディスクドライバー上にある場合には、読み取りパフォーマンスも向上しています。各読み取りは、ページが利用可能になるまでワーカスレッドを待機させます。非同期 I/O では、オペレーティングシステムは複数の読み取り要求の作業をプールして、読み取り操作をより効率的に行います。

PSQL のリレーショナルエンジンは、PSQL アプリケーションに対し ODBC サポートを提供します。ODBC クライアントのプラットフォームには、Windows プラットフォームがあります。リレーショナルエンジンへのリモート ODBC アプリケーションアクセスには、PSQL の ODBC クライアントがインストールされている必要があります。これは、ネットワーク上でクライアント側の ODBC 呼び出しを ODBC 通信サーバーに転送する専用 ODBC ドライバーです。

リレーショナルエンジンには以下のような機能が含まれています。

ODBC 通信サーバーは、以下の機能を実行します。

SQL および ODBC の詳細については、『SQL Engine Reference』の SQL の概要および『ODBC Guide』のDSN のセットアップおよび接続文字列を参照してください。

下図は、サーバー版 PSQL のリレーショナルエンジンのアーキテクチャコンポーネントを示したものです。SQL 接続マネージャーは、MicroKernel エンジンおよびリレーショナルエンジンと同じプロセスアドレス空間で起動し実行します。

SQL 接続マネージャーは、最大 2000 までの同時接続をサポートしており、ODBC ドライバーマネージャーを使用してリレーショナルエンジン（SRDE）を呼び出します。エンジンは MicroKernel の上に置かれます。

図 2 は、PSQL のクライアント/サーバーリレーショナルアーキテクチャを示します。クライアントは、TCP/IP を介してサーバーの SQL 接続マネージャーに接続します。このアーキテクチャは、サーバーエンジンおよびワークグループエンジン（ローカルワークグループエンジンからリモートワークグループエンジンへの接続にクライアント DSN を使用する場合）に適用されます。

図 3 は、ローカルワークグループエンジンからリモートデータベースへの接続に DSN を使用する場合のワークグループリレーショナルアーキテクチャを示します。リモートワークグループエンジンはリモートデータへのゲートウェイとなっていることを想定しています。

PSQL の多くの最上位コンポーネントは、その下の階層のコンポーネントからのエラーコードがそのまま渡されるため、呼び出し元アプリケーションまたはログファイルでエラーの実際の原因を明確に特定できるようになりました。エラーコードがさまざまな状況に該当する可能性がある場合は、PSQL イベントログ内の具体的な情報により、そのエラーの根本的な原因が特定されます。メッセージログの見直しを参照してください。

自動再接続機能の PSQL Auto-Reconnect（PARC）を使用すると、クライアント/サーバーまたはワークグループアプリケーションは、一時的なネットワークの中断時にも現在のデータベースオペレーションを中止しません。PSQL がネットワークの中断を検出すると、設定可能な指定時間ごとに自動的に再接続を試行します。この機能はクライアントのコンテキストも維持するので、通信が再確立されたとき、ネットワークの中断が起こったときとまったく同じようにデータベースアクセスが継続されます。

この機能は、アプリケーションのコンテキストを維持し、ネットワーク通信が中断されたときにクライアントまたはサーバーがその時点でデータを送信しようとしていたかどうかにかかわらず、再接続を試行します。

ネットワークが中断したとき、一定の待ち時間の経過ごとに再接続が試行されます。すべての接続で、0.5、1、2、4、8 秒ごとに継続的に再接続が試行され、その後、自動再接続タイムアウトの値に達するまで 8 秒ごとに試行されます。最大待ち時間に達しても接続に成功しない場合、現在のオペレーションは失敗し、クライアントの接続はリセットされます。最大の待ち時間は 45 秒から 65,635 秒の間に設定できます。

この機能はデフォルトで使用不可になっています。この機能を動作させるには、クライアントとサーバーの両方の設定で、自動再接続の有効化（Windows のみ）を選択する必要があります。待ち時間の値は、サーバー設定の自動再接続タイムアウトを使って行うことができます。

この機能は、Btrieve、ODBC、および DTI 接続でサポートされています。

Btrieve 通信サーバーは、トランザクションログディレクトリに .par または .sar ファイルを書き込むことがあります。これらは、サーバーがクライアントに送信しようとした最新のアイテムのコンテキストを含むテンポラリファイルです。再接続が行われると、クライアントはデータの再送信を再度要求します。サーバーはこれらのファイルを読んで適切なデータを取得します。これらのファイルは、データが読み取られたあと、接続が最終的に終了するときにサーバーが削除します。