日本語PDF
  1. Net Services管理者ガイド
  2. Oracle Net Servicesの理解
  3. Oracle Netアーキテクチャの理解

5 Oracle Netアーキテクチャの理解

Oracle NetリスナーはOracle Net Foundationレイヤーの最上位に位置するアプリケーションです。データベースは、クライアント・アプリケーションからの初期接続を、リスナーを通じて受け取ります。

リスナーは、クライアント要求を受け取ってOracle Databaseサーバーに渡します。クライアントがデータベースとのネットワーク・セッションを要求するたびに、リスナーは初期要求を受信します。

図5-1では、初期接続時のクライアントとデータベース・サーバー上にある様々なレイヤーを示します。図に示すように、リスナーはサーバー側のネットワーク・スタックの最上位レイヤーにあります。

図5-1 初期接続で使用するレイヤー

図5-1の説明が続きます
「図5-1 初期接続で使用するレイヤー」の説明

親トピック: Oracle Net Servicesの理解

5.1 サービス登録について

リスナーはデータベース・サービスとそのサービス・ハンドラが利用可能かどうかを、サービス登録から判断します。登録を行うと、リスナー登録(LREG)プロセスからリスナーに次の情報が提供されます。

  • データベースが提供するデータベース・サービスの名前

  • サービスに対応付けられているデータベース・インスタンスの名前と、その現在および最大のロード情報

  • インスタンスから使用可能なサービス・ハンドラ(ディスパッチャおよび専用サーバー)とそのタイプ、プロトコル・アドレスおよび現在のロード量と最大ロード量

前述の情報によって、リスナーは、クライアントの要求を適切に送ることができます。

図5-2は、情報を2つのリスナーに登録する2つのデータベース・インスタンスを示しています。登録できるすべての情報を示しているわけではありません。たとえば、ポート番号などのリスニング・エンドポイントをリスナーに動的に登録できます。

図5-2 サービス登録

図5-2の説明が続きます
「図5-2 サービス登録」の説明

インスタンスの起動時にリスナーが実行していない場合、LREGプロセスはサービス情報を登録できません。LREGは、定期的にリスナーに接続を試みますが、リスナーが起動されてからLREGがリスナーに登録するまで、最大で60秒間遅延することがあります。リスナーの起動後即座にサービス登録を開始するには、SQL文ALTER SYSTEM REGISTERを使用します。この文は特に高可用性が求められる構成で有益です。

親トピック: Oracle Netアーキテクチャの理解

5.2 リスナーおよび接続要求について

各リスナーは、リスニングするエンドポイントを指定する1つ以上のプロトコル・アドレスで構成されます。プロトコル・アドレスはリスナーがリスニングを実行するプロトコルと、プロトコル固有のその他の情報を定義します。たとえば、リスナーを次のプロトコル・アドレスでリスニングを実行するように設定できます。 

(DESCRIPTION=
   (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)))

前の例では、リスナーのホスト(sales-server)とポート番号(1521)を指定するTCP/IPプロトコル・アドレスを示しています。

1つのプロトコル・アドレスで構成されたクライアントは、そのリスナーに接続要求を送ります。リスナーはクライアント要求を受信すると、そのクライアント要求を処理する適切なサービス・ハンドラを選択してクライアント要求を転送します。サービス・ハンドラは、データベースへの接続ポイントとして機能するディスパッチャまたは専用サーバーです。

図5-3は、接続確立中のリスナーのロールを示しています。HTTP接続を行うブラウザとデータベース接続を行うクライアントを示しています。

  1. ブラウザまたはクライアントがリスナーに接続要求を送信します。

  2. リスナーは要求を解析し、要求されたデータベース・サービスのサービス・ハンドラに転送します。

  3. ブラウザまたはクライアントはデータベースに接続します。

図5-3 リスナーのアーキテクチャ

図5-3の説明が続きます
「図5-3 リスナー・アーキテクチャ」の説明

親トピック: Oracle Netアーキテクチャの理解

5.3 Oracle Restartについて

Oracle Restartは、シングル・インスタンス環境におけるOracleデータベースの可用性を向上します。サーバー制御(SRVCTL)ユーティリティを使用すると、リスナーなどのコンポーネントをOracle Restart構成に追加できます。この構成により、リスナーに障害が発生した場合、または動作していない場合にリスナーを自動的に起動できます。

