2 データベースの識別とアクセス

データベースの識別方法とクライアントのデータベースへのアクセス方法について説明します。

• データベース・インスタンスの理解
  
• データベース・サービスの理解
  
• データベース・サービスへの接続
  
• サービス・ハンドラの理解
  
• ネーミング・メソッドの理解
  Oracle Net Servicesは、いくつかの種類のネーミング・メソッドを提供しています。これらは、各クライアント上のローカル構成またはネットワーク上のすべてのクライアントがアクセスできる集中化された構成をサポートしています。
• 複数リスナーを使用したサービスのアクセス可能性の拡張
  

2.1 データベース・インスタンスの理解

データベースには1つ以上のインスタンスがあります。インスタンスは、システム・グローバル領域(SGA)と呼ばれるメモリー領域とOracleバックグラウンド・プロセスからなります。インスタンスのメモリーおよびプロセスは、関連付けられたデータベースのデータを効率よく管理し、データベース・ユーザーに提供します。

ノート:

インスタンスは、Oracle XML DBなど、他のサービスも管理します。

次の図では、salesとfinanceという2つのデータベース・インスタンスを示します。各インスタンスは、それぞれのデータベースとサービス名に対応付けられています。

図2-1 各データベースに1つのインスタンス

「図2-1 各データベースに1つのインスタンス」の説明

インスタンスはインスタンス名で識別されます(この例では、salesやfinanceなどです)。インスタンス名は、INSTANCE_NAME初期化パラメータで指定されます。インスタンス名のデフォルトは、データベース・インスタンスのOracleシステム識別子(SID)です。

一部のハードウェア・アーキテクチャでは、複数のコンピュータがデータ、ソフトウェアまたは周辺装置へのアクセスを共有できます。Oracle Real Application Clusters (Oracle RAC)では、単一の物理データベースを共有する異なるコンピュータ上で複数のインスタンスを実行することで、このようなアーキテクチャを活用できます。

次の図では、Oracle RAC構成を示します。この例では、2つのインスタンス、sales1とsales2が1つのデータベース・サービス、sales.us.example.comに対応付けられています。

図2-2 1つのOracle RACデータベースへの複数インスタンスの対応付け

「図2-2 1つのOracle RACデータベースへの複数インスタンスの対応付け」の説明

2.2 データベース・サービスの理解

Oracle Databaseは、クライアントに対してはサービスとして表示されます。データベースには、1つ以上のサービスを対応付けることができます。

次の図では、それぞれが固有のクライアント向けデータベース・サービスを提供する、2つのデータベースを示します。一方のサービスsales.us.example.comでは、販売担当者が販売データベースにアクセスできます。もう一方のサービスfinance.us.example.comでは、財務アナリストが財務データベースにアクセスできます。

図2-3 各データベースに1つのサービス

「図2-3 各データベースに1つのサービス」の説明

販売データベースと財務データベースは、サービス名、sales.us.example.comおよびfinance.us.example.comによってそれぞれ識別されます。サービス名はデータベースの論理表現です。インスタンスを起動すると、インスタンスはそれ自体を1つ以上のサービス名を使用してリスナーに登録します。クライアント・プログラムまたはデータベースがリスナーに接続すると、これらはサービスへの接続を要求します。

サービス名は複数のデータベース・インスタンスを識別することができ、インスタンスは複数のサービスに属することができます。このため、リスナーはクライアントとインスタンスとの間の仲介役を果し、接続要求を適切なインスタンスに渡します。サービスに接続するクライアントは、必要なインスタンスを指定する必要がありません。

サービス名は、サーバー・パラメータ・ファイルのSERVICE_NAMES初期化パラメータで指定します。サーバー・パラメータ・ファイルを使用すると、ALTER SYSTEMコマンドを使用して初期化パラメータを変更でき、変更内容は停止して起動した後も維持されます。DBMS_SERVICEパッケージを使用して、サービスを作成することもできます。サービス名のデフォルトはグローバル・データベース名で、データベース名(DB_NAME初期化パラメータ )およびドメイン名(DB_DOMAIN初期化パラメータ)から構成されています。sales.us.example.comの場合、データベース名はsalesで、ドメイン名はus.example.comです。

ノート:

Oracle Database 19c以降、SERVICE_NAMESパラメータをお客様が使用することは非推奨になりました。サービスを管理するには、SRVCTLまたはGDSCTLコマンドライン・ユーティリティ、またはDBMS_SERVICEパッケージを使用することをお薦めします。

次の図では、1つのデータベースに関連付けられた複数のサービスに接続するクライアントを示します。

図2-4 1つのデータベースへの複数サービスの対応付け

