| Oracle Database Net Services管理者ガイド 11g リリース1（11.1） E05725-04 |
|
 戻る |
 次へ |
この章では、データベースの識別方法とクライアントのデータベースへのアクセス方法を説明します。
この章の内容は、次のとおりです。
この項で説明する項目は、次のとおりです。
Oracleデータベースは、クライアントに対してはサービスとして表示されます。これは、データベースがクライアントにかわって作業を実行することを意味します。データベースには、1つ以上のサービスを対応付けることができます。
図3-1では、2つのデータベースを示します。それぞれがイントラネット・クライアントにデータベース・サービスを独自に提供しています。 一方のサービス、sales.us.example.comでは、販売担当者が販売データベースにアクセスできます。 もう一方のサービス、finance.us.example.comでは、財務アナリストが財務データベースにアクセスできます。
販売データベースと財務データベースは、サービス名、sales.us.example.comおよびfinance.us.example.comによってそれぞれ識別されます。サービス名は、サーバー・パラメータ・ファイルのSERVICE_NAMES初期化パラメータで指定します。
サービス名のデフォルトはグローバル・データベース名です。これは、データベース名（DB_NAME初期化パラメータ）およびドメイン名（DB_DOMAIN初期化パラメータ）から構成される名前です。 サービス名がsales.us.example.comであれば、salesがデータベース名、us.example.comがドメイン名です。
|
注意: SERVICE_NAMESパラメータの値は、データベースの実行時にSQL文のALTER SYSTEMを使用して動的に変更できます。 |
データベースには、複数のサービスを対応付けることができます。図3-2では、Webクライアントに2つの異なるサービスを提供する1つのデータベースを示します。 一方のサービス、book.us.example.comは、書籍を購入するクライアント専用です。 一方のサービス、soft.us.example.comは、ソフトウェアを購入するクライアント専用です。
1つのデータベースに複数サービスを対応付けると、次のような機能が得られます。
単一のデータベースを、様々な方法であらゆるクライアントが識別できます。
データベース管理者は、システム・リソースを制限したり、確保できます。このレベルの制御では、これらのサービスの1つを要求するクライアントに、より適切にリソースを割り当てることが可能です。
データベースには1つ以上のインスタンスがあります。インスタンスは、システム・グローバル領域（SGA）と呼ばれるメモリー領域とOracleバックグラウンド・プロセスからなります。インスタンスのメモリーとプロセスは、関連データベースのデータを効率的に管理し、データベース・ユーザーにサービスを提供します。
図3-3では、salesとfinanceの2つのデータベース・インスタンスを示します。各インスタンスは、それぞれデータベースに対応付けられています。
サービスと同じように、インスタンスはインスタンス名で識別されます。この例では、salesとfinanceです。インスタンス名は、INSTANCE_NAME初期化パラメータによって指定されます。インスタンス名のデフォルトは、そのデータベース・インスタンスのOracleシステム識別子（SID）です。
一部のハードウェア・アーキテクチャでは、複数のコンピュータがデータ、ソフトウェアまたは周辺装置へのアクセスを共有できます。Oracle Real Application Clustersでは、単一の物理データベースを共有する異なるコンピュータ上で複数のインスタンスを実行することで、このようなアーキテクチャを活用できます。
図3-4は、Oracle Real Application Clusters構成を示しています。 この例では、2つのインスタンス、sales1とsales2が1つのデータベース・サービス、sales.us.example.comに対応付けられています。
データベース・サービスに接続するために、クライアントは、データベースの場所とデータベース・サービスの名前を示す接続記述子を使用します。 次の例に示す接続記述子によってクライアントは、sales.us.example.comと呼ばれるデータベース・サービスに接続できます。
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.example.com)))
接続記述子のアドレス部分は、リスナーのプロトコル・アドレスです。データベース・サービスに接続するために、まずクライアントはリスナー・プロセスと通信します。このリスナー・プロセスは、通常データベース・サーバーに常駐しています。リスナーは、クライアントの接続要求を受信して、それをデータベース・サーバーに渡します。いったん接続が確立すると、クライアントとデータベース・サーバーは直接通信します。
ビジネス・アドレスと同様に、リスナーはクライアントからの要求を受け入れるようにプロトコル・アドレスで設定できます。このアドレスはリスナーがリスニングを実行するプロトコルと、プロトコル固有のその他の情報を定義します。たとえば、リスナーを次のプロトコル・アドレスでリスニングを実行するように設定できます。
(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)))
前の例では、リスナーのホストとポート番号を指定するTCP/IPプロトコル・アドレスを示しています。これと同じプロトコル・アドレスで構成されたクライアントは、このリスナーに接続要求を送ります。
接続記述子は、クライアントが接続を確立しようとするデータベース・サービス名も指定します。リスナーは、接続要求を処理できるサービスを認識しています。これは、Oracleデータベースがこの情報をリスナーに動的に登録しているためです。この登録プロセスは、サービス登録と呼ばれます。登録により、リスナーにデータベース・インスタンスに関する情報と、各インスタンスに利用可能なサービス・ハンドラも提供します。サービス・ハンドラは、Oracleデータベース・サーバーへの接続ポイントとして機能します。サービス・ハンドラには、ディスパッチャまたは専用サーバーがあります。
データベースの特定のインスタンスへの接続が必要な場合、クライアントは特定インスタンスのINSTANCE_NAMEを接続記述子で指定できます。この機能は、Oracle Real Application Clusters構成を使用する場合に役立ちます。 たとえば、次の接続記述子は、sales.us.example.comに対応付けられているsales1のインスタンス名を指定しています。
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.example.com)
(INSTANCE_NAME=sales1)))
または、特定のタイプのサービス・ハンドラを常に使用するクライアントは、そのサービス・ハンドラのタイプを指定する接続記述子を使用できます。次の例の接続記述子は、(SERVER=shared)で示すように、共有サーバー構成のディスパッチャを使用するように構成されています。
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.example.com)
(SERVER=shared)))
クライアントに専用サーバーを使用する場合は、(SERVER=shared)のかわりに(SERVER=dedicated)を指定できます。SERVERパラメータが設定されていない場合、共有サーバー構成として判断されます。しかし、利用できるディスパッチャがない場合、クライアントは専用サーバーを使用します。
データベース常駐接続プーリングがサーバーで有効になっている場合、(SERVER=pooled)を指定してプールから接続を取得できます。データベース常駐接続プーリングがサーバーで有効になっていない場合、クライアント要求は拒否されます。
リスナーはクライアントの要求を受け取ると、これまでに登録していたサービス・ハンドラの1つを選択します。選択したハンドラのタイプ、使用する通信プロトコル、データベース・サーバーのオペレーティング・システムに基づいて、リスナーは次の処理のいずれかを実行します。
接続要求を直接ディスパッチャに渡します。
ディスパッチャまたは専用サーバー・プロセスの位置情報が記録されたリダイレクト・メッセージをクライアントに戻します。続いてクライアントが、ディスパッチャまたは専用サーバー・プロセスに直接接続します。
専用サーバー・プロセスを生成して、クライアント接続を専用サーバー・プロセスに渡します。
リスナーがクライアントとの接続処理をいったん完了すると、クライアントはリスナーを介さずにOracleデータベースと通信します。リスナーは、着信ネットワーク・セッションのリスニングを再開します。
|
関連項目:
|
Oracle Real Application Clustersなどの一部の構成では、同じデータベース・サービスへのクライアント接続要求を処理するために、複数のノード上に複数のリスナーを構成できます。 次の例では、sales1-serverまたはsales2-serverのいずれかのリスナーを使用して、sales.us.example.comに接続します。
(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))) (CONNECT_DATA= (SERVICE_NAME=sales.us.example.com)))
複数のリスナー構成では、フェイルオーバーやロード・バランシング機能も、単独で、あるいはそれぞれを組み合せて有効的に活用できます。
接続時フェイルオーバーによって、クライアントは、最初のリスナーへの接続に失敗した場合、別のリスナーに接続できます。接続を試行するリスナーの数は、リスナー・プロトコル・アドレスの数で決まります。接続時フェイルオーバーを実行しない場合、Oracle Netは、1つのリスナーへの接続のみ試行します。
透過的アプリケーション・フェイルオーバー（TAF）機能は、Oracle Real Application Clustersなど、可用性の高い環境に対するランタイム・フェイルオーバーです。TAFはアプリケーションとサービス間接続のフェイルオーバーおよび再確立を行います。接続が失敗した場合、これによってクライアント・アプリケーションは、自動的にデータベースに再接続され、オプションで処理中のSELECT文を再開します。この再接続は、Oracle Call Interface（OCI）ライブラリ内から自動的に実行されます。
クライアント・ロード・バランシング機能によって、クライアントは、複数のリスナー間で接続要求をランダム化できます。Oracle Netは、プロトコル・アドレスのリストを順不同に選択して、複数のリスナーに対する負荷を均衡化します。クライアント・ロード・バランシングを実行しない場合、Oracle Netは、接続が成功するまでプロトコル・アドレスを順番に試行します。
接続ロード・バランシング機能を利用すると、複数のディスパッチャ間のアクティブな接続数を均衡化することによって、接続時のパフォーマンスが向上します。単一インスタンス環境では、リスナーは最も負荷の少ないディスパッチャを選択して、クライアントの着信要求を処理できます。Oracle Real Application Clusters環境では、接続ロード・バランシングによって、複数のインスタンス間のアクティブな接続数を均衡化することも可能です。
サービス登録を動的に行うため、リスナーはすべてのインスタンスとディスパッチャをその場所に関係なく常に認識します。リスナーは、着信したクライアント要求の送信先となるインスタンスを、また共有サーバーが構成されている場合は送信先となるディスパッチャを、ロード情報に応じて判別します。
共有サーバー構成では、リスナーは次の順番でディスパッチャを選択します。
ロード量が最小のノード
ロード量が最小のインスタンス
そのインスタンスのロード量が最小のディスパッチャ
専用サーバー構成では、リスナーは次の順番でインスタンスを選択します。
ロード量が最小のノード
ロード量が最小のインスタンス
データベース・サービスが複数のノード上に複数のインスタンスを持つ場合、リスナーはロード量が最小のノード上にある、ロード量が最小のインスタンスを選択します。共有サーバーが構成されている場合、選択したインスタンスの中でロード量が最小のディスパッチャが選択されます。
この項で説明する項目は、次のとおりです。
共有サーバー・アーキテクチャでは、ディスパッチャ・プロセスを使用して、クライアント接続を共通のリクエスト・キューに入れます。複数のサーバー・プロセスの共有プールの中で、あるアイドル状態の共有サーバー・プロセスが共通キューから要求を取り出します。この方法によって、サーバー・プロセスの小規模プールが大量のクライアントを処理できるようになります。専用サーバー・モデルと比べて共有サーバー・モデルのきわめて有利な点は、システム・リソースの使用が削減されることです。これにより、サポート可能なユーザー数を拡大できます。
リスナーはサービス・ハンドラのタイプとしてディスパッチャを使用しますが、これにクライアント要求を渡すことができます。クライアント要求を受け取ると、リスナーは次のいずれかの処理を実行します。
ディスパッチャのプロトコル・アドレスを含むリダイレクト・メッセージをリスナーに発行します。次に、クライアントは、リスナーに要求したネットワーク・セッションを終了し、リダイレクト・メッセージで提供されたネットワーク・アドレスを使用して、ディスパッチャとのネットワーク・セッションを確立します。
リスナーは可能な場合は必ずDirect Hand-Offを使用します。リダイレクト・メッセージは、たとえばディスパッチャがリスナーに対してリモートである場合に使用します。
図3-5では、リスナーが接続要求をディスパッチャに直接渡す様子を示します。
リスナーがクライアント接続要求を受け取ります。
リスナーは、接続要求をディスパッチャに直接渡します。
クライアントは、ここでディスパッチャに直接接続します。
図3-6では、リダイレクト接続におけるディスパッチャの役割を示します。
リスナーがクライアント接続要求を受け取ります。
リスナーは、ディスパッチャの位置をリダイレクト・メッセージでクライアントに通知します。
クライアントがディスパッチャに直接接続します。
専用サーバー構成では、リスナーは専用サーバー・プロセスを各クライアントの着信接続要求ごとに個別に起動します。このプロセスは、クライアントへのサービス提供のみを行います。一度セッションが完了すると、専用サーバー・プロセスは終了します。専用サーバー・プロセスは各接続ごとに起動する必要があるため、この構成は共有サーバー構成よりも多くのシステム・リソースを必要とします。
専用サーバー・プロセスは、クライアント要求を受け取った時にリスナーが開始するサービス・ハンドラのタイプです。クライアント/サーバー接続の確立が完了すると、次のいずれかの処理が発生します。
専用サーバーはリスナーから接続要求を継承します。
専用サーバーはリスナーにリスニング・プロトコル・アドレスを通知します。リスナーはリダイレクト・メッセージでプロトコル・アドレスをクライアントに渡し、接続を終了します。クライアントは、そのプロトコル・アドレスを使用して、専用サーバーに直接接続します。
|
注意: どちらが選択されるかは、オペレーティング・システムおよび使用中のトランスポート・プロトコルによって決まります。 |
クライアントとデータベースが同じコンピュータ上に存在する場合、クライアント接続は、リスナーを経由せずに専用サーバー・プロセスに直接渡すことができます。セッションを開始するアプリケーションは、接続要求に対する専用サーバー・プロセスを生成します。データベースの起動に使用されるアプリケーションがデータベースと同じコンピュータ上にある場合、この処理は自動的に実行されます。
|
注意: リモート・クライアントが専用サーバーに接続するためには、リスナーとデータベース・インスタンスを同じコンピュータ上で実行する必要があります。 |
図3-7では、リスナーがクライアント接続要求を専用サーバー・プロセスに渡す様子を示します。
リスナーがクライアント接続要求を受け取ります。
リスナーは専用サーバー・プロセスを開始し、専用サーバーはリスナーから接続要求を継承します。
クライアントがここで専用サーバーに直接接続します。
図3-8では、リダイレクト接続における専用サーバーの役割を示します。
複数のプロセスとして
複数のホスト上に
複数のホスト上に複数のプロセスとして
データベース常駐接続プーリングは、クライアント・アプリケーションとプロセス全体に専用接続のプーリングを提供します。この機能は、データベースへの永続的な接続を維持してサーバー・リソース（メモリーなど）を最適化する必要があるアプリケーションに役立ちます。
データベース常駐接続プールから接続を取得するクライアントは、専用サーバーのかわりにバックグラウンド・プロセス（接続ブローカ）に永続的に接続されます。接続ブローカはプール機能を実装しており、クライアントから専用サーバーのプールへのセッションを使用したインバウンド接続の多重化を実行します。
クライアントがデータベースの作業を実行する必要がある場合、接続ブローカはプールから専用サーバーを選択し、クライアントに割り当てます。その後、クライアントは要求が処理されるまで専用サーバーに直接接続されます。サーバーがクライアント要求の処理を終了した後、サーバーはプールに戻され、クライアントからの接続は接続ブローカに戻されます。
図3-9は、プロセスを図で示しています。
ユーザーは接続文字列を指定して接続要求を開始します。 接続文字列には、ユーザー名、パスワードおよび接続識別子が含まれます。接続識別子には、接続記述子または接続記述子に解決される名前を使用できます。
最も一般的な接続識別子の1つは、サービスの単純な名前であるネット・サービス名です。次の例では、CONNECTコマンドで使用する接続文字列に、完全な接続記述子を接続識別子として使用しています。
SQL> CONNECT hr@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=sales-server1)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales.us.example.com)))
Enter password: password
次の例では、CONNECTコマンドで使用する接続文字列に、接続識別子としてネット・サービス名salesを使用しています。
SQL> CONNECT hr@sales
Enter password: password
ネット・サービス名のsalesを使用すると、salesから接続記述子への最初のマッピングによって、接続処理が実行されます。このマップ情報は、ネーミング・メソッドでアクセスされる1つ以上の情報リポジトリに保存されます。
ネーミング・メソッドを利用してクライアント・セッションを確立するためのプロセスは、次のとおりです。
クライアントは、接続識別子を指定して接続要求を開始します。
接続識別子は、ネーミング・メソッドによって接続記述子に解決されます。この情報は、クライアントに戻されます。
クライアントは、接続記述子内に存在するアドレスに対して、接続要求を実行します。
リスナーは要求を受け取り、それを該当するデータベース・サーバーに送ります。
データベース・サーバーによって、接続が受け入れられます。
Oracle Netは、次のネーミング・メソッドをサポートします。
|
注意: 接続記述子の他にも、ネーミング・メソッドを使用して、名前をプロトコル・アドレスやプロトコル・アドレス・リストにマッピングできます。 |
ローカル・ネーミング
ローカル・ネーミング・メソッドは、ネット・サービス名とその接続記述子を、tnsnames.oraという名前のローカルに配置された構成ファイルに格納します。
ディレクトリ・ネーミング
ディレクトリ・ネーミング・メソッドは、接続識別子を集中化されたLDAP準拠のディレクトリ・サーバーに格納し、データベース・サービスにアクセスします。
簡易接続ネーミング
簡易接続ネーミング・メソッドでは、クライアントが、ホスト名およびオプションのポート名やサービス名から構成されるTCP/IP接続文字列を使用して、Oracleデータベース・サーバーへ接続できるようになります。
CONNECT username@[//]host[:port][/service_name][:server][/instance_name]
簡略ネーミング・メソッドでは構成は必要ありません。
外部ネーミング
外部ネーミング・メソッドは、ネット・サービス名を、サポートされる非Oracleネーミング・サービスに格納します。これらサポートされるサード・パーティのサービスには次のものがあります。
分散コンピューティング環境（DCE）セル・ディレクトリ・サービス（CDS）