Oracle Restartを使用するときは、次のことに注意してください。

  • リスナーを起動および停止するには、SRVCTLユーティリティを使用します。リスナー制御ユーティリティLSNRCTLは使用しないでください。

  • 各リスナーは固有の名前を持つ必要があります。

関連項目:

親トピック: Oracle Netアーキテクチャの理解

5.4 ブロックされた接続要求について

ブロックされた接続要求は、対応するインスタンスが登録される前に受信要求が行われた場合、またはデータベースのシャットダウンが進行中のときなどのようにデータベースが制限モードになっている場合に、発生する可能性があります。データベース・インスタンスが制限されたモードの場合、LREGはリスナーにこのインスタンスへの全接続をブロックするよう指示します。クライアントが接続しようとすると、次のいずれかのエラーが発生します。

  • ORA-12526: TNS:リスナー: 該当するインスタンスはすべて限定モードになっています

  • ORA-12527: TNS:リスナー: インスタンスはすべて限定モードになっているか、新規接続をブロックしています

  • ORA-12528: TNS:リスナー: 該当するインスタンスはすべて、新規接続をブロックしています

データベース・インスタンスがリスナーにまだ登録されていないと、ORA-12528エラーが発生します。

関連項目:

親トピック: Oracle Netアーキテクチャの理解

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

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

親トピック: Oracle Netアーキテクチャの理解

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

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

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

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

図5-4の説明が続きます
「図5-5 専用サーバー・アーキテクチャ」の説明

親トピック: データベース・サーバー・プロセス・アーキテクチャの理解

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

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

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

ノート:

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

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

図5-5の説明は次にあります。
「図5-5 専用サーバー・アーキテクチャ」の説明

親トピック: データベース・サーバー・プロセス・アーキテクチャの理解

5.6 Oracle Connection Managerのアーキテクチャの理解

Oracle Connection Managerはゲートウェイであり、これを介してクライアントの接続要求が次のホップまたはデータベース・サーバーに直接送信されます。Oracle Connection Managerを通して接続要求を送信するクライアントは、そのOracle Connection Managerに構成されているセッション多重化およびアクセス制御を利用できます。LREGプロセスがサービスを登録するまで、サービス情報は送信されません。

Oracle Connection Managerは3つのコンポーネントで構成されています。

リスナーは、クライアント接続を受け取り、一連の規則と照合して、アクセスの可否を判断します。アクセスが許可されると、リスナーは最小接続回数の接続を選択してゲートウェイ・プロセスに要求を転送します。CMGWプロセスでは、データをリレーするために接続が終了するまで、この要求を別のOracle Connection Managerに転送するか、またはデータベース・サーバーに直接、転送します。すでに既存のサーバーへの接続がある場合、ゲートウェイは既存の接続を介してこの接続を多重化、または集中化させます。CMADMINは、ゲートウェイ・プロセスとリスナーの状態を監視して、必要に応じてプロセスを停止または開始します。さらに、このリスナーで使用されるゲートウェイ・プロセスの場所とロードを登録し、Oracle Connection Manager Controlユーティリティの要求に応答します。

図5-6では、リスナーは接続要求を選別します。ゲートウェイ・プロセスは、CMADMINプロセスに登録され、CMADMINプロセスはリスナーに登録されます。最後にリスナーは、接続要求をゲートウェイ・プロセスに転送します。ゲートウェイ・プロセスは3つの有効なクライアント接続を受け取り、データベースへの単一のネットワーク・プロトコル接続を介してそれらを多重化します。4番目の接続は一連の規則について評価されて拒否されます。

図5-6 Oracle Connection Managerのアーキテクチャ

図5-6の説明が続きます
「図5-6 Oracle Connection Managerのアーキテクチャ」の説明

親トピック: Oracle Netアーキテクチャの理解

5.7 完全なアーキテクチャ

Oracle Netはアーキテクチャ上のソリューションを提供しているため、インターネットやイントラネット環境における拡張性をさらに高めることができます。

図5-7は、Oracle Databaseサーバーへの複数の接続がOracle Connection Managerおよび共有サーバー・アーキテクチャによってさらにスケーラブルになっている様子を示しています。Oracle Connection Managerを使用すると、アプリケーションWebサーバーのネットワークI/Oの負荷が軽減され、共有サーバーを使用すると、さらに多くの同時ユーザーが処理されます。

図5-7 スケーラブルなアーキテクチャ上のソリューション

図5-7の説明が続きます
「図5-7 スケーラブルなアーキテクチャ上のソリューション」の説明

親トピック: Oracle Netアーキテクチャの理解