「図2-4 1つのデータベースへの複数サービスの対応付け」の説明

1つのデータベースに複数サービスを対応付けると、次のような機能が得られます。

• 単一のデータベースを、異なる方法であらゆるクライアントが識別できます。

• データベース管理者は、システム・リソースを制限したり、確保できます。このレベルの制御では、これらのサービスの1つを要求するクライアントに、より適切にリソースを割り当てることが可能です。

関連項目:

• 初期化パラメータの詳細は、『Oracle Database管理者ガイド』を参照してください。

• ALTER SYSTEM文の詳細は、『Oracle Database SQLリファレンス』を参照してください。

• SERVICE_NAMESパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

• DBMS_SERVICEパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』 を参照してください。

2.3 データベース・サービスへの接続

データベース・サービスに接続するために、クライアントは、データベースの場所とデータベース・サービスの名前を示す接続記述子を使用します。次の例は、sales.us.example.comというデータベース・サービス、およびホストsales-serverに接続する簡易接続記述子を示しています(デフォルトではポートは1521です)。

sales-server/sales.us.example.com

次の例は、前述の簡易接続記述子およびデータベース・サービスに対するtnsnames.oraファイル内のエントリを示しています。

(DESCRIPTION=
  (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
  (CONNECT_DATA=
    (SERVICE_NAME=sales.us.example.com)))

• 接続記述子について
  
• プロトコル・アドレスについて
  
• サービス登録について
  

関連項目:

「ネーミング・メソッドの理解」

2.3.1 接続記述子について

接続記述子は、tnsnames.oraファイルに記述されている、リスナーの1つまたは複数のプロトコル・アドレスおよび宛先サービスの接続情報により構成されます。例2-1は、salesデータベースにマップされた接続記述子を示しています。

例2-1 接続記述子

sales=
 (DESCRIPTION= 
  (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
  (CONNECT_DATA= 
     (SID=sales)
     (SERVICE_NAME=sales.us.example.com)
     (INSTANCE_NAME=sales)))

例2-1に示すように、接続記述子には次のパラメータが含まれています。

• ADDRESSセクションには次のパラメータがあります。

  • PROTOCOLパラメータは、リスナー・プロトコル・アドレスを識別します。プロトコルは、TCP/IPの場合tcpです。

  • HOSTパラメータは、ホスト名を識別します。ホストはsales-serverです。

  • PORTパラメータは、ポートを識別します。ポートは、デフォルトのポート番号1521です。

  • オプションのHTTPS_PROXYパラメータとHTTPS_PROXY_PORTパラメータにより、データベース・クライアントの接続は組織の転送Webプロキシを通過できるようになります。これらのパラメータは、PROTOCOL=TCPSの接続記述子にのみ適用されます。

• CONNECT_DATAセクションには次のパラメータがあります。

  • SIDパラメータは、Oracle Databaseのシステム識別子(SID)を識別します。SIDはsalesです。

  • SERVICE_NAMEパラメータはサービスを識別します。宛先サービス名は、sales.us.example.comという名前のデータベース・サービスです。

    この接続記述子パラメータの値は、初期化パラメータ・ファイルのSERVICE_NAMES初期化パラメータ(SERVICE_NAMESでは末尾にSが使用されます)から取得されます。一般的にSERVICE_NAMES初期化パラメータは、データベース名とドメイン名が含まれるグローバル・データベース名です。例では、sales.us.example.comには、salesのデータベース名とus.example.comのドメインがあります。

    ノート:

    Oracle Database 19c以降、SERVICE_NAMESパラメータをお客様が使用することは非推奨になりました。サービスを管理するには、SRVCTLまたはGDSCTLコマンドライン・ユーティリティ、またはDBMS_SERVICEパッケージを使用することをお薦めします。

  • INSTANCE_NAMEパラメータはデータベース・インスタンスを識別します。インスタンス名はオプションです。

    初期化パラメータ・ファイルのINSTANCE_NAMEパラメータは、インストール中またはデータベース作成中に入力されたSIDが、デフォルトで設定されます。

• 接続記述子のIPv6アドレスについて
  

関連項目:

「データベース・インスタンスの理解」および「データベース・サービスの理解」

2.3.1.1 接続記述子のIPv6アドレスについて

ホストは、IP version 4 (IPv4)およびIP version 6 (IPv6)インタフェースを使用できます。IPv6アドレスとIPv6アドレスに解決されるホスト名は、TNS接続アドレスのHOSTパラメータで使用すると便利で、このTNS接続アドレスは、表2-*にリストされているサポート対象のNetネーミング・メソッドから取得できます。

IPv6を使用したエンドツーエンド接続には、次の構成が必要です。

• クライアントTNS接続アドレスは、IPv6エンドポイント上のOracle Net Listenerに接続する必要があります。

• Oracle Net Listenerに対して構成されているデータベース・インスタンスは、IPv6エンドポイント上の接続要求をリスニングする必要があります。

ホスト名が指定されている場合、正常な接続が確立されるか、すべてのアドレスが試行されるまで、Oracle Netはドメイン・ネーム・システム(DNS)の名前解決によって戻されるすべてのIPアドレスへの接続を試行します。例2-1で、sales-serverホストはクライアント接続を受け入れるIPv4専用ホストであるとします。DNSはsales-serverを次のIPアドレスにマップします。

1. IPv6アドレス2001:0db8:0:0::200C:417A

2. IPV4アドレス192.0.2.213

この場合、IPv6アドレスがDNSリストの先頭にあるため、Oracle Netはまずこのアドレスで接続を試行します。この例では、sales-serverはIPv6接続をサポートしていないため、この試行は失敗します。Oracle NetはIPv4アドレスへの接続に進み、この試行は成功します。

関連項目:

• 「TCP/IPプロトコルについて」

• 「リスニング用プロトコル・アドレスの構成」

• 「IPv4およびIPv6のブリッジとしてのOracle Connection Managerの使用」

• IPv6のネットワーク接続

2.3.2 プロトコル・アドレスについて

接続記述子のアドレスの一部はリスナーのプロトコル・アドレスです。データベース・サービスに接続するには、クライアントは、まず、データベース・サーバーに常駐しているリスナー・プロセスに接続します。リスナーはクライアントからの着信接続要求を受信し、これらの要求をデータベース・サーバーに送信します。接続が確立された後、クライアントとデータベース・サーバーは直接通信します。

リスナーはクライアントからの要求を受け入れるようにプロトコル・アドレスで設定できます。このアドレスはリスナーがリスニングを実行するプロトコルと、プロトコル固有のその他の情報を定義します。たとえば、リスナーを次のプロトコル・アドレスでリスニングを実行するように設定できます。

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

前の例では、リスナーのホストとポート番号を指定するTCP/IPプロトコル・アドレスを示しています。これと同じプロトコル・アドレスで構成されたクライアント接続記述子は、このリスナーに接続要求を送信できます。

2.3.3 サービス登録について

接続記述子ではデータベース・サービス名を指定し、これを使用してクライアントは接続の確立を試みます。リスナーは接続要求を処理できるサービスを認識しますが、これは、Oracle Databaseがこの情報をリスナーに動的に登録しているためです。この登録プロセスは、サービス登録と呼ばれます。登録によって、データベース・インスタンス、および各インスタンスで利用可能なサービス・ハンドラに関する情報がリスナーに提供されます。ディスパッチャまたは専用サーバーがあります。

• インスタンス名の指定
  
• サービス・ハンドラの指定
  

2.3.3.1 インスタンス名の指定

データベースの特定のインスタンスへの接続が必要な場合、クライアントは特定インスタンスのINSTANCE_NAMEを接続記述子で指定できます。この機能は、Oracle RAC構成を使用する場合に役立ちます。たとえば、次の接続記述子は、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)))

