5.5 データベース・サーバー・プロセス・アーキテクチャの理解

リスナーに登録されたサービス・ハンドラのタイプに基づいて、リスナーは共有サーバー・プロセスまたは専用サーバー・プロセスのいずれかに要求を転送します。データベース・サーバーは、共有サーバー・アーキテクチャを使用して、サーバー・プロセスを多数のクライアント・プロセスが共有できるようにしています。専用サーバー構成では、リスナーはクライアントの着信接続要求ごとに専用サーバー・プロセスを個別に起動します。このプロセスはクライアントへのサービス提供のみを行います。

• 共有サーバー・プロセスについて
  
• 専用サーバー・プロセスについて
  

5.5.1 共有サーバー・プロセスについて

図5-4で示すように、共有サーバー・プロセスは、共有サーバー・アーキテクチャで使用されます。共有サーバー・アーキテクチャでは、クライアントは最終的にディスパッチャへの接続を行います。LREGプロセスは、ディスパッチャの場所とロード情報をリスナーに登録するため、リスナーは要求を最もロード量の少ないディスパッチャに転送できます。この登録プロセスは、図には示されていません。

ディスパッチャは、複数のクライアント接続を同時にサポートできます。各クライアント接続は、バーチャル・サーキットにバインドされます。バーチャル・サーキットは、ディスパッチャが使用する共有メモリーの1つで、クライアント・データベースの接続要求および応答を目的としています。ディスパッチャは、要求が到着するとバーチャル・サーキットを共通要求キューに配置します。アイドル状態の共有サーバーは、要求キューからバーチャル・サーキットを取り出して要求を処理し、要求キューから次のバーチャル・サーキットを取り出す前に、取り出したバーチャル・サーキットを放棄します。共有サーバーは、完了したすべての要求をディスパッチャのレスポンス・キューに格納します。各ディスパッチャには、SGA(システム・グローバル領域)に独自のレスポンス・キューがあります。この方法によって、サーバー・プロセスの小規模プールが大量のクライアントを処理できるようになります。

図5-4 共有サーバー・アーキテクチャ

「図5-5 専用サーバー・アーキテクチャ」の説明

5.5.2 専用サーバー・プロセスについて

専用サーバー・アーキテクチャでは、クライアント・プロセスごとに専用サーバー・プロセスへの接続を行います。サーバー・プロセスは、他のいずれのクライアントとも共有されません。図5-5は、専用サーバー・アーキテクチャを示しています。

LREGは専用サーバー・プロセスに関する情報をリスナーに登録します。これによってリスナーは、クライアント要求を受け取って転送する際に、専用サーバー・プロセスを開始できます。

ノート:

専用サーバー・アーキテクチャは、HTTP、FTPまたはWebDAVクライアントをサポートしていません。データベース・クライアントのみサポートします。

図5-5 専用サーバー・アーキテクチャ

「図5-5 専用サーバー・アーキテクチャ」の説明