ネットワーク・プロトコルを通じてクライアント・アプリケーションから渡された情報は、
データベース・サーバー側にある同様の通信スタックで受信されます。データベース・サー バー側でのプロセス・フローは、クライアント側でのプロセス・フローの逆になり、情報は 通信レイヤーを通ってさかのぼります。
OCIのかわりに、データベース・サーバーはOracleプログラム・インタフェースプログラム・インタフェース（プログラム・インタフェースプログラム・インタフェース OPI）を 使用します。OCIから送信される各文に対して、OPIは応答します。たとえば、OCIが25 行のデータのフェッチを要求すると、OPIはフェッチした25行のデータをOCIに戻します。
Java アプリケーション接続のスタック通信アーキテクチャ アプリケーション接続のスタック通信アーキテクチャ アプリケーション接続のスタック通信アーキテクチャ アプリケーション接続のスタック通信アーキテクチャ
Oracle Java Database Connectivity（（（（JDBC）ドライバ）ドライバ）ドライバ）ドライバにより、Javaアプリケーションは
Oracleデータベースにアクセスします。Oracleには、2つのJDBCドライバが用意されてい
ます。
■ JDBC OCIドライバドライバは、クライアントドライバドライバ /サーバーのJavaアプリケーションで使用される レベル2のJDBCドライバです。JDBC OCIドライバは、JDBCの呼び出しをOCIの呼 び出しに変換します。変換された呼び出しは、Oracle Netを通してOracleデータベー ス・サーバーに送信されます。
■ JDBC Thinドライバドライバドライバドライバは、Javaアプレットが使用するレベル4のドライバです。JDBC Thinドライバは、Javaソケットを通してOracleデータベース・サーバーに直接接続を 確立します。データベースへのアクセスは、TTCとOracle Netの軽量実装に支援され ます。
図4-3では、JDBCドライバが使用するスタック通信レイヤーを示します。
図 図図
図 4-3 Javaクライアント・アプリケーションで使用するレイヤークライアント・アプリケーションで使用するレイヤークライアント・アプリケーションで使用するレイヤークライアント・アプリケーションで使用するレイヤー
JDBC OCIドライバは、標準のクライアント/サーバー通信スタックと同様の通信スタック
を使用します。JDBC Thinドライバは、JavaNetと呼ばれるOracle Net Foundationレイ
ヤーのJava実装と、JavaTTCと呼ばれるTTCのJava実装を使用します。
注意 注意注意
注意: SDPプロトコルはサポートされていますが、この図には含まれて いません。
関連項目 関連項目関連項目
関連項目: 『Oracle9i JDBC開発者ガイドおよびリファレンス』
Oracle Net Servicesのアーキテクチャ 4-9
Web クライアント接続のスタック通信アーキテクチャ クライアント接続のスタック通信アーキテクチャ クライアント接続のスタック通信アーキテクチャ クライアント接続のスタック通信アーキテクチャ
TTCによるプレゼンテーションに加えて、Oracleデータベース・サーバーは、Webクライ アントがデータベース内にアクセスする機能に使用できる、その他の多数のプレゼンテー ションをサポートしています。リスナーは、これを容易にするため、データベースで要求さ れるあらゆるプレゼンテーションをサポートします。
たとえば、図4-4は、Oracle Database 10gインスタンスのOracle XML DBへのHTTP接続 またはFTP接続で使用するスタック通信レイヤーを示しています。WebDAV接続では、
HTTPおよびFTPと同じスタック通信レイヤーが使用されます。
図 図図
図 4-4 Webクライアント接続に使用するレイヤークライアント接続に使用するレイヤークライアント接続に使用するレイヤークライアント接続に使用するレイヤー
関連項目 関連項目関連項目
関連項目: 『Oracle XML DB開発者ガイド』
リスナーのアーキテクチャ リスナーのアーキテクチャ リスナーのアーキテクチャ リスナーのアーキテクチャ
データベース・サーバーは、クライアント・アプリケーションからの初期接続を、リスナー を通じて受け取ります。リスナーはOracle Net Foundationレイヤーの最上位に位置するア プリケーションです。図4-5では、初期接続時のクライアントとデータベース・サーバー上 にある様々なレイヤーを示します。
図図図
図 4-5 初期接続で使用するレイヤー初期接続で使用するレイヤー初期接続で使用するレイヤー初期接続で使用するレイヤー
リスナーは、クライアント要求を受け取ってOracleデータベース・サーバーに渡します。
クライアントがデータベース・サーバーとのネットワーク・セッションを要求するたびに、
リスナーは初期要求を受信します。
各リスナーは、リスニング・エンドポイントを指定する1つ以上のプロトコル・アドレスプロトコル・アドレスプロトコル・アドレスでプロトコル・アドレス 構成されます。これらのプロトコル・アドレスの1つで構成されたクライアントは、そのリ スナーに接続要求を送ります。
リスナーはクライアント要求を受信すると、そのクライアント要求を処理する適切なサービサービサービサービ ス・ハンドラ
ス・ハンドラス・ハンドラ
ス・ハンドラを選択してクライアント要求を転送します。リスナーはデータベース・サービ スとそのサービス・ハンドラが利用可能かどうかを、サービス登録サービス登録サービス登録から判断します。サービサービス登録 ス登録時、インスタンスのバックグラウンド・プロセスであるPMONプロセスプロセスは、次に関プロセスプロセス する情報をリスナーに提供します。
注意注意注意
注意: SDPプロトコルはサポートされていますが、この図には含まれて いません。
Oracle Net Servicesのアーキテクチャ 4-11
■ データベースが提供するデータベース・サービスの名前
■ サービスに対応付けられているインスタンスインスタンスインスタンスの名前と、その現在および最大のロード情報インスタンス
■ インスタンスに使用可能なサービス・ハンドラ（ディスパッチャディスパッチャディスパッチャと専用サーバー）ディスパッチャ 。こ れには、タイプ、プロトコル・アドレス、現在および最大のロード情報が含まれます。
この情報によって、リスナーはクライアントの要求を適切に渡すことができます。図4-6で は、インスタンスがリスナーに情報を登録する様子を示します。登録できるすべての情報を 示しているわけではありません。
図 図図
図 4-6 サービス登録サービス登録サービス登録サービス登録
オプションで、リスニング・エンドポイント、つまりポート番号を、リスナーに動的に登録 できます。たとえば、Oracle XML DB、HTTP、FTPおよびWebDAVのリスニング・エンド ポイントがリスナーに登録されます。
インスタンスの起動時にリスナーが実行していない場合、PMONはサービス情報を登録で きません。PMONは、定期的にリスナーに接続を試みますが、リスナーが起動されてから PMONがリスナーに登録するまで、最大で60秒間遅延することがあります。リスナーの起 動後即座にサービス登録を開始するには、SQL文ALTER SYSTEM REGISTERを使用しま す。これは特に高可用性が求められる構成で有益です。
リスナーが受信した要求を受け取るのが、対応するインスタンスが登録されるより前の場合 は、リスナーは要求を拒否します。
インスタンスが制限されたモードの場合、PMONはリスナーにこのインスタンスへの全接 続をブロックするよう指示します。クライアントが接続しようとすると、次のいずれかのエ ラーが発生します。
■ ORA-12526: TNS:リスナー: 該当するインスタンスはすべて限定モードになってい ます
■ ORA-12527: TNS:リスナー: インスタンスはすべて限定モードになっているか、新 規接続をブロックしています
■ ORA-12528: TNS:リスナー: 該当するインスタンスはすべて、新規接続をブロック しています
4-13ページの図4-7は、HTTP接続を行うブラウザとTTC接続を行うクライアントを使用し て、接続を確立するときのリスナーのロールを示しています。
1. データベースは、サービス、インスタンスおよびサービス・ハンドラに関する情報をリ スナーに登録します。
2. クライアントはリスナーに初期接続を確立します。
3. リスナーはクライアント要求を解析し、要求されたデータベース・サービスのサービ ス・ハンドラに転送します。
関連項目関連項目関連項目
関連項目: エラー・メッセージの詳細は、『Oracle Databaseエラー・
メッセージ』を参照してください。
関連項目 関連項目関連項目 関連項目:
■ ALTER SYSTEM REGISTER文の詳細は、『Oracle Database SQLリ ファレンス』を参照してください。
■ HTTP、FTPおよびWebDAVのリスニング・エンドポイントの動的な
登録の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
Oracle Net Servicesのアーキテクチャ 4-13 図図図
図 4-7 リスナーのアーキテクチャリスナーのアーキテクチャリスナーのアーキテクチャリスナーのアーキテクチャ
データベース・サーバー・プロセス・アーキテクチャ データベース・サーバー・プロセス・アーキテクチャ データベース・サーバー・プロセス・アーキテクチャ データベース・サーバー・プロセス・アーキテクチャ
リスナーに登録されているサービス・ハンドラのタイプに基づいて、リスナーは要求を共有 サーバー・プロセスまたは専用サーバー・プロセスのいずれかに転送します。
共有サーバー・プロセス 共有サーバー・プロセス 共有サーバー・プロセス 共有サーバー・プロセス
共有サーバー・プロセスは、共有サーバー・アーキテクチャで利用されます。4-15ページの 図4-8は、共有サーバー・アーキテクチャを示します。共有サーバー・アーキテクチャでは、
クライアントは最終的にディスパッチャへの接続を行います。PMONプロセスは、ディス パッチャの場所とロード情報をリスナーに登録するため、リスナーは要求を最もロード量の 少ないディスパッチャに転送できます。
ディスパッチャは、複数のクライアント接続を同時にサポートできます。各クライアント接 続は、バーチャル・サーキットバーチャル・サーキットバーチャル・サーキットバーチャル・サーキットにバインドされます。バーチャル・サーキットは、ディス パッチャが使用する共有メモリーの1つで、クライアント・データベースの接続要求および 応答を目的としています。ディスパッチャは、要求が到着するとバーチャル・サーキットを 共通キューに配置する。アイドル状態の共有サーバーは、共通キューからバーチャル・サー キットを取り出して要求を処理し、共通キューから次のバーチャル・サーキットを取り出す 前に、取り出したバーチャル・サーキットを放棄する。この方法によって、サーバー・プロ セスの小規模プールが大量のクライアントを処理できるようになります。