2.3.3.2 サービス・ハンドラの指定

特定のタイプのサービス・ハンドラを常に使用するクライアントは、そのサービス・ハンドラのタイプを指定する接続記述子を使用できます。次の例では、接続記述子は(SERVER=shared)を使用して、データベース接続時にディスパッチャを要求します。デフォルトで専用サーバーを使用するようにデータベースを構成できます。

(DESCRIPTION=
  (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
  (CONNECT_DATA=
    (SERVICE_NAME=sales.us.example.com)
     (SERVER=shared)))

リスナーはクライアントの要求を受け取ると、登録されているサービス・ハンドラの1つを選択します。選択したハンドラのタイプ、使用する通信プロトコル、データベース・サーバーのオペレーティング・システムに基づいて、リスナーは次の処理のいずれかを実行します。

• 接続要求を直接ディスパッチャに渡します。

• ディスパッチャまたは専用サーバー・プロセスの位置情報が記録されたリダイレクト・メッセージをクライアントに戻します。続いてクライアントが、ディスパッチャまたは専用サーバー・プロセスに直接接続します。

• 専用サーバー・プロセスを生成して、クライアント接続を専用サーバー・プロセスに渡します。

リスナーがクライアントとの接続処理を完了すると、クライアントはリスナーを介さずにOracle Databaseと直接通信します。リスナーは、着信ネットワーク・セッションのリスニングを再開します。

サービス・ハンドラを指定する場合は、次の点を考慮する必要があります。

• クライアントに専用サーバーを使用する場合は、(SERVER=dedicated)を指定します。SERVERパラメータが設定されていない場合、共有サーバー構成と見なされます。しかし、利用できるディスパッチャがない場合、クライアントは専用サーバーを使用します。

• データベース常駐接続プーリングがサーバーで有効になっている場合、(SERVER=pooled)を指定してプールから接続を取得します。データベース常駐接続プーリングがサーバーで有効になっていない場合、クライアント要求は拒否され、ユーザーはエラー・メッセージを受け取ります。

関連項目:

• リスナーでサービス・ハンドラを使用する方法は、「リスナーおよび接続要求について」を参照

• 『Oracle Call Interfaceプログラマーズ・ガイド』および『Oracle Database管理者ガイド』を参照してください。

• グローバル・サービス管理の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。

2.4 サービス・ハンドラの理解

サービス・ハンドラは、Oracle Databaseへの接続ポイントとして機能します。サービス・ハンドラには、ディスパッチャまたは専用サーバー・プロセス、またはプールがあります。

• ディスパッチャについて
  
• 専用サーバー・プロセスについて
  
• データベース常駐接続プーリングについて
  

2.4.1 ディスパッチャについて

共有サーバー・アーキテクチャはディスパッチャ・プロセスを使用して、クライアント接続を共通の要求キューに渡します。サーバー・プロセスの共有プールの中のアイドル状態の共有サーバー・プロセスは、共通キューから要求を取り出します。このアプローチでは、小さいサーバー・プロセス・プールで大量のクライアントを処理することが可能です。専用サーバー・モデルと比較した共有サーバー・モデルの大きな利点は、システム・リソースが少なくて済むため、ユーザー数の増加に対応できることです。

リスナーはサービス・ハンドラのタイプとしてディスパッチャを使用しますが、これにクライアント要求を渡すことができます。クライアント要求を受け取ると、リスナーは次のいずれかの処理を実行します。

• 接続要求を直接ディスパッチャに渡します。

• ディスパッチャのプロトコル・アドレスを含むリダイレクト・メッセージをリスナーに発行します。次に、クライアントは、リスナーに要求したネットワーク・セッションを終了し、リダイレクト・メッセージで提供されたネットワーク・アドレスを使用して、ディスパッチャとのネットワーク・セッションを確立します。

リスナーは可能な場合は必ずダイレクト・ハンドオフを使用します。リダイレクト・メッセージは、たとえばディスパッチャがリスナーに対してリモートである場合に使用します。

次の図では、リスナーが接続要求をディスパッチャに直接渡しています。

1. リスナーがクライアント接続要求を受け取ります。

2. リスナーは、接続要求をディスパッチャに直接渡します。

3. クライアントは、ここでディスパッチャに直接接続します。

図2-5 ディスパッチャへのダイレクト・ハンドオフ

「図2-5 ディスパッチャへのダイレクト・ハンドオフ」の説明

次の図では、リダイレクトされた接続におけるディスパッチャの役割を示します。

1. リスナーがクライアント接続要求を受け取ります。

2. リスナーは、ディスパッチャの位置をリダイレクト・メッセージでクライアントに通知します。

3. クライアントがディスパッチャに直接接続します。

図2-6 ディスパッチャにリダイレクトされた接続

「図2-6 ディスパッチャにリダイレクトされた接続」の説明

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

専用サーバー構成では、リスナーはクライアントの着信接続要求ごとに専用サーバー・プロセスを個別に起動します。このプロセスはクライアントへのサービス提供のみを行います。セッション完了後、専用サーバー・プロセスは終了します。専用サーバー・プロセスは接続ごとに起動する必要があるため、共有サーバー構成よりも多くのシステム・リソースが構成に必要になる場合があります。

専用サーバー・プロセスは、クライアント要求を受け取った時にリスナーが開始するサービス・ハンドラのタイプです。クライアント/サーバー接続を完了するには、次のいずれかの処理が発生します。

• 専用サーバーはリスナーから接続要求を継承します。

• 専用サーバーはリスナーにリスニング・プロトコル・アドレスを通知します。リスナーはリダイレクト・メッセージでプロトコル・アドレスをクライアントに渡し、接続を終了します。クライアントは、そのプロトコル・アドレスを使用して、専用サーバーに直接接続します。

前述の処理のどちらかが選択されるかは、オペレーティング・システムおよび使用中のトランスポート・プロトコルによって決まります。

クライアントとデータベースが同じコンピュータ上に存在する場合、クライアント接続は、リスナーを経由せずに専用サーバー・プロセスに直接渡すことができます。これは、bequeathプロトコルとして知られています。セッションを開始するアプリケーションは、接続要求に対する専用サーバー・プロセスを生成します。データベースの起動に使用されるアプリケーションがデータベースと同じコンピュータ上にある場合、この処理は自動的に実行されます。

ノート:

リモート・クライアントが専用サーバーに接続するためには、リスナーとデータベース・インスタンスを同じコンピュータ上で実行する必要があります。

図2-7では、リスナーがクライアント接続要求を専用サーバー・プロセスに渡す様子を示します。

1. リスナーがクライアント接続要求を受け取ります。

2. リスナーは専用サーバー・プロセスを開始し、専用サーバーはリスナーから接続要求を継承します。

3. クライアントがここで専用サーバーに直接接続します。

図2-7 専用サーバー・プロセスへの接続

「図2-7 専用サーバー・プロセスへの接続」の説明

図2-8では、リダイレクト接続における専用サーバーの役割を示します。

1. リスナーがクライアント接続要求を受け取ります。

2. リスナーは専用サーバー・プロセスを開始します。

3. リスナーが専用サーバー・プロセスの位置をリダイレクト・メッセージでクライアントに通知します。

4. クライアントが専用サーバーに直接接続します。

図2-8 専用サーバー・プロセスへのリダイレクト接続

「図2-8 専用サーバー・プロセスへのリダイレクト接続」の説明

2.4.3 データベース常駐接続プーリングについて

データベース常駐接続プーリングは、データベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放するような一般的なWebアプリケーション使用シナリオに対して、データベース・サーバーの接続プールを提供します。データベース常駐接続プーリングは、専用サーバーをプールします。プール・サーバーは、サーバー・フォアグラウンド・プロセスとデータベース・セッションの組合せに相当します。データベース常駐接続プーリングは、サーバーとリスナーの間の動的な登録を使用します。静的な登録を使用することはできません。

データベース常駐接続プーリングは、中間層プロセス内のスレッド間で接続を共有する中間層接続プールを補完します。また、これを使用すると、同じ中間層ホスト上の中間層プロセス間、および異なる中間層ホスト上の中間層プロセス間でもデータベース接続を共有できます。この結果、大量のクライアント接続をサポートするために必要となる基本データベース・リソースが大幅に減少するため、データベース層のメモリー・フットプリントが縮小し、中間層とデータベース層の両方のスケーラビリティが向上します。すぐに使用できるサーバーのプールを保持することで、クライアント接続の作成と切断のコストが削減されるという利点もあります。

データベース常駐接続プーリングは、すべてのクライアント・アプリケーションとプロセスにわたる専用接続のプーリングを提供します。この機能は、データベースへの永続的な接続を維持してサーバー・リソース(メモリーなど)を最適化する必要があるアプリケーションに役立ちます。

データベース常駐接続プールから接続を取得するクライアントは、専用サーバーのかわりにバックグラウンド・プロセス(接続ブローカ)に永続的に接続されます。接続ブローカはプール機能を実装しており、クライアントから専用サーバーのプールへのセッションを使用したインバウンド接続の多重化を実行します。

クライアントがデータベースの作業を実行する必要がある場合、接続ブローカはプールから専用サーバーを選択し、クライアントに割り当てます。その後、クライアントは要求が処理されるまで専用サーバーに直接接続されます。サーバーがクライアント要求の処理を終了した後、サーバーはプールに戻され、クライアントからの接続は接続ブローカに戻されます。

次の図では、そのプロセスを示します。

図2-9 接続ブローカ・プロセスにより接続を処理する専用サーバー・プロセス

「図2-9 接続ブローカ・プロセスにより接続を処理する専用サーバー・プロセス」の説明

2.5 ネーミング・メソッドの理解

Oracle Net Servicesは、いくつかの種類のネーミング・メソッドを提供しています。これらは、各クライアント上のローカル構成またはネットワーク上のすべてのクライアントがアクセスできる集中化された構成をサポートしています。

• ネーミング・メソッドについて
  ネーミング・メソッドとは、データベース・サービスに接続するときに、クライアント・アプリケーションが接続識別子を接続記述子に変換するために使用する解決メソッドです。
• ネーミング・メソッドの選択
  接続記述子に名前をマッピングする適切なネーミング・メソッドの選択は組織の規模によって決まります。
• ネーミング・メソッドを使用したクライアント・セッションの確立
  
• 接続文字列の入力
  ネットワーク・コンポーネントの起動後に、ネットワーク経由の接続を確立できます。接続の確立方法は、ネーミング・メソッドと、接続に使用するツールによって異なります。

2.5.1 ネーミング・メソッドについて

ネーミング・メソッドとは、データベース・サービスに接続するときに、クライアント・アプリケーションが接続識別子を接続記述子に変換するために使用する解決メソッドです。

概要

データベース接続の作成にサービス名を使用する際に必要な情報はリポジトリに格納することができ、1つ以上のネーミング・メソッドで表されます。ユーザーは接続文字列を指定して接続要求を開始します。

接続文字列には、ユーザー名、パスワードおよび接続識別子が含まれます。接続識別子には、接続記述子または接続記述子に解決される名前を使用できます。接続記述子には次のものが含まれます。

• プロトコル・アドレスによるリスナーの位置情報など、サービスへのネットワーク・ルート。

• データベース・サービス名またはOracleシステム識別子(SID)。

次のCONNECTコマンドでは、ネットワーク・サービス名のかわりに、接続識別子として完全な接続記述子を持つ接続文字列を使用しています。1つの行として、文字列を入力する必要があります。ページの幅のために2行で表示されます。

SQL> CONNECT hr@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server1)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales.us.example.com)))

