Oracle Databaseでは、複数のユーザーおよびアプリケーションが同時に1つのデータベース・インスタンスに接続できるように、複数のプロセスを使用しています。
Oracle Databaseでは、インスタンスに接続されているユーザー・プロセスの要求を処理するために、サーバー・プロセスが作成されます。
サーバー・プロセスには、次の2つのプロセスがあります。
専用サーバー・プロセス。単一のユーザー・プロセスのみを処理します。
共有サーバー・プロセス。複数のユーザー・プロセスを処理できます。
データベースでは、専用サーバー・プロセスは常に使用可能な状態ですが、共有サーバーは、1つ以上の初期化パラメータを特別に設定して、構成および使用可能にする必要があります。
専用サーバー・プロセスは、1つのユーザー・プロセスのみを処理します。
図5-1は、専用サーバー・プロセスの仕組みを示しています。この図では、専用サーバー・プロセスを介して、2つのユーザー・プロセスがデータベースに接続されています。
一般的には、共有サーバーを使用し、ディスパッチャを介して接続することをお薦めします。これを図5-2に示します。共有サーバー・プロセスは、実行中のインスタンスに必要なプロセスの数を少なくできるため、効率が向上します。
ただし、次の状況では、ユーザーと管理者は、専用サーバー・プロセスを使用して明示的にインスタンスに接続する必要があります。
バッチ・ジョブを実行する場合(たとえば、ジョブがサーバー・プロセスに対して持つアイドル時間がほとんどないか、まったくない場合)
Recovery Manager(RMAN)を使用して、データベースをバックアップ、リストアまたはリカバリする場合
Oracle Databaseが共有サーバー用に構成されている場合に専用サーバー接続を要求するには、専用サーバーを使用するように構成されているネット・サービス名を使用して接続する必要があります。具体的に言うと、ネット・サービス名の接続記述子にSERVER=DEDICATED
句を含めます。
関連項目:
専用サーバー接続を要求する方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
共有サーバー・プロセスは、複数のユーザー・プロセスを処理できます。
専用サーバー・プロセスを使用した注文入力システムを例にとって考えてみます。顧客が注文受付に電話で商品を注文すると、担当者はその注文をデータベースに入力します。取引のほとんどの間、担当者は顧客と電話で話しています。この間、サーバー・プロセスは必要ないため、担当者のユーザー・プロセス専用のサーバー・プロセスはアイドル状態のままです。アイドル状態のサーバー・プロセスはシステム・リソースを保持しているため、他の担当者が注文を入力する際にシステムのパフォーマンスが低下します。
共有サーバー・アーキテクチャでは、接続ごとに専用サーバー・プロセスは必要ありません(図5-2を参照)。
共有サーバー構成を使用する場合、クライアントのユーザー・プロセスはディスパッチャに接続します。ディスパッチャは複数のクライアント接続を同時にサポートできます。各クライアント接続はバーチャル・サーキットにバインドされており、これはディスパッチャが使用する共有メモリーの1つで、クライアント・データベースの接続要求および応答を目的としています。ディスパッチャは、リクエストが到着するとバーチャル・サーキットを共通キューに配置します。
アイドル状態の共有サーバー・プロセスは、共通キューからバーチャル・サーキットを選択して要求を処理し、そのバーチャル・サーキットを解放して、共通キューから別のバーチャル・サーキットを取り出します。このアプローチでは、小さいサーバー・プロセス・プールで大量のクライアントを処理することが可能です。専用サーバー・モデルと比較した共有サーバー・アーキテクチャの大きな利点は、システム・リソースが少なくて済むため、ユーザー数の増加に対応できることです。
リソース管理をさらに向上させるために、共有サーバーにセッション多重化を構成でき、これにより、オペレーティング・システムのリソースを節約するために、単一のネットワーク接続で通信用の複数のセッションが結合されます。
共有サーバー・アーキテクチャには、Oracle Net Servicesが必要です。共有サーバーを使用するユーザー・プロセスは、Oracle Databaseインスタンスと同じシステム上にある場合でも、必ずOracle Net Servicesを介して接続してください。
関連項目:
セッションの多重化などの機能を含む共有サーバーの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
データベース常駐接続プーリング(DRCP)は、データベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放するような一般的なWebアプリケーション使用に対して、データベース・サーバーの接続プールを提供します。DRCPは専用サーバーをプールします。プール・サーバーは、サーバー・フォアグラウンド・プロセスとデータベース・セッションの組合せに相当します。
DRCPは、中間層プロセス内のスレッド間で接続を共有する中間層接続プールを補完します。また、DRCPを使用すると、同じ中間層ホスト上の中間層プロセス間、および異なる中間層ホスト上の中間層プロセス間でもデータベース接続を共有できます。この結果、大量のクライアント接続をサポートするために必要となる基本データベース・リソースが大幅に減少するため、データベース層のメモリー・フットプリントが縮小し、中間層とデータベース層の両方のスケーラビリティが向上します。すぐに使用できるサーバーのプールを保持することで、クライアント接続の作成と切断のコストが削減されるという利点もあります。
DRCPは、中間層接続プーリングを実行できない(PHP/Apacheなどの)マルチプロセスのシングル・スレッド・アプリケーション・サーバーを含むアーキテクチャに特に適しています。データベースは、DRCPを使用すると同時接続の数を数万まで増やすことができます。
注意:
Windowsプラットフォームでは、SQLNET.AUTHENTICATION_SERVICES
パラメータ値のnts
設定がDRCPでサポートされていません。
関連項目:
DRCPの詳細は、『Oracle Database概要』を参照してください。
DRCPの使用に関する制限事項など、DRCPの詳細は、『Oracle Database開発ガイド』を参照してください。
DRCPセッションを取得する場合に使用できるオプションの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
データベース常駐接続プーリングを使用する場合
データベース常駐接続プーリングは、複数のクライアントがデータベースにアクセスする場合で、次のいずれかに該当する場合に有効です。
大量のクライアント接続を最小限のメモリー使用でサポートする必要がある場合。
複数の類似クライアント・アプリケーションがあり、セッションの共有または再利用が可能な場合。
類似アプリケーションとは、同じデータベース資格証明で接続し、同じスキーマを使用するアプリケーションです。
クライアント・アプリケーションでデータベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放する場合。
クライアント要求にまたがるセッション・アフィニティが必要ない場合。
クライアント側に複数のプロセスおよび複数のホストが存在する場合。
データベース常駐接続プーリングの利点
データベース常駐接続プーリングの使用には次の利点があります。
複数の中間層クライアント・アプリケーション間でリソースを共有できます。
リソース使用量が減少するため、データベースおよびアプリケーションのスケーラビリティが向上します。
データベース常駐接続プーリングおよびLOGON/LOGOFFトリガー
LOGON
トリガーは、DRCPで認証が実施されるたびに、または新規セッションが作成されるたびに起動します。
LOGOFF
トリガーは、DRCPでログオフされるたび、またセッションが破棄されると起動します。このため、LOGOFF
トリガーは、アイドル時間制限のために、セッションが終了すると起動します。
関連項目:
『Oracle Database PL/SQL言語リファレンス』
『Oracle Databaseセキュリティ・ガイド』
専用サーバー、共有サーバーおよびデータベース常駐接続プーリングの相違点を理解します。
表5-1に、専用サーバー、共有サーバーおよびデータベース常駐接続プーリングの相違点を示します。
表5-1 専用サーバー、共有サーバーおよびデータベース常駐接続プーリング
専用サーバー | 共有サーバー | データベース常駐接続プーリング |
---|---|---|
クライアント要求を受け取ると、クライアント用に新規サーバー・プロセスとセッションが作成されます。 |
クライアントから最初の要求を受け取ると、ディスパッチャ・プロセスによって要求が共通キューに入れられます。要求は使用可能な共有サーバー・プロセスによって取り出されます。その後のクライアントと共有サーバー・プロセス間の通信はディスパッチャ・プロセスによって管理されます。 |
クライアントから最初の要求を受け取ると、接続ブローカによって使用可能なプール・サーバーが選択され、そのプール・サーバーにクライアント接続が渡されます。 使用可能なプール・サーバーがない場合は、接続ブローカによって作成されます。プールが最大サイズに達した場合、クライアント要求は、プール・サーバーが使用可能になるまで待機キューに入れられます。 |
データベース・リソースを解放すると、セッションおよびサーバー・プロセスが終了します。 |
データベース・リソースを解放すると、セッションが終了します。 |
データベース・リソースを解放すると、プール・サーバーがプールに解放されます。 |
メモリー要件は、サーバー・プロセスとセッションの数に比例します。クライアントごとに1つのサーバーと1つのセッションが存在します。 |
メモリー要件は、共有サーバーとセッションの合計に比例します。クライアントごとに1つのセッションが存在します。 |
メモリー要件は、プール・サーバーとそのセッションの数に比例します。プール・サーバーごとに1つのセッションが存在します。 |
セッション・メモリーはPGAから割り当てられます。 |
セッション・メモリーはSGAから割り当てられます。 |
セッション・メモリーはPGAから割り当てられます。 |
専用サーバー、共有サーバーおよびデータベース常駐接続プーリングのメモリー使用量の例
各セッションに必要なメモリーが400KB、各サーバー・プロセスに必要なメモリーが4MBであるアプリケーションについて考えます。プール・サイズは100で、使用される共有サーバーの数は100です。
5000のクライアント接続がある場合、各構成で使用されるメモリーは次のようになります。
専用サーバー
使用メモリー = 5000 X (400KB + 4MB) = 22GB
共有サーバー
使用メモリー = 5000 X 400KB + 100 X 4MB = 2.5GB
2.5GBのうち2GBはSGAから割り当てられます。
データベース常駐接続プーリング
使用メモリー = 100 X (400KB + 4MB) + (5000 X 35KB)= 615MB
ブローカへの各接続のコストは、約35KBです。
共有サーバーを有効にし、共有サーバーの初期化パラメータを設定または変更できます。
関連項目:
ALTER
SYSTEM
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
初期化パラメータのセットにより、共有サーバー操作を制御します。
共有サーバー操作を制御する初期化パラメータは、次のとおりです。
SHARED_SERVERS
: 起動する初期共有サーバー数および最低限保持する共有サーバー数を指定します。共有サーバーを使用するための必須パラメータはこのパラメータのみです。
MAX_SHARED_SERVERS
: 同時に実行可能な共有サーバーの最大数を指定します。
SHARED_SERVER_SESSIONS
: 同時に実行可能な共有サーバー・ユーザー・セッションの合計数を指定します。このパラメータを設定すると、専用サーバーのユーザー・セッションを確保することが可能になります。
DISPATCHERS
: 共有サーバー・アーキテクチャのディスパッチャ・プロセスを構成します。
MAX_DISPATCHERS
: 同時に実行できるディスパッチャ・プロセスの最大数を指定します。このパラメータは、現在は無視できます。将来のリリースで、同時接続数によってディスパッチャ数が自動的にチューニングされるようになるまで使用しません。
CIRCUITS
: 受信および発信用のネットワーク・セッションに使用可能なバーチャル・サーキットの合計数を指定します。
関連項目:
これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』
共有サーバーが動作するには、共有プールまたはラージ・プールにユーザー・グローバル領域(UGA)が必要です。同時セッション数が少ないインストールでは、通常、これらのシステム・グローバル領域(SGA)コンポーネントのデフォルト・サイズで十分です。ただし、セッション数が多い場合は、共有サーバーに対応できるようにメモリーをチューニングする必要があります。
ガイドラインは、『Oracle Databaseパフォーマンス・チューニング・ガイド』のメモリーの構成と使用に関する項を参照してください。
共有サーバーを使用可能にするには、SHARED_SERVERS
初期化パラメータに0(ゼロ)より大きい値を設定します。他の共有サーバー初期化パラメータの設定は不要です。
動的に共有サーバーを設定するには、ALTER SYSTEM
文でSHARED_SERVERS
初期化パラメータを0以外の値に設定します。
データベースの起動時にSHARED_SERVERS
初期化パラメータを0以外の値に設定するには、それを初期化パラメータ・ファイルに含めます。
共有サーバーが動作するには最低1つのディスパッチャが必要であるため、構成されていない場合でも、ディスパッチャは起動されます。ディスパッチャについては、「ディスパッチャの構成」を参照してください。
注意:
SHARED_SERVERS
がデータベースの起動時に初期化パラメータ・ファイルに組み込まれていない場合でも、DISPATCHERS
が組み込まれ、少なくとも1つのディスパッチャが指定されていると、共有サーバーは使用可能になります。この場合、SHARED_SERVERS
のデフォルトは1です。
SHARED_SERVERS
とDISPATCHERS
のいずれも初期化ファイルに組み込まれていない場合は、インスタンスが起動された後にDISPATCHERS
パラメータを単に変更しても共有サーバーを起動することはできません。共有サーバーを起動するには、SHARED_SERVERS
を0(ゼロ)以外の値に変更する必要があります。
注意:
Database Configuration Assistant(DBCA)でOracle Databaseを作成した場合、DBCAによってOracle XML DB(XDB)のディスパッチャが構成されます。これは、HTTPやFTPなどのXDBプロトコルには共有サーバーが必要になるためです。これにより、SHARED_SERVER
の値は1になります。共有サーバーは使用可能ですが、この構成では、XDBサービスに接続して共有サーバーを使用できるのは1つのセッションのみです。共有サーバーを標準的なデータベース・セッション(SQL文を発行)に対応できるようにするには、ディスパッチャ構成を追加するか、既存の構成をXDB固有ではない構成に置き換える必要があります。手順については、「ディスパッチャの構成」を参照してください。
SHARED_SERVERS
初期化パラメータは、インスタンスの起動時に作成する共有サーバーの最小数を指定します。インスタンスの起動後は、既存の共有サーバーがビジーになる頻度と要求キューの長さに基づいて、Oracle Databaseが共有サーバーの数を動的に調整します。
標準的なシステムでは、共有サーバーの数は、10接続ごとに共有サーバー1つという割合で安定します。OLTPアプリケーションでは、要求率が低い場合、または要求に対してサーバー使用の比率が低い場合は、接続数/サーバー数の割合が高くなります。対照的に、要求率が高いか、要求に対してサーバー使用の比率が大きいアプリケーションの場合は、接続数/サーバー数の割合が低くなります。
PMON(プロセス・モニター)バックグラウンド・プロセスは、SHARED_SERVERS
で指定された値を下回る状態まで共有サーバーを終了させることはできません。したがって、このパラメータを使用すると、偶発的な負荷の変動のためにPMONが共有サーバーを終了および再起動することがなくなるため、負荷が安定し、システムへの過負荷を最小にできます。
システムの平均的な負荷がわかっている場合は、SHARED_SERVERS
を最適な値に設定できます。次に、このパラメータの使用方法の例を示します。
1000人の従業員が勤務するテレマーケティング・センターでデータベースが使用されているとします。従業員は、平均して勤務時間の90%を顧客との電話応対に費やし、レコードの検索と更新には10%のみ費やしています。従業員が顧客と電話をしている間に共有サーバーが終了し、データベースにアクセスしたときに再び起動することがないように、DBAは最適な共有サーバー数として100を指定しています。
ただし、すべての勤務時間帯で同じ数の従業員が勤務しているわけではありません。夜間の時間帯は200人の従業員で十分です。SHARED_SERVERS
は動的なパラメータであるため、DBAは、夜間の共有サーバーの数を20に減らし、バッチ・ジョブなどの他のタスクにリソースが解放されるようにします。
最低限アクティブに保つ必要がある共有サーバーの数を削減するには、SHARED_SERVERS
パラメータを小さい値に動的に設定します。設定後は、共有サーバー数がSHARED_SERVERS
パラメータの値に減少するまで、非アクティブになる共有サーバーにはPMONによって終了のマークが付けられます。
動的に共有サーバーを設定するには、ALTER SYSTEM
文でSHARED_SERVERS
初期化パラメータを0以外の値に設定します。
たとえば、次の文は、共有サーバーの数を削減します。
ALTER SYSTEM SET SHARED_SERVERS = 5;
SHARED_SERVERS
を0(ゼロ)に設定すると、共有サーバーは使用禁止になります。詳細は、「共有サーバーの無効化」を参照してください。
MAX_SHARED_SERVERS
初期化パラメータは、PMONが自動的に作成可能な共有サーバーの最大数を指定します。デフォルト値はありません。
値が指定されていない場合、PMONは次の制限内で、負荷によって必要とされる共有サーバーを可能なかぎり起動します。
プロセスの制限(PROCESSES
初期化パラメータによって設定)
最小空きプロセス・スロット数(少なくとも総プロセス・スロット数の1/8、またはPROCESSES
が24未満に設定されている場合は2スロット)
システム・リソース
共有サーバーのプロセス数を制限するには:
MAX_SHARED_SERVERS
初期化パラメータを設定します。
SHARED_SERVERS
の値が、MAX_SHARED_SERVERS
の値より優先されます。したがって、SHARED_SERVERS
をMAX_SHARED_SERVERS
より大きい値に設定すると、MAX_SHARED_SERVERS
の値を超える数の共有サーバーをPMONに起動させることができます。その後は、MAX_SHARED_SERVERS
の値をSHARED_SERVERS
より大きい値に動的に変更することで、共有サーバー数に新しい上限を設定できます。
共有サーバー数を制限する主な理由は、メモリーやCPUタイムなどのリソースを他のプロセス用に確保しておくためです。たとえば、前述のテレマーケティング・センターの例について考えてみます。
DBAは、夜間のバッチ・ジョブ用にリソースの2/3を確保しようとします。DBAは、MAX_SHARED_SERVERS
の値を最大プロセス数(PROCESSES
)の1/3より小さい値に設定します。この設定によって、DBAは、すべての従業員がデータベースに同時にアクセスした場合でも、バッチ・ジョブは専用サーバーに接続でき、従業員の要求処理後に共有サーバーが停止するまで待機する必要がないことを確認します。
共有サーバー数を制限するもう1つの理由は、多数のサーバー・プロセスが同時に実行されることによって、大量のスワッピングが発生してシステムの処理速度が低下しないようにするためです。ただし、この場合はMAX_SHARED_SERVERS
よりPROCESSES
が上限として機能します。
この他にも、共有サーバー数を制限する理由として、テスト、デバッグ、パフォーマンス分析およびチューニングがあります。たとえば、特定のユーザー・コミュニティを効率的にサポートするために必要な共有サーバーの数を調べるために、MAX_SHARED_SERVERS
の値を非常に小さい数に設定しておき、ユーザーが応答時間の遅延を認識しない数まで増やすことができます。
SHARED_SERVER_SESSIONS
初期化パラメータは、同時共有サーバー・ユーザー・セッションの最大数を指定します。
動的パラメータであるこのパラメータを設定すると、データベース・セッションを専用サーバー用に確保できます。この結果、データベースのバックアップやリカバリなど、専用サーバーを必要とする管理タスクが共有サーバー・セッションによって専有されることはありません。
共有サーバーのセッション数を制限するには:
SHARED_SERVER_SESSIONS
初期化パラメータを設定します。
このパラメータにデフォルト値はありません。値が指定されていない場合は、SESSIONS
初期化パラメータの制限範囲内で共有サーバー・セッションが必要に応じて作成されます。
DISPATCHERS
初期化パラメータは、共有サーバー・アーキテクチャ内のディスパッチャ・プロセスを構成します。共有サーバーが動作するためには、1つのディスパッチャ・プロセスが最小限必要です。ディスパッチャを指定せずに、SHARED_SERVER
を0(ゼロ)以外の値に設定して共有サーバーを使用可能にすると、デフォルトで、Oracle Databaseによって1つのディスパッチャがTCPプロトコル用に作成されます。
この構成に相当する初期化パラメータDISPATCHERS
の明示的設定は次のとおりです。
dispatchers="(PROTOCOL=tcp)"
次のいずれかの条件に適合する場合は、DISPATCHERS
初期化パラメータを使用して、追加のディスパッチャを構成できます。
TCP/IP以外のプロトコルを構成する必要がある場合。DISPATCHERSパラメータの次のいずれかの属性でプロトコル・アドレスを構成します。
次のオプションのディスパッチャ属性を1つ以上構成する場合。
TCP/IP以外のプロトコルを構成するか、追加のディスパッチャを構成するには:
DISPATCHERS
初期化パラメータを設定し、適切な属性を指定します。
DISPATCHERS
初期化パラメータには、複数の属性を設定できます。
プロトコル・アドレスは必須です。プロトコル・アドレスは次の属性を1つ以上使用して指定します。
属性 | 説明 |
---|---|
|
ディスパッチャがリスニングするエンドポイントのネットワーク・プロトコル・アドレスを指定します。 |
|
ネットワーク・プロトコル・アドレスなど、ディスパッチャがリスニングするエンドポイントのネットワークの説明を指定します。構文は、次のとおりです。 (DESCRIPTION=(ADDRESS=...)) |
|
ディスパッチャによってリスニング・エンドポイントが生成されるネットワーク・プロトコルを指定します。次に例を示します。 (PROTOCOL=tcp) プロトコル・アドレスの構文の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。 |
次の属性は、この構成が使用するディスパッチャ数を指定します。これはオプションで、デフォルトは1です。
属性 | 説明 |
---|---|
|
起動する初期ディスパッチャの数を指定します。 |
次の属性は、構成の各ディスパッチャのネットワーク属性に関する情報をインスタンスに通知します。これらの属性はすべてオプションです。
属性 | 説明 |
---|---|
|
各ディスパッチャに対して許容されるネットワーク接続の最大数を指定します。 |
|
各ディスパッチャに対して許容されるネットワーク・セッションの最大数を指定します。 |
|
LREGプロセスがディスパッチャ情報を登録するリスナーの別名を指定します。ネーミング・メソッドによって解決される別名を設定してください。 |
|
Oracle Connection Managerのセッションの多重化機能を使用可能にする場合に使用します。 |
|
ディスパッチャがリスナーに登録するサービス名を指定します。 |
完全な属性名または先頭の3文字以上で構成されたサブストリングを指定できます。たとえば、SESSIONS=3
、SES=3
、SESS=3
またはSESSI=3
のように指定できます。
関連項目:
DISPATCHERS
初期化パラメータの属性の詳細は、『Oracle Databaseリファレンス』を参照してください。
オペレーティング・システムに対して各プロセスごとに可能な接続数を把握した後、インスタンス起動時に各ネットワーク・プロトコルに対して作成する初期ディスパッチャの数を計算します。
インスタンスの起動時に作成される初期のディスパッチャ数を計算するには、次の式を使用します。
Number of dispatchers = CEIL ( max. concurrent sessions / connections for each dispatcher )
CEIL
は、最も近い整数に切り上げた結果を返します。
たとえば、各プロセスごとに970の接続数をサポートできるシステムがある場合に、次の最大セッション数を仮定します。
TCP/IPを介して最大4,000のセッションが同時に接続します。
SSL付きTCP/IPを介して最大2,500のセッションが同時に接続します。
この場合は、次のように、TCP/IP用のDISPATCHERS
属性には最低で5ディスパッチャ(4000÷970)を、SSL付きTCP/IP用には最低で3ディスパッチャ(2500÷970)を設定する必要があります。
DISPATCHERS='(PROT=tcp)(DISP=5)', '(PROT=tcps)(DISP=3)'
パフォーマンスによっては、ディスパッチャ数の調整が必要となる場合があります。
複数のディスパッチャ構成を指定するには、DISPATCHERS
にカンマ区切りの文字列リストを設定するか、初期化パラメータ・ファイルに複数のDISPATCHERS
初期化パラメータを指定します。
DISPATCHERS
初期化パラメータを設定します。
DISPATCHERS
を複数回指定する場合、各行は初期化パラメータ・ファイル内で互いに隣接している必要があります。内部では、Oracle Databaseによって、INDEX
値(0(ゼロ)から開始)が各DISPATCHERS
パラメータに割り当てられます。このDISPATCHERS
パラメータは、後で、ALTER SYSTEM
文の中で索引番号を使用して参照できます。
次に、DISPATCHERS
初期化パラメータの設定例をいくつか示します。
例: 標準
これは、DISPATCHERS
初期化パラメータの設定の標準的な例です。
DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=2)"
例: ディスパッチャに使用するIPアドレスの強制
次の仮定的な例では、指定されたIPアドレスでリッスンする2つのディスパッチャを作成します。アドレスは、インスタンスが存在するホストの有効なIPアドレスである必要があります。(ホストに複数のIPアドレスを構成できます。)
DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(HOST=144.25.16.201))(DISPATCHERS=2)"
例: ディスパッチャが使用するポートの強制
ディスパッチャが特定のポートをリスニング・エンドポイントとして使用するように強制するには、次のようにPORT
属性を追加します。
DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(PORT=5000))" DISPATCHERS="(ADDRESS=(PROTOCOL=TCP)(PORT=5001))"
インスタンス内のディスパッチャ・プロセスの数を制御できます。共有サーバー数と異なり、ディスパッチャ数は自動的に変更されません。ディスパッチャの数は、明示的にALTER SYSTEM
文で変更します。ディスパッチャ数は、MAX_DISPATCHERS
パラメータで指定された制限を超えて増加することができます。
V$QUEUE
V$DISPATCHER
V$DISPATCHER_RATE
これらのビューによって、ディスパッチャ・プロセスに対する負荷が一貫して高いことが判明した場合は、追加のディスパッチャ・プロセスを起動してユーザー要求をルーティングすることで、パフォーマンスを改善できます。逆に、ディスパッチャの負荷が一貫して低い場合は、ディスパッチャの数を少なくすることにより、パフォーマンスを改善できます。
関連項目:
これらのビューを監視してディスパッチャの負荷とパフォーマンスを判別する方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』
インスタンスの実行中にディスパッチャの数を動的に変更するには、ALTER SYSTEM
文を使用して、既存のディスパッチャ構成に対するDISPATCHERS
属性の設定を変更します。新規のディスパッチャ構成を追加して、異なるネットワーク属性でディスパッチャを起動することもできます。
特定のディスパッチャ構成に対するディスパッチャ数を少なくしても、ディスパッチャが即時に削除されるわけではありません。Oracle Databaseは、ユーザーの切断にあわせてDISPATCHERS
で指定した制限数に達するまでディスパッチャを停止します。
たとえば、初期化パラメータ・ファイルの次のDISPATCHERS
設定でインスタンスが起動されたとします。
DISPATCHERS='(PROT=tcp)(DISP=2)', '(PROT=tcps)(DISP=2)'
TCP/IPプロトコル用のディスパッチャ数を2から3に増やし、SSL付きTCP/IPプロトコル用のディスパッチャ数を2から1に減らすには、次の文を発行します。
ALTER SYSTEM SET DISPATCHERS = '(INDEX=0)(DISP=3)', '(INDEX=1)(DISP=1)';
または
ALTER SYSTEM SET DISPATCHERS = '(PROT=tcp)(DISP=3)', '(PROT=tcps)(DISP=1)';
注意:
(DISP=1
)を指定する必要はありません。1はDISPATCHERS
パラメータのデフォルト値のため、これはオプションです。
現在起動しているTCP/IP用のディスパッチャ・プロセスが2以下の場合は、新しいプロセスが作成されます。SSL付きTCP/IP用のディスパッチャ・プロセスが現在複数起動している場合は、接続ユーザーの切断にあわせて余分なプロセスが停止されます。
ディスパッチャの変更の詳細を理解します。
INDEX
キーワードを使用すると、変更するディスパッチャ構成を識別できます。このINDEX
を指定しないと、指定したDESCRIPTION
、ADDRESS
またはPROTOCOL
と一致する最初のディスパッチャ構成が変更されます。既存のディスパッチャ構成の中で一致するものが見つからなかった場合は、新しいディスパッチャが追加されます。
INDEX
値の範囲は0からn
-1で、n
は現行のディスパッチャ構成の数です。ALTER SYSTEM
文でINDEX
値にn
を指定すると(n
は現行のディスパッチャ構成の数)、新しいディスパッチャ構成が追加されます。
現行のディスパッチャ構成の値、つまり、ディスパッチャの数などを確認するには、V$DISPATCHER_CONFIG
動的パフォーマンス・ビューを問い合せます。ディスパッチャが関連付けられているディスパッチャ構成を確認するには、V$DISPATCHER
ビューのCONF_INDX
列を問い合せます。
ディスパッチャ構成のDESCRIPTION
、ADDRESS
、PROTOCOL
、CONNECTIONS
およびMULTIPLEX
属性を変更しても、その変更は既存のディスパッチャには反映されず、新しいディスパッチャにのみ反映されます。したがって、構成に関連付けられているすべてのディスパッチャに対して変更を反映するには、DISPATCHERS
パラメータを変更した後で、既存のディスパッチャを強制的に停止し、新しく指定したプロパティに配置された新しいディスパッチャをデータベースで起動する必要があります。
LISTENER
属性とSERVICES
属性は、同じ制約の対象となりません。これらの属性は、変更した構成に関連付けられている既存のディスパッチャに適用されます。SESSIONS
属性は、その値が減らされた場合のみ、既存のディスパッチャに適用されます。反対に値が増加された場合は、新しく起動されるディスパッチャにのみ適用されます。
ALTER SYSTEM SET DISPATCHERS
文では、ディスパッチャ数の削減のために停止されるディスパッチャは、データベースによって決定されます。別の方法として、特定のディスパッチャ・プロセスを停止できます。
V$DISPATCHER
動的パフォーマンス・ビューを使用します。SELECT NAME, NETWORK FROM V$DISPATCHER;各ディスパッチャは、Dnnn形式の名前で一意に識別されます。
ALTER SYSTEM SHUTDOWN IMMEDIATE文を実行し、ディスパッチャの名前を指定します。
D002
を停止するには、次の文を発行します。ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002';
IMMEDIATE
キーワードを指定すると、ディスパッチャによる新規接続の受入れが停止し、データベースはそのディスパッチャを介した既存のすべての接続を即時に終了します。すべてのセッションがクリーン・アップされてから、ディスパッチャ・プロセスが停止します。IMMEDIATE
を指定しなかった場合、ディスパッチャは、接続ユーザーがすべて切断され、接続がすべて終了するまで待ってから停止します。共有サーバーを無効にするには、SHARED_SERVERS
を0に設定します。この操作は、ALTER
SYSTEM
文を使用して動的に行うことができます。
SHARED_SERVERS
初期化パラメータを0に設定します。
共有サーバーを無効にすると、新しいクライアントは共有モードで接続できなくなります。ただし、Oracle Databaseではすべての共有サーバーの接続がクローズされるまで一部の共有サーバーが保持されます。保持される共有サーバーの数は、SHARED_SERVERS
の変更前の設定で指定されていた数、またはMAX_SHARED_SERVERS
パラメータの値のいずれか小さい値です。SHARED_SERVERS
とMAX_SHARED_SERVERS
の両方が0(ゼロ)に設定されている場合は、すべての共有サーバーが停止し、残りの共有サーバー・クライアントからの要求は、SHARED_SERVERS
またはMAX_SHARED_SERVERS
の値が再度引き上げられるまでキューで待機します。
ディスパッチャを一度停止して、すべての共有サーバー・クライアントを切断するには、次の文を入力します。
ALTER SYSTEM SET DISPATCHERS = '';
共有サーバーの構成情報およびパフォーマンスの監視のためにデータ・ディクショナリ・ビューを問い合せることができます。
ビュー | 説明 |
---|---|
|
名前、ネットワーク・アドレス、状態、各種使用統計、索引番号などのディスパッチャ・プロセス情報を提供します。 |
|
ディスパッチャに関する構成情報を提供します。 |
|
ディスパッチャ・プロセスのレート統計が含まれています。 |
|
共有サーバー・メッセージ・キューについての情報が含まれています。 |
|
共有サーバーについての情報が含まれています。 |
|
バーチャル・サーキットについての情報が含まれています。バーチャル・サーキットとは、ディスパッチャおよびサーバーを介したデータベースへのユーザー接続です。 |
|
共有サーバーのチューニング情報が含まれています。 |
|
各種のシステム・グローバル領域(SGA)グループに関するサイズ情報が含まれています。この情報は、共有サーバーのチューニング時に役立ちます。 |
|
チューニングに役立つSGA関連の詳細な統計情報が含まれています。 |
|
共有プール内で予約済のプールと領域をチューニングする際に役立つ統計リストが含まれています。 |
関連項目:
共有サーバーの監視とチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』
データベース・サーバーは、データベース常駐接続プーリングを使用できるように事前に構成されています。ただし、この機能は、接続プールを起動して明示的に使用可能にする必要があります。
関連項目:
Oracle Databaseには、SYS_DEFAULT_CONNECTION_POOL
と呼ばれるデフォルトの接続プールがあります。デフォルトでは、このプールは作成されますが起動はされません。データベース常駐接続プーリングを使用可能にするには、接続プールを明示的に起動する必要があります。
データベース常駐接続プーリングを使用可能にする手順は、次のとおりです。
「データベース常駐接続プールの起動」の説明に従って、データベース常駐接続プールを起動します。
「接続プールへのクライアント接続要求のルーティング」の説明に従って、クライアント接続要求を接続プールにルーティングします。
データベース常駐接続プールの起動
接続プールを起動するには:
SQL*Plusを起動して、SYS
ユーザーとしてデータベースに接続します。
次のコマンドを発行します。
SQL> EXECUTE DBMS_CONNECTION_POOL.START_POOL();
起動されると、接続プールは明示的に停止されるまでこの状態のままです。接続プールは、データベース・インスタンスが再起動されると、インスタンスの停止時点でアクティブだった場合は自動的に再起動されます。
Oracle Real Application Clusters(Oracle RAC)環境では、インスタンスを使用して接続プールを管理できます。プール構成に対する変更は、すべてのOracle RACインスタンスで適用されます。
接続プールへのクライアント接続要求のルーティング
クライアント・アプリケーションでは、接続文字列で接続タイプをPOOLED
に指定する必要があります。
次の例は、クライアントをデータベース常駐接続プールに接続する簡単な接続文字列を示しています。
examplehost.company.com:1521/books.company.com:POOLED
次の例は、クライアントをデータベース常駐接続プールに接続するTNS接続記述子を示しています。
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=myhost) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales) (SERVER=POOLED)))
注意:
データベース常駐接続プールへのクライアント接続では、TCPプロトコルのみがサポートされます。データベース常駐接続プーリングを使用禁止にする方法
データベース常駐接続プーリングを使用禁止にするには、接続プールを明示的に停止する必要があります。次の手順を実行します。
注意:
データベース常駐接続プールを使用禁止にする操作は、サーバーに渡されたすべてのクライアント要求が完了しないと完了できません。
接続プールはデフォルトのパラメータ値を使用して構成されます。DBMS_CONNECTION_POOL
パッケージ内のプロシージャを使用すると、使用方法に応じて接続プールを構成できます。Oracle Real Application Clusters(Oracle RAC)環境では、構成パラメータは各Oracle RACインスタンスに適用されます。
CONFIGURE_POOLプロシージャの使用
DBMS_CONNECTION_POOL
パッケージのCONFIGURE_POOL
プロシージャを使用すると、拡張オプションを指定して接続プールを構成できます。このプロシージャは通常、接続プールのすべてのパラメータを変更する必要がある場合に使用します。
ALTER_PARAMプロシージャ
DBMS_CONNECTION_POOL
パッケージのALTER_PARAM
プロシージャを使用すると、特定の構成パラメータを他のパラメータに影響を与えることなく変更できます。たとえば、次のコマンドでは、使用されるプール・サーバーの最小数が変更されます。
SQL> EXECUTE DBMS_CONNECTION_POOL.ALTER_PARAM ('','MINSIZE','10');
次の例では、各接続ブローカで処理できる最大接続数が50000に変更されます。
SQL> EXECUTE DBMS_CONNECTION_POOL.ALTER_PARAM ('','MAXCONN_CBROK','50000');
このコマンドを実行する前に、データベースがインストールされているプラットフォームで許可される最大接続数がMAXCONN_CBROK
に設定した値未満でないことを確認します。
たとえば、Linuxでは、/etc/security/limits.conf
ファイルに次のエントリがあると、ユーザーtest_user
に許可される最大接続数は30000となります。
test_user HARD NOFILE 30000
各接続ブローカで処理できる最大接続数を50000に設定するには、最初にlimits.conf
ファイルの値を50000以上の値に変更します。
接続プールのデフォルト設定のリストア
接続プールのパラメータを変更した後でデフォルトのプール設定に戻す場合は、DBMS_CONNECTION_POOL
パッケージのRESTORE_DEFAULT
プロシージャを使用します。接続プールの設定をデフォルトに戻すコマンドは、次のとおりです。
SQL> EXECUTE DBMS_CONNECTION_POOL.RESTORE_DEFAULTS();
関連項目:
DBMS_CONNECTION_POOL
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
DBMS_CONNECTION_POOL
パッケージ内のサブプログラムのパラメータを指定して、データベース常駐接続プーリングを構成できます。
次の表は、接続プールのために設定できるパラメータを示しています。
表5-2 データベース常駐接続プーリングの構成パラメータ
パラメータ名 | 説明 |
---|---|
|
プール内のプール・サーバーの最小数。デフォルト値は4です。 |
|
プール内のプール・サーバーの最大数。デフォルト値は40です。 接続プールでは、プールされたサーバーの5%が認証のために保持され、少なくとも1つのプールされたサーバーが認証のために常時保持されます。このパラメータを設定する場合は、認証と接続の両方に十分なプール・サーバーがあることを確認します。 |
|
クライアント・アプリケーション要求の受取り時にサーバーが使用可能でない場合にプールが増分されるプール・サーバーの数。デフォルト値は2です。 |
|
各プール・サーバー・セッションでキャッシュするセッション・カーソルの数。デフォルト値は50です。 |
|
プール・サーバーがプールでアイドル状態のままで待機する最大時間(秒数)。この時間を過ぎると、サーバーは終了される。デフォルト値は300です。 このパラメータはプールが |
|
クライアントがプールからプール・サーバーを取得した後で非アクティブ状態でいる最大時間(秒数)。クライアント・アプリケーションが、プールからプール・サーバーを取得した後、 |
|
プール・サーバーがプールから取得されプールに解放される回数。デフォルト値は500000です。 |
|
プール・サーバーがプールに存在している時間(秒数)。デフォルト値は86400です。 |
|
クライアント要求を処理するために作成される接続ブローカの数。デフォルト値は1です。 複数の接続ブローカ・プロセスを作成すると、大量のクライアント・アプリケーションがある場合に、クライアント接続要求の負荷を分散できます。 |
|
各接続ブローカで処理できる最大接続数。 デフォルト値は40000です。ただし、データベースがインストールされているプラットフォームで許可される最大接続がデフォルト値より少ない場合は、
|
関連項目:
DBMS_CONNECTION_POOL
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
接続プールの情報の取得およびデータベース常駐接続プーリングのパフォーマンスの監視のために、データ・ディクショナリ・ビューを問い合せることができます。
表5-3 データベース常駐接続プーリングのデータ・ディクショナリ・ビュー
ビュー | 説明 |
---|---|
|
プール・ステータス、接続の最大数と最小数、アイドル・セッションのタイムアウトなど、接続プールに関する情報が含まれます。 |
|
接続ブローカへの各接続に関する情報が含まれます。 |
|
セッション要求の数、要求と一致するセッションがプールで検出された回数、セッション要求の合計待機時間など、プール統計が含まれます。 |
|
プールのプールと接続クラスとのマッピングに関する情報が含まれます。 |
|
プールの接続クラス・レベルの統計が含まれます。 |
マルチプロセスのOracle Databaseシステムでは、最高のパフォーマンスを提供し、多くのユーザーが同時に使用できるように、バックグラウンド・プロセスが使用されています。バックグラウンド・プロセスでは、ユーザー・プロセスごとに実行される複数のデータベース・プログラムによって処理される機能が統合されます。バックグラウンド・プロセスは、非同期的にI/Oを実行して他のOracle Databaseプロセスを監視することによって、並列性を高め、パフォーマンスと信頼性を向上させます。
表5-4に基礎的なバックグラウンド・プロセスを示しますが、これらの多くはこのドキュメントの他の項で詳細に説明されています。追加のデータベース機能やオプションを使用している場合、これ以外のバックグラウンド・プロセスも実行される場合があります。次に例を示します。
Oracle Databaseアドバンスト・キューイングを使用している場合は、キュー・モニター(QMNn)・バックグラウンド・プロセスが存在します。
データファイルをストレージ・サブシステムの物理デバイスにマッピングするためにFILE_MAPPING
初期化パラメータをtrue
に設定している場合は、FMONプロセスが存在します。
Oracle Automatic Storage Management(Oracle ASM)を使用している場合は、Oracle ASM固有の追加のバックグラウンド・プロセスが存在します。
表5-4 Oracle Databaseバックグラウンド・プロセス
プロセス名 | 説明 |
---|---|
データベース・ライター(DBWnまたはBWnn) |
データベース・ライターは、変更があったブロックをデータベース・バッファ・キャッシュからデータファイルに書き込みます。Oracle Databaseは最高で100のデータベース・ライター・プロセスを行います。最初の36個のデータベース・ライター・プロセスの名前は、DBW0-DBW9およびDBWa-DBWzです。37番目から100番目のデータベース・ライター・プロセスの名前は、BW36-BW99です。 データベース・ライター・プロセスの数は、
|
ログ・ライター(LGWR) |
ログ・ライター・プロセスは、ディスクにREDOログ・エントリを書き込みます。REDOログ・エントリは、システム・グローバル領域(SGA)のREDOログ・バッファに生成される。LGWRは、REDOログ・ファイルにREDOログ・エントリを順番に書き込む。データベースに多重化されたREDOログがある場合、LGWRはREDOログ・ファイルのグループにREDOログ・エントリを書き込む。ログ・ライター・プロセスについては、「REDOログの管理」を参照してください。 |
チェックポイント(CKPT) |
システム・グローバル領域内で変更があったすべてのデータベース・バッファは、特定の時点でDBWnによってデータファイルに書き込まれます。このイベントはチェックポイントと呼ばれます。チェックポイント・プロセスは、最新のチェックポイントを示すために、チェックポイントでDBWnにシグナルを出し、データベースのすべてのデータファイルと制御ファイルを更新する役割を持ちます。 |
システム・モニター(SMON) |
システム・モニターは、障害の発生したインスタンスの再起動時にリカバリを実行します。Oracle Real Application Clustersデータベースでは、1つのインスタンスのSMONプロセスが、障害を起こした他のインスタンスのインスタンス・リカバリを実行できます。また、SMONにより、不要になった一時セグメントがクリーン・アップされ、ファイル読込みエラーやオフライン・エラーのためにシステム障害時やインスタンス・リカバリ時にスキップされた停止後のトランザクションがリカバリされます。これらのトランザクションは、表領域またはファイルがオンラインに戻るときに、SMONによって最後にリカバリされます。 |
プロセス・モニター(PMON) |
プロセス・モニターは、ユーザー・プロセスが失敗したときにプロセス・リカバリを実行します。PMONは、キャッシュをクリーン・アップし、プロセスで使用されていたリソースを解放する役割を持ちます。また、PMONは、ディスパッチャ・プロセス(この表で後述)とサーバー・プロセスをチェックし、障害がある場合は再起動します。 |
アーカイバ(ARCn) |
REDOログ・ファイルは、ログ・ファイルが一杯になるか、ログ・スイッチが発生すると、1つ以上のアーカイバ・プロセスによってアーカイブ記憶域にコピーされます。アーカイバ・プロセスは、「アーカイブREDOログ・ファイルの管理」の主題です。 |
リカバラ(RECO) |
リカバラ・プロセスは、ネットワーク障害やシステム障害が原因で分散データベース内で保留されている分散トランザクションを解決するために使用されます。ローカルRECOは一定周期でリモート・データベースへの接続を試み、保留中の分散トランザクションのローカル部分のコミットまたはロールバックを自動的に完了させる。このプロセスの詳細と開始方法は、「分散トランザクションの管理」を参照してください。 |
ディスパッチャ(Dnnn) |
ディスパッチャはオプションのバックグラウンド・プロセスで、共有サーバー構成の使用時にのみ存在します。共有サーバーの詳細は、前述の「Oracle Databaseの共有サーバー構成」を参照してください。 |
関連項目:
Oracle Databaseバックグラウンド・プロセスの完全なリストは、『Oracle Databaseリファレンス』を参照してください。
SQL文のパラレル処理を管理できます。この構成では、Oracle Databaseは、SQL文の処理作業を複数のパラレル・プロセスに分割できます。
注意:
この項に記載されているパラレル実行機能は、Oracle Database Enterprise Editionで利用できます。
多数のSQL文の実行をパラレル化できます。並列度は、単一の処理に対応付け可能なパラレル実行サーバーの数で表されます。
並列度は、次の要素によって決まります。
文のPARALLEL
句
問合せ内で参照されているオブジェクトの場合は、オブジェクトが作成または変更されたときに使用されたPARALLEL
句
文に挿入されたパラレル・ヒント
データベースによって決定されたデフォルト
SQLのパラレル実行の使用例は、「表作成のパラレル化」を参照してください。
インスタンスが起動すると、Oracle Databaseによって、パラレル操作に使用可能なパラレル実行サーバーのプールが作成されます。パラレル実行コーディネータと呼ばれるプロセスがパラレル実行サーバーのプールの実行をディスパッチし、これらすべてのパラレル実行サーバーからユーザーへの結果の送信を調整します。
PARALLEL_MAX_SERVERS
初期化パラメータのデフォルト値は0(ゼロ)より大きい値に設定されているため、パラレル実行サーバーはデフォルトで使用可能です。これらのプロセスは、並列化を利用できる様々なOracle Databaseの機能によって使用されます。関連する初期化パラメータは、データベースによって大半のユーザー用にチューニングされますが、必要に応じて環境にあわせて変更できます。簡単にチューニングできるように、一部のパラメータは動的に変更できます。
並列化は、トランザクション・リカバリ、レプリケーション、SQL実行など、様々な機能で使用できます。ここで説明しているSQLのパラレル実行の場合、1つの文の実行フェーズ全体を通して、複数のパラレル実行サーバー・プロセスが対応付けられます。文の処理が完了すると、その文に対応付けられていたプロセスが他の文を処理できるようになります。
セッションのSQLのパラレル実行は、ALTER SESSION
文を使用して制御できます。
SQLのパラレル実行は、ALTER SESSION DISABLE PARALLEL DML|DDL|QUERY
文で使用禁止にできます。この文を発行した後は、後続のすべてのDML(INSERT
、UPDATE
、DELETE
)、DDL(CREATE
、ALTER
)または問合せ(SELECT
)操作がシリアルに実行されます。関係する表または索引にパラレル属性が指定されている場合でも、それとは無関係に文はシリアルに実行されます。ただし、PARALLEL
ヒントが指定された文は、セッションの設定を無効にします。
DML、DDLまたは問合せ操作を無効にするために、適切なALTER SESSION DISABLE PARALLEL
文を実行します。
たとえば、パラレルDDL操作を無効にするには、次の文を実行します。
ALTER SESSION DISABLE PARALLEL DDL;
SQLのパラレル実行は、ALTER SESSION ENABLE PARALLEL DML|DDL|QUERY
文で使用可能にできます。その後、PARALLEL
句またはパラレル・ヒントを文に対応付けると、そのDML文、DDL文または問合せ文はパラレルで実行されます。DDL文と問合せ文のパラレル実行はデフォルトで使用可能です。
DML、DDLまたは問合せ操作を有効にするために、適切なALTER SESSION DISABLE PARALLEL
文を実行します。
たとえば、DML文は、ALTER SESSION
文を明示的に発行して、パラレルDMLを使用可能にした場合のみパラレル化できます。
ALTER SESSION ENABLE PARALLEL DML;
ALTER SESSION FORCE PARALLEL DML|DDL|QUERY
文を発行すると、後続のすべてのDML、DDLまたは問合せ文をパラレルで実行するように強制できます。また、特定の並列度を強制的に適用して、後続の文に対応付けられたPARALLEL
句を無効にできます。この文で並列度を指定しなかった場合は、デフォルトの並列度が使用されます。パラレル実行を強制すると、SQL文のパラレル・ヒントが無効になります。
ALTER SESSION FORCE PARALLEL
文を実行します。
たとえば、次の文は、後続の文のパラレル実行を強制し、優先する並列度を5に設定します。
ALTER SESSION FORCE PARALLEL DDL PARALLEL 5;
外部プロシージャは、プログラミング言語で作成され、共有ライブラリに格納されるプロシージャまたはファンクションです。Oracleサーバーは、PL/SQLルーチンを使用して、外部プロシージャまたはファンクションをコールできます。
外部プロシージャはC、C++、Javaなどのプログラミング言語で記述されているプロシージャであり、データベースの外部でコンパイルおよび格納された後、ユーザー・セッションによってコールされます。たとえば、PL/SQLプログラム・ユニットから、特別な用途の処理を実行するのに必要な1つ以上のCルーチンをコールできます。
これらのコール可能ルーチンは、Dynamic Link Library(DLL)またはJavaクラス・メソッドの場合はライブラリ・ユニットに格納されており、ベース言語で登録されています。Oracle Databaseには、コール仕様という特別な用途のインタフェースが用意されており、ユーザーはこのインタフェースを使用して外部プロシージャをコールできます。
ユーザー・セッションによって外部プロシージャが呼び出されると、データベースによって外部プロシージャ・エージェントがデータベースのホスト・コンピュータ上で開始されます。エージェントのデフォルトの名前はextproc
です。各セッションには専用エージェントがあります。必要に応じて、エージェントが特定のオペレーティング・システム・ユーザーとして実行されるよう、資格証明を作成できます。セッションが終了すると、データベースではそのエージェントを終了します。
ユーザー・アプリケーションは、外部プロシージャ・エージェントに対してDLLまたはライブラリ・ユニットの名前、外部プロシージャの名前およびすべての関連するパラメータを渡します。次に、外部プロシージャ・エージェントはDLLまたはライブラリ・ユニットをロードして外部プロシージャを実行し、外部プロシージャから返された値をアプリケーションに返送します。
関連項目:
外部プロシージャの詳細は、『Oracle Database開発ガイド』
外部プロシージャ・コールを有効にするには、リスナーの変更およびライブラリの管理が必要です。
外部プロシージャ・コールを有効にするには、次のDBAタスクが必要となる場合があります。
extproc
エージェントを起動するためのリスナーの構成
デフォルトでは、extproc
はデータベースによって起動されます。次の状況では、リスナーによってextproc
が起動されるように、このデフォルト構成を変更する必要があります。
マルチスレッドのextproc
エージェントを使用する場合
データベースがWindowsにおいて共有サーバー・モードで実行されている場合
LIBRARY
指定のAGENT
句またはPROCEDURE
またはFUNCTION
指定のAGENT
IN
句によって、外部プロシージャが異なるextproc
エージェントにリダイレクトされる場合
デフォルト構成を変更する手順は、『Oracle Database開発ガイド』を参照してください。
ライブラリの管理、またはライブラリの管理に関連のある権限の付与
DLL文には、ライブラリと呼ばれるスキーマ・オブジェクトを経由してアクセスする必要があります。セキュリティを確保するために、デフォルトではDBA
ロールを持つユーザーのみがライブラリを作成および管理できます。このため、次のことを依頼される場合があります。
ライブラリの場所に対してCREATE
DIRECTORY
文を使用して、ディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトの作成後、CREATE
LIBRARY
文を使用して、このディレクトリ・オブジェクトをライブラリの場所に指定できます。
DBMS_CREDENTIAL.CREATE_CREDENTIAL
PL/SQLプロシージャを使用して、資格証明を作成します。資格証明の作成後、CREATE
LIBRARY
文を使用して、extproc
エージェントを特定のオペレーティング・システム・ユーザーとして実行するライブラリに、この資格証明を関連付けることができます。
CREATE
LIBRARY
文を使用して、開発者が必要とするライブラリ・オブジェクトを作成します。
権限CREATE
LIBRARY
、CREATE
ANY
LIBRARY
、ALTER
ANY
LIBRARY
、EXECUTE
ANY
LIBRARY
、EXECUTE
ON
library_name
およびEXECUTE
ON
directory_object
を開発者に付与します。
これらの権限の明示的付与は、信頼できるユーザーに対してのみ行ってください。決してPUBLIC
ロールに対して付与しないでください。ライブラリにPL/SQLインタフェースを作成する場合、EXECUTE
権限のみをPL/SQLインタフェースに付与してください。基礎となるライブラリにEXECUTE
を付与しないでください。PL/SQLインタフェースを作成するには、ライブラリに対するEXECUTE
オブジェクト権限が必要です。ただし、ユーザーは自らのスキーマに対しては自動的にこの権限を持っています。ライブラリに対してEXECUTE
オブジェクト権限を明示的に付与する必要はほとんどりません。
関連項目:
CREATE
LIBRARY
文の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DBMS_CREDENTIAL.CREATE_CREDENTIAL
プロシージャを使用した資格証明の作成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
DBMS_CREDENTIAL
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
Oracle Schedulerジョブでの資格証明の使用の詳細は、「スケジューラ・ジョブの資格証明の指定」
時々、現行のユーザー・セッションを停止する必要があります。たとえば、管理操作を実行する場合に、すべての管理セッション以外のセッションを停止する必要があります。
セッションが停止すると、そのセッションのアクティブ・トランザクションがロールバックされ、そのセッションが保持していたリソース(ロックやメモリー領域など)がただちに解放されて、他のセッションで使用可能になります。
SQL文ALTER SYSTEM KILL SESSION
を使用して、現行のセッションを停止します。次の文は、システム識別子が7でシリアル番号が15のセッションを停止します。
ALTER SYSTEM KILL SESSION '7,15';
DBMS_SERVICE.DISCONNECT_SESSION
プロシージャを使用して、現行インスタンスにおいて指定したサービスからセッションを停止することもできます。
関連項目:
DISCONNECT_SESSION
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
停止するセッションを識別するには、セッションの索引番号とシリアル番号を指定します。
セッションのシステム識別子(SID)とシリアル番号を識別するには:
V$SESSION
動的パスワード・ビューを問い合せます。
たとえば、次の問合せはユーザーjward
のすべてのセッションを識別します。
SELECT SID, SERIAL#, STATUS FROM V$SESSION WHERE USERNAME = 'JWARD'; SID SERIAL# STATUS ----- --------- -------- 7 15 ACTIVE 12 63 INACTIVE
Oracle Databaseに対してSQLコールを実行しているとき、セッションはACTIVE
です。データベースに対してSQLコールを実行していないとき、セッションはINACTIVE
です。
関連項目:
セッションの状態値については、『Oracle Databaseリファレンス』
アクティブなセッションを終了すると、セッションが終了します。
セッションの終了時にユーザー・セッションがトランザクションを処理している場合(STATUSがACTIVE
)、トランザクションはロールバックされ、ユーザーはただちに次のメッセージを受け取ります。
ORA-00028: your session has been killed
ORA-00028
メッセージを受け取った後、データベースに再接続する前に追加の文を実行すると、Oracle Databaseは次のメッセージを返します。
ORA-01012: not logged on
ネットワークI/Oやトランザクションのロールバックを実行している場合は、アクティブ・セッションを中断できません。そのセッションは、操作が完了するまで停止できません。この場合、セッションは、停止するまですべてのリソースを保持します。また、セッションを停止させるためにALTER SYSTEM
文を発行したセッションは、対象のセッションが停止するまで最大60秒待機します。中断できなかった操作が1分経過しても終了しない場合、ALTER SYSTEM
文の発行者は、セッションが停止されることを示すマークが設定されたというメッセージを受け取ります。停止マークが付けられたセッションは、V$SESSION
での状態(STATUS)がKILLED
になり、サーバー(SERVER)がPSEUDO
以外の値になります。
アプリケーション・コンティニュイティを使用している場合、アクティブ・セッションのアクティビティはセッションが終了したときにリカバリされます。セッションの停止後にセッションをリカバリしない場合は、NOREPLAY
キーワードをALTER
SYSTEM
文に組み込むことができます。たとえば、次の文では、セッションをリカバリしないことを指定します。
ALTER SYSTEM KILL SESSION '7,15' NOREPLAY;
DBMS_SERVICE.DISCONNECT_SESSION
プロシージャを使用して1つ以上のセッションを停止する場合、アプリケーション・コンティニュイティによってセッションがリカバリされないように、disconnect_option
パラメータにDBMS_SERVICE.NOREPLAY
を指定できます。たとえば、すべてのセッションをサービスsales.example.com
から切断し、セッションをリカバリしないことを指定するには、次のプロシージャを実行します。
BEGIN DBMS_SERVICE.DISCONNECT_SESSION( service_name => 'sales.example.com', disconnect_option => DBMS_SERVICE.NOREPLAY); END; /
関連項目:
DISCONNECT_SESSION
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
停止時にセッションがOracle Databaseに対してSQLコールを実行していない場合(INACTIVE
)、ORA-00028
のメッセージはただちには返されません。このメッセージは、その後ユーザーが停止したセッションを使用しようとしたときに返されます。
非アクティブ・セッションを停止すると、V$SESSION
ビューのセッションのSTATUS
がKILLED
になります。停止したセッションの行は、ユーザーが再びそのセッションを使用しようとしてORA-00028
メッセージを受け取った後、V$SESSION
から削除されます。
次の例では、非アクティブ・セッションを停止しています。最初にV$SESSION
を問い合せてセッションのSID
とSERIAL#
を識別してから、セッションを停止しています。
SELECT SID,SERIAL#,STATUS,SERVER FROM V$SESSION WHERE USERNAME = 'JWARD'; SID SERIAL# STATUS SERVER ----- -------- --------- --------- 7 15 INACTIVE DEDICATED 12 63 INACTIVE DEDICATED 2 rows selected. ALTER SYSTEM KILL SESSION '7,15'; Statement processed. SELECT SID, SERIAL#, STATUS, SERVER FROM V$SESSION WHERE USERNAME = 'JWARD'; SID SERIAL# STATUS SERVER ----- -------- --------- --------- 7 15 KILLED PSEUDO 12 63 INACTIVE DEDICATED 2 rows selected.
プロセスおよびセッションの情報について一連のデータ・ディクショナリ・ビューを問い合せることができます。
ビュー | 説明 |
---|---|
|
現在アクティブになっているプロセスの情報が含まれています。 |
|
現行のセッションごとにセッション情報がリストされます。 |
|
各ユーザー・セッションのI/O統計情報が含まれています。 |
|
6秒(絶対時間)以上実行されていた各種操作の状態が表示されます。現在、状態が表示される操作は、多数のバックアップおよびリカバリ機能、統計収集および問合せの実行などです。Oracle Databaseのリリースごとにさらに操作が追加されます。 |
|
各セッションの現在または最後の待機が表示されます。 |
|
各アクティブ・セッションの最後の10個の待機イベントがリストされます。 |
|
ブロックされたセッションに関する情報が表示されます。 |
|
システム統計情報が含まれています。 |
|
一部のシステム・リソースについて、現行および最大のグローバル・リソース使用率が表示されます。 |
|
共有SQL領域に関する統計情報が含まれています。SQL文字列ごとに1行ずつ含まれます。メモリー内にあり、解析済で、実行準備のできているSQL文に関する統計情報も提供します。 |