最も一般的な接続識別子の1つは、サービスの単純な名前であるネットワーク・サービス名です。次のCONNECTコマンドでは、接続文字列に、接続識別子としてネットワーク・サービス名salesを使用しています。

SQL> CONNECT hr@sales

ネットワーク・サービス名のsalesを使用すると、salesから接続記述子への最初のマッピングによって、接続処理が実行されます。

ネーミング・メソッドのタイプ

マップされた情報には、ネーミング・メソッドによってアクセスします。次のネーミング・メソッドを利用できます。

• ローカル・ネーミング

• ディレクトリ・ネーミング

• 簡易接続ネーミング

• 簡易接続プラスのネーミング

• 集中化された構成プロバイダのネーミング(Azure App ConfigurationストアまたはOCI Object StorageのJSONファイル)

ネーミング・メソッドの構成方法

ネーミング・メソッドは、次のステップで構成します。

1. ネーミング・メソッドを選択します。

2. 名前または接続識別子に接続記述子をマップします。

3. そのネーミング・メソッドを使用するクライアントを構成します。

2.5.2 ネーミング・メソッドの選択

接続記述子に名前をマッピングする適切なネーミング・メソッドの選択は組織の規模によって決まります。

• データベースが少ない小規模な組織では、簡易接続ネーミングを使用してデータベース・サーバーのホスト名にTCP/IP接続するか、またはローカル・ネーミングを使用してクライアント上のtnsnames.oraファイルに名前を格納します。

• データベースが多い大規模な組織では、ディレクトリ・ネーミングを使用して集中化されたディレクトリ・サーバーに名前を格納するか、集中化された構成プロバイダ・ネーミングを使用して集中化された構成プロバイダに名前を格納します。

• インターネット・ネットワークではローカル・ネーミング・メソッドでデータベースに接続するために必要なアプリケーションWebサーバーを構成します。

ここでは、各ネーミング・メソッドの長所と短所、およびネットワークで使用するための推奨事項を要約します:

ネーミング・メソッド	説明	メリット/デメリット	推奨環境:
ローカル・ネーミング	ネットワーク・サービス名とその接続記述子を、tnsnames.oraという名前のローカルに配置された構成ファイルに格納します(この構成ファイルは、デフォルトではORACLE_BASE_HOMEnetwork/adminディレクトリにあります)。	メリット: ネットワーク・サービス名アドレスを解決する簡単な方法です。 異なるプロトコルを実行しているネットワーク間でネットワーク・サービス名を解決します。 デメリット: すべてのネットワーク・サービス名とアドレス変更をローカル側で構成する必要があります。	ほとんど変更がなくサービス数の少ない単純な分散ネットワーク
ディレクトリ・ネーミング	接続識別子を集中化されたLDAP準拠のディレクトリ・サーバーに格納し、データベース・サービスにアクセスします。	メリット: ネットワーク名とアドレスを1箇所に集中させるため、名前の変更と更新が管理しやすくなります。このため管理者は数百、数千のクライアントに対して変更を行う必要がありません。 ディレクトリはこの他のサービスの名前も格納します。 ツールを使用して簡単に構成ができます。 デメリット: ディレクトリ・サーバーにアクセスする必要があります。	頻繁に変更する大規模で複雑なネットワーク(20以上のデータベースを持つ)
集中化された構成プロバイダのネーミング	接続記述子やデータベース資格証明の参照(オプション)を、Azure App ConfigurationストアやOracle Cloud Infrastructure (OCI) Object Storageなどの集中化された構成プロバイダにJSONファイルとして格納します。	メリット: ネットワーク名とアドレスを1箇所に集中させるため、接続記述子を管理(追加、削除または変更)しやすくします。これにより、管理者が、数百または数千になる可能性がある複数のクライアント接続記述子を変更する必要がなくなります。 たとえば、ローカル・ネーミング・メソッド(tnsnames.ora)または簡易接続ネーミング・メソッドを使用して多数の接続記述子がクライアントに格納されている場合、何か変更があると、これらのクライアント接続記述子をすべて更新する必要があります。 インスタンス・ベースまたは管理対象アイデンティティ・ベースの認証を使用している場合、集中化された構成プロバイダにアクセスするためのパスワードは、Microsoft AzureまたはOCIによって管理されます。 格納されているすべてのデータベース・ユーザー名およびデータベース・パスワードのデータベース・パスワード変更ポリシーを集中管理できます。 デメリット: OCI Object StorageまたはAzure App Configurationサービスへのアクセスが必要です。 インスタンスベース、リソース・プリンシパルベースまたは管理対象アイデンティティ・ベース認証の外部で使用する場合、変更が発生するたびに、接続識別子でクラウド・アクセスのユーザー名とパスワードを変更する必要がある場合があります。	頻繁に変更する大規模で複雑なネットワーク(20以上のデータベースを持つ)
簡易接続ネーミング	クライアントは、ホスト名およびオプションのポート名やサービス名から構成されるTCP/IP接続文字列を使用して、Oracle Databaseサーバーへ接続できるようになります。	メリット: 最小のユーザー構成で済みます。ユーザーは接続を確立するためにデータベース・ホスト名のみを指定します。 簡略ネーミング・メソッドではクライアント側の構成は必要ありません。 ローカル名構成ファイル(tnsnames.ora)の作成とメンテナンスの必要がありません。 デメリット: 推奨環境の欄に示すように使用できる環境に制限があります。	次に示す条件に合致する単純なTCP/IPネットワーク クライアントおよびサーバーはTCP/IPを使用して接続していること。 拡張接続記述子を必要とする機能がないこと。

2.5.3 ネーミング・メソッドを使用したクライアント・セッションの確立

ネーミング・メソッドを使用してクライアント・セッションを確立する代表的なプロセスは、次のとおりです。

1. クライアントは、接続識別子を指定して接続要求を開始します。

2. 接続識別子は、ネーミング・メソッドによって接続記述子に解決されます。

3. クライアントは、接続記述子内に存在するアドレスに対して、接続要求を実行します。

4. リスナーは要求を受け取り、それを該当するデータベース・サーバーに送ります。

5. データベース・サーバーによって、接続が受け入れられます。

ノート:

接続記述子の他にも、ネーミング・メソッドを使用して、接続名をプロトコル・アドレスやプロトコル・アドレス・リストにマッピングできます。

2.5.4 接続文字列の入力

ネットワーク・コンポーネントの起動後に、ネットワーク経由の接続を確立できます。接続の確立方法は、ネーミング・メソッドと、接続に使用するツールによって異なります。

接続文字列は次のような形式です:

CONNECT username@connect_identifier

デフォルトの接続識別子

ほとんどのオペレーティング・システムで、デフォルトの接続識別子を定義できます。デフォルトを使用する場合、接続文字列で接続識別子を指定する必要がなくなります。デフォルトの接続識別子を定義するには、LinuxおよびUNIXプラットフォームの場合は環境変数TWO_TASKを、Microsoft Windowsの場合は環境変数LOCALまたはレジストリ・エントリを使用します。

たとえば、環境変数TWO_TASKにsalesと設定されている場合は、SQL*Plusから、CONNECT username@salesではなくCONNECT usernameを使用してデータベースに接続できます。Oracle NetはTWO_TASK変数を確認し、接続識別子として値salesを使用します。

TWO_TASKおよびLOCAL環境変数の設定方法は、Oracleのオペレーティング・システム固有のマニュアルを参照してください。

接続識別子と接続記述子の構文特性

接続文字列で使用する接続識別子には、一重引用符(')または二重引用符(")で囲む場合を除き、空白を含めることはできません。次の例では、空白を含む接続識別子および接続記述子が一重引用符で囲まれています。

CONNECT scott@'(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales.us.example.com)))'
Enter password: password

CONNECT scott@'cn=sales, cn=OracleContext, dc=us, dc=example, dc=com'
Enter password: password

接続識別子の中で二重引用符(")が使用されている場合は、一重引用符(')で囲みます。たとえば:

CONNECT scott@'sales@"good"example.com'
Enter password: password

接続識別子の中で一重引用符(')が使用されている場合は、二重引用符(")で囲みます。たとえば:

CONNECT scott@"cn=sales, cn=OracleContext, ou=Mary's Dept, o=example"
Enter password: password

Oracle Database接続文字列ユーティリティ

Oracle Database 23c以降では、Oracle Database接続文字列コマンドライン・ユーティリティ(connstr)を使用して、すべての使用可能なネットワーク・サービス名の接続文字列を表示できます。

こうした文字列は、各種の形式(簡易接続、JDBC Thinまたは接続記述子など)で表示できます。また、クライアント・アプリケーションまたはツール(SQL*Plus、PythonまたはJDBC Thinクライアントなど)で使用すると、データベースにすばやく接続できます。また、connstrユーティリティを使用すると、ローカル・ネーミング・メソッドで使用するサービス名およびその接続記述子をtnsnames.oraファイルに書き込むことができます。

たとえば、このユーティリティは、sales.us.example.comサービス名の次の接続記述子を含むtnsnames.oraファイルを生成します:

sales.us.example.com=
    (DESCRIPTION=
        (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
        (CONNECT_DATA=
            (SERVICE_NAME=sales.us.example.com))
    )

クライアント・アプリケーションは、データベースに接続するための接続文字列でsales.us.example.comを次のように使用できます:

sqlplus [e-mail]
Enter password: password

2.6 複数リスナーを使用したサービスのアクセス可能性の拡張

Oracle RACなどの一部の構成では、同じデータベース・サービスへのクライアント接続要求を処理するために、複数のノード上に複数のリスナーを構成できます。次の例では、sales.us.example.comはsales1-serverまたはsales2-serverでリスナーを使用して接続できます。

(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)))

複数のリスナー構成では、フェイルオーバーやロード・バランシング機能も、単独で、あるいはそれぞれを組み合せて有効的に活用できます。

• 接続時フェイルオーバーについて
  
• 透過的アプリケーション・フェイルオーバーについて
  
• クライアント・ロード・バランシングについて
  
• 接続ロード・バランシングについて
  

2.6.1 接続時フェイルオーバーについて

接続時フェイルオーバー機能を使用すると、クライアントは、最初のリスナーへの接続に失敗した場合、別のリスナーに接続できます。接続を試行するリスナーの数は、リスナー・プロトコル・アドレスの数で決まります。接続時フェイルオーバーを実行しない場合、Oracle Netは、1つのリスナーへの接続のみ試行します。

2.6.2 透過的アプリケーション・フェイルオーバーについて

透過的アプリケーション・フェイルオーバー(TAF)機能は、Oracle Real Application Clustersなどの高可用性環境のためのランタイム・フェイルオーバーです。TAFでは、アプリケーションとサービス間の接続のフェイルオーバーおよび再確立を行います。これにより、クライアント・アプリケーションは接続障害の発生時にデータベースに自動的に再接続でき、実行中だったSELECT文を再開することも可能です。この再接続は、Oracle Call Interface(OCI)ライブラリ内から自動的に実行されます。

2.6.3 クライアント・ロード・バランシングについて

クライアント・ロード・バランシング機能によって、クライアントは、複数のリスナー間で接続要求をランダム化できます。Oracle Netは、プロトコル・アドレスのリストを順不同に選択して、複数のリスナーに対する負荷を均衡化します。クライアント・ロード・バランシングを実行しない場合、Oracle Netは、接続が成功するまでプロトコル・アドレスを順番に試行します。

2.6.4 接続ロード・バランシングについて

接続ロード・バランシング機能を利用すると、複数のディスパッチャ間のアクティブな接続数を均衡化することによって、接続時のパフォーマンスが向上します。シングル・インスタンス環境では、リスナーは最も負荷の少ないディスパッチャを選択して、クライアントの着信要求を処理できます。Oracle Real Application Clusters環境では、接続ロード・バランシングによって、複数のインスタンス間のアクティブな接続数を均衡化することも可能です。

サービス登録を動的に行うため、リスナーはすべてのインスタンスとディスパッチャをその場所に関係なく常に認識します。リスナーは、着信したクライアント要求の送信先となるインスタンスを、また共有サーバーが構成されている場合は送信先となるディスパッチャを、ロード情報に応じて判別します。

共有サーバー構成では、リスナーは次の順番でディスパッチャを選択します。

1. ロード量が最小のノード

2. ロード量が最小のインスタンス

3. そのインスタンスのロード量が最小のディスパッチャ

専用サーバー構成では、リスナーは次の順番でインスタンスを選択します。

1. ロード量が最小のノード

2. ロード量が最小のインスタンス

データベース・サービスが複数のノード上に複数のインスタンスを持つ場合、リスナーはロード量が最小のノード上にある、ロード量が最小のインスタンスを選択します。