| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
Oracle Databaseでは、インスタンスに接続されているユーザー・プロセスの要求を処理するために、サーバー・プロセスが作成されます。サーバー・プロセスには、次の2つのプロセスがあります。
専用サーバー・プロセス。単一のユーザー・プロセスのみを処理します。
共有サーバー・プロセス。複数のユーザー・プロセスを処理できます。
データベースでは、専用サーバー・プロセスは常に使用可能な状態ですが、共有サーバーは、1つ以上の初期化パラメータを特別に設定して、構成および使用可能にする必要があります。
図5-1「Oracle Databaseの専用サーバー・プロセス」は、専用サーバー・プロセスの動作の仕組みを示しています。この図では、専用サーバー・プロセスを介して、2つのユーザー・プロセスがデータベースに接続されています。
一般的には、共有サーバーを使用し、ディスパッチャを介して接続することをお薦めします。これは、図5-2「Oracle Databaseの共有サーバー・プロセス」に図示されています。共有サーバー・プロセスは、実行中のインスタンスに必要なプロセスの数を少なくできるため、効率が向上します。
ただし、次の状況では、ユーザーと管理者は、専用サーバー・プロセスを使用して明示的にインスタンスに接続する必要があります。
バッチ・ジョブを実行する場合(たとえば、ジョブがサーバー・プロセスに対して持つアイドル時間がほとんどないか、まったくない場合)
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でサポートされていません。 |
|
関連項目:
|
データベース常駐接続プーリングを使用する場合
データベース常駐接続プーリングは、複数のクライアントがデータベースにアクセスする場合で、次のいずれかに該当する場合に有効です。
大量のクライアント接続を最小限のメモリー使用でサポートする必要がある場合。
複数の類似クライアント・アプリケーションがあり、セッションの共有または再利用が可能な場合。
類似アプリケーションとは、同じデータベース資格証明で接続し、同じスキーマを使用するアプリケーションです。
クライアント・アプリケーションでデータベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放する場合。
クライアント要求にまたがるセッション・アフィニティが必要ない場合。
クライアント側に複数のプロセスおよび複数のホストが存在する場合。
データベース常駐接続プーリングの使用には次の利点があります。
複数の中間層クライアント・アプリケーション間でリソースを共有できます。
リソース使用量が減少するため、データベースおよびアプリケーションのスケーラビリティが向上します。
データベース常駐接続プーリングおよびLOGON/LOGOFFトリガー
LOGONトリガーは、DRCPで認証が実施されるたびに、または新規セッションが作成されるたびに起動します。
LOGOFFトリガーは、DRCPでログオフされるたび、またセッションが破棄されると起動します。このため、LOGOFFトリガーは、アイドル時間制限のために、セッションが終了すると起動します。
|
関連項目:
|
表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です。
プール・サーバーを使用して接続されている場合、次の処理を実行することはできません。
データベースの停止
データベース常駐接続プールの停止
接続済ユーザーのパスワードの変更
データベース常駐接続プールへの共有データベース・リンクを使用した接続
暗号化、証明書など、アドバンスト・セキュリティ・オプション(ASO)のオプションの使用
OCI_MIGRATEオプションを使用した直接的な、またはOCIConnectionPoolを介した間接的なサーバー側での移行可能セッションの使用
プール内のDDL前のセッションはまだDDL後のクライアントに渡される可能性があるため、プール内のデータベース・ユーザーに関係するDDL文の実行には注意が必要です。たとえば、ユーザーを削除する場合、そのユーザーのセッションがプール内に存在せず、そのユーザーとして認証されたブローカへの接続がないことを確認します。
明示的なロールが使用可能であり、プールに解放されるセッションは、後でデフォルトのログイン・ロールを必要とする(同じユーザーの)接続に渡される可能性があります。明示的なロールのあるセッションは解放せずに、かわりにセッションを終了してください。
この項では、共有サーバーを使用可能にする方法、および共有サーバーの初期化パラメータを設定または変更する方法を説明します。内容は次のとおりです。
共有サーバー操作を制御する初期化パラメータは、次のとおりです。
SHARED_SERVERS: 起動する初期共有サーバー数および最低限保持する共有サーバー数を指定します。共有サーバーを使用するための必須パラメータはこのパラメータのみです。
MAX_SHARED_SERVERS: 同時に実行可能な共有サーバーの最大数を指定します。
SHARED_SERVER_SESSIONS: 同時に実行可能な共有サーバー・ユーザー・セッションの合計数を指定します。このパラメータを設定すると、専用サーバーのユーザー・セッションを確保することが可能になります。
DISPATCHERS: 共有サーバー・アーキテクチャのディスパッチャ・プロセスを構成します。
MAX_DISPATCHERS: 同時に実行できるディスパッチャ・プロセスの最大数を指定します。このパラメータは、現在は無視できます。将来のリリースで、同時接続数によってディスパッチャ数が自動的にチューニングされるようになるまで使用しません。
CIRCUITS: 受信および発信用のネットワーク・セッションに使用可能なバーチャル・サーキットの合計数を指定します。
|
関連項目: これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
共有サーバーが動作するには、共有プールまたはラージ・プールにユーザー・グローバル領域(UGA)が必要です。同時セッション数が少ないインストールでは、通常、これらのシステム・グローバル領域(SGA)コンポーネントのデフォルト・サイズで十分です。ただし、セッション数が多い場合は、共有サーバーに対応できるようにメモリーをチューニングする必要があります。
ガイドラインは、『Oracle Databaseパフォーマンス・チューニング・ガイド』のメモリーの構成と使用に関する項を参照してください。
共有サーバーを使用可能にするには、SHARED_SERVERS初期化パラメータに0(ゼロ)より大きい値を設定します。他の共有サーバー初期化パラメータの設定は不要です。共有サーバーが動作するには最低1つのディスパッチャが必要であるため、構成されていない場合でも、ディスパッチャは起動されます。ディスパッチャについては、「ディスパッチャの構成」を参照してください。
共有サーバーを動的に起動するには、ALTER SYSTEM文を使用してSHARED_SERVERSパラメータに0(ゼロ)以外の値を設定するか、またはデータベースの起動時にSHARED_SERVERSを初期化パラメータ・ファイルに組み込みます。SHARED_SERVERSが初期化パラメータ・ファイルに組み込まれていない場合、または値が0(ゼロ)に設定されている場合、共有サーバーはデータベースの起動時に使用可能になりません。
|
注意: SHARED_SERVERSがデータベースの起動時に初期化パラメータ・ファイルに組み込まれていない場合でも、DISPATCHERSが組み込まれ、少なくとも1つのディスパッチャが指定されていると、共有サーバーは使用可能になります。この場合、SHARED_SERVERSのデフォルトは1です。
|
|
注意: 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 SET SHARED_SERVERS = 5;
SHARED_SERVERSを0(ゼロ)に設定すると、共有サーバーは使用禁止になります。詳細は、「共有サーバーの使用禁止」を参照してください。
MAX_SHARED_SERVERSパラメータは、PMONによって自動的に作成される共有サーバーの最大数を指定します。デフォルト値はありません。値が指定されていない場合、PMONは次の制限内で、負荷によって必要とされる共有サーバーを可能なかぎり起動します。
プロセスの制限(PROCESSES初期化パラメータによって設定)
最小空きプロセス・スロット数(少なくとも総プロセス・スロット数の1/8、またはPROCESSESが24未満に設定されている場合は2スロット)
システム・リソース
|
注意: Windows NTの場合、各サーバーは共通プロセス内のスレッドであるため、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の値を非常に小さい数に設定しておき、ユーザーが応答時間の遅延を認識しない数まで増やすことができます。
DISPATCHERS初期化パラメータは、共有サーバー・アーキテクチャ内のディスパッチャ・プロセスを構成します。共有サーバーが動作するためには、最低1つのディスパッチャ・プロセスが必要です。ディスパッチャを指定せずに、SHARED_SERVERを0(ゼロ)以外の値に設定して共有サーバーを使用可能にすると、デフォルトで、Oracle Databaseによって1つのディスパッチャがTCPプロトコル用に作成されます。この構成に相当する初期化パラメータDISPATCHERSの明示的設定は次のとおりです。
dispatchers="(PROTOCOL=tcp)"
次のいずれかの条件に適合する場合は、DISPATCHERS初期化パラメータを使用して、追加のディスパッチャを構成できます。
TCP/IP以外のプロトコルを構成する必要がある場合。DISPATCHERSパラメータの次のいずれかの属性でプロトコル・アドレスを構成します。
次のオプションのディスパッチャ属性を1つ以上構成する場合。
この項では、DISPATCHERS初期化パラメータで指定可能な属性について簡単に説明します。
プロトコル・アドレスは必須です。プロトコル・アドレスは次の属性を1つ以上使用して指定します。
次の属性は、この構成が使用するディスパッチャ数を指定します。これはオプションで、デフォルトは1です。
次の属性は、構成の各ディスパッチャのネットワーク属性に関する情報をインスタンスに通知します。これらの属性はすべてオプションです。
完全な属性名または先頭の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を複数回指定する場合、各行は初期化パラメータ・ファイル内で互いに隣接している必要があります。内部では、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文で変更します。このリリースのOracle Databaseでは、ディスパッチャ数をMAX_DISPATCHERSパラメータで指定された制限よりも大きい数に増加できます。MAX_DISPATCHERSは将来のリリースで考慮される予定です。
次のビューを監視し、ディスパッチャ・プロセスの負荷を判別します。
|
関連項目: これらのビューを監視してディスパッチャの負荷とパフォーマンスを判別する方法については、『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用のディスパッチャ・プロセスが現在複数起動している場合は、接続ユーザーの切断にあわせて余分なプロセスが停止されます。
TCP/IPプロトコル用のディスパッチャ数は変更しないで、接続プーリングをサポートする別のTCP/IPディスパッチャを追加すると仮定します。この場合は次の文を入力します。
ALTER SYSTEM SET DISPATCHERS = '(INDEX=2)(PROT=tcp)(POOL=on)';
INDEX属性は、新規ディスパッチャ構成を追加するために必要です。前述の文で(INDEX=2)を省略すると、INDEX 0のTCP/IPディスパッチャ構成が接続プーリングをサポートするように変更され、その構成に対するディスパッチャ数が、ディスパッチャ数(属性DISPATCHERS)が指定されていない場合のデフォルトである1に減らされます。
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、TICKS、MULTIPLEXおよびPOOL属性を変更しても、その変更は既存のディスパッチャには反映されず、新しいディスパッチャにのみ反映されます。したがって、構成に関連付けられているすべてのディスパッチャに対して変更を反映するには、DISPATCHERSパラメータを変更した後で、既存のディスパッチャを強制的に停止し、新しく指定したプロパティに配置された新しいディスパッチャをデータベースで起動する必要があります。
LISTENER属性とSERVICES属性は、同じ制約の対象となりません。これらの属性は、変更した構成に関連付けられている既存のディスパッチャに適用されます。SESSIONS属性は、その値が減らされた場合のみ、既存のディスパッチャに適用されます。反対に値が増加された場合は、新しく起動されるディスパッチャにのみ適用されます。
ALTER SYSTEM文では、ディスパッチャを停止してディスパッチャの数を少なくする判断は、データベースが行います。別の方法として、特定のディスパッチャ・プロセスを停止できます。停止するディスパッチャ・プロセスの名前を識別するには、V$DISPATCHER動的パフォーマンス・ビューを使用します。
SELECT NAME, NETWORK FROM V$DISPATCHER;
各ディスパッチャは、Dnnn形式の名前で一意に識別されます。
ディスパッチャD002を停止するには、次の文を発行します。
ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002';
IMMEDIATEキーワードを指定すると、ディスパッチャによる新規接続の受入れが停止し、データベースはそのディスパッチャを介した既存のすべての接続を即時に終了します。すべてのセッションがクリーン・アップされてから、ディスパッチャ・プロセスが停止します。IMMEDIATEを指定しなかった場合、ディスパッチャは、接続ユーザーがすべて切断され、接続がすべて終了するまで待ってから停止します。
共有サーバーを無効にするには、SHARED_SERVERSを0に設定します。この操作は、ALTER SYSTEM文を使用して動的に行うことができます。共有サーバーを無効にすると、新しいクライアントは共有モードで接続できなくなります。ただし、Oracle Databaseではすべての共有サーバーの接続がクローズされるまで一部の共有サーバーが保持されます。保持される共有サーバーの数は、SHARED_SERVERSの変更前の設定で指定されていた数、またはMAX_SHARED_SERVERSパラメータの値のいずれか小さい値です。SHARED_SERVERSとMAX_SHARED_SERVERSの両方が0(ゼロ)に設定されている場合は、すべての共有サーバーが停止し、残りの共有サーバー・クライアントからの要求は、SHARED_SERVERSまたはMAX_SHARED_SERVERSの値が再度引き上げられるまでキューで待機します。
ディスパッチャを一度停止して、すべての共有サーバー・クライアントを切断するには、次の文を入力します。
ALTER SYSTEM SET DISPATCHERS = '';
次のビューは、共有サーバー構成情報の取得やパフォーマンスの監視に使用できます。
| ビュー | 説明 |
|---|---|
V$DISPATCHER |
名前、ネットワーク・アドレス、状態、各種使用統計、索引番号などのディスパッチャ・プロセス情報を提供します。 |
V$DISPATCHER_CONFIG |
ディスパッチャに関する構成情報を提供します。 |
V$DISPATCHER_RATE |
ディスパッチャ・プロセスのレート統計が含まれています。 |
V$QUEUE |
共有サーバー・メッセージ・キューについての情報が含まれています。 |
V$SHARED_SERVER |
共有サーバーについての情報が含まれています。 |
V$CIRCUIT |
バーチャル・サーキットについての情報が含まれています。バーチャル・サーキットとは、ディスパッチャおよびサーバーを介したデータベースへのユーザー接続です。 |
V$SHARED_SERVER_MONITOR |
共有サーバーのチューニング情報が含まれています。 |
V$SGA |
各種のシステム・グローバル領域(SGA)グループに関するサイズ情報が含まれています。この情報は、共有サーバーのチューニング時に役立ちます。 |
V$SGASTAT |
チューニングに役立つSGA関連の詳細な統計情報が含まれています。 |
V$SHARED_POOL_RESERVED |
共有プール内で予約済のプールと領域をチューニングする際に役立つ統計リストが含まれています。 |
|
関連項目:
|
データベース・サーバーは、データベース常駐接続プーリングを使用できるように事前に構成されています。ただし、この機能は、接続プールを起動して明示的に使用可能にする必要があります。
この項の内容は次のとおりです。
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)))
データベース常駐接続プーリングを使用禁止にするには、接続プールを明示的に停止する必要があります。次の手順を実行します。
SQL*Plusを起動して、SYSユーザーとしてデータベースに接続します。
次のコマンドを発行します。
SQL> EXECUTE DBMS_CONNECTION_POOL.STOP_POOL();
|
関連項目: DBMS_CONNECTION_POOLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』 |
|
注意: データベース常駐接続プールを使用禁止にする操作は、サーバーに渡されたすべてのクライアント要求が完了しないと完了できません。 |
接続プールはデフォルトのパラメータ値を使用して構成されます。DBMS_CONNECTION_POOLパッケージ内のプロシージャを使用すると、使用方法に応じて接続プールを構成できます。Oracle Real Application Clusters(Oracle RAC)環境では、構成パラメータは各Oracle RACインスタンスに適用されます。
表5-2に、接続プール用に構成可能なパラメータを示します。
表5-2 データベース常駐接続プーリングの構成パラメータ
| パラメータ名 | 説明 |
|---|---|
|
|
プール内のプール・サーバーの最小数。デフォルト値は4です。 |
|
|
プール内のプール・サーバーの最大数。デフォルト値は40です。 接続プールでは、プールされたサーバーの5%が認証のために保持され、少なくとも1つのプールされたサーバーが認証のために常時保持されます。このパラメータを設定する場合は、認証と接続の両方に十分なプール・サーバーがあることを確認します。 |
|
|
クライアント・アプリケーション要求の受取り時にサーバーが使用可能でない場合にプールが増分されるプール・サーバーの数。デフォルト値は2です。 |
|
|
各プール・サーバー・セッションでキャッシュするセッション・カーソルの数。デフォルト値は50です。 |
|
|
プール・サーバーがプールでアイドル状態のままで待機する最大時間(秒数)。この時間を過ぎると、サーバーは終了される。デフォルト値は300です。 このパラメータはプールが |
|
|
クライアントがプールからプール・サーバーを取得した後で非アクティブ状態でいる最大時間(秒数)。クライアント・アプリケーションが、プールからプール・サーバーを取得した後、 |
|
|
プール・サーバーがプールから取得されプールに解放される回数。デフォルト値は500000です。 |
|
|
プール・サーバーがプールに存在している時間(秒数)。デフォルト値は86400です。 |
|
|
クライアント要求を処理するために作成される接続ブローカの数。デフォルト値は1です。 複数の接続ブローカ・プロセスを作成すると、大量のクライアント・アプリケーションがある場合に、クライアント接続要求の負荷を分散できます。 |
|
|
各接続ブローカで処理できる最大接続数。 デフォルト値は40000です。ただし、データベースがインストールされているプラットフォームで許可される最大接続がデフォルト値より少ない場合は、
|
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パッケージおよびタイプ・リファレンス』 |
表5-3に、データベース常駐接続プーリングに関する情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューを使用すると、接続プールに関する情報を取得し、データベース常駐接続プーリングのパフォーマンスを監視できます。
表5-3 データベース常駐接続プーリングのデータ・ディクショナリ・ビュー
| ビュー | 説明 |
|---|---|
|
|
プール・ステータス、接続の最大数と最小数、アイドル・セッションのタイムアウトなど、接続プールに関する情報が含まれます。 |
|
|
接続ブローカへの各接続に関する情報が含まれます。 |
|
|
セッション要求の数、要求と一致するセッションがプールで検出された回数、セッション要求の合計待機時間など、プール統計が含まれます。 |
|
|
プールの接続クラス・レベルの統計が含まれます。 |
|
関連項目: これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
マルチプロセスのOracle Databaseシステムでは、最高のパフォーマンスを提供し、多くのユーザーが同時に使用できるように、バックグラウンド・プロセスが使用されています。バックグラウンド・プロセスでは、ユーザー・プロセスごとに実行される複数のデータベース・プログラムによって処理される機能が統合されます。バックグラウンド・プロセスは、非同期的にI/Oを実行して他のOracle Databaseプロセスを監視することによって、並列性を高め、パフォーマンスと信頼性を向上させます。
表5-4に基礎的なバックグラウンド・プロセスを示しますが、これらの多くはこのドキュメントの他の項で詳細に説明されています。追加のデータベース機能やオプションを使用している場合、これ以外のバックグラウンド・プロセスも実行される場合があります。次に例を示します。
Oracle Streamsアドバンスト・キューイングを使用している場合は、キュー・モニター(QMNn)・バックグラウンド・プロセスが存在します。
また、データファイルをストレージ・サブシステムの物理デバイスにマッピングするためにFILE_MAPPING初期化パラメータを指定している場合は、FMONプロセスが存在します。
Oracle Automatic Storage Management(Oracle ASM)を使用している場合は、Oracle ASM固有の追加のバックグラウンド・プロセスが存在します。
表5-4 Oracle Databaseバックグラウンド・プロセス
| プロセス名 | 説明 |
|---|---|
|
データベース・ライターは、変更があったブロックをデータベース・バッファ・キャッシュからデータファイルに書き込みます。Oracle Databaseでは、最大36のデータベース・ライター・プロセス(DBW0からDBW9およびDBWaからDBWj)を使用できます。DBW
|
|
|
ログ・ライター・プロセスは、ディスクにREDOログ・エントリを書き込みます。REDOログ・エントリは、システム・グローバル領域(SGA)のREDOログ・バッファに生成される。LGWRは、REDOログ・ファイルにREDOログ・エントリを順番に書き込む。データベースに多重化されたREDOログがある場合、LGWRはREDOログ・ファイルのグループにREDOログ・エントリを書き込む。ログ・ライター・プロセスの詳細は、第12章「REDOログの管理」を参照してください。 |
|
|
システム・グローバル領域内で変更があったすべてのデータベース・バッファは、特定の時点でDBWnによってデータファイルに書き込まれます。このイベントはチェックポイントと呼ばれます。チェックポイント・プロセスは、最新のチェックポイントを示すために、チェックポイントでDBWnにシグナルを出し、データベースのすべてのデータファイルと制御ファイルを更新する役割を持ちます。 |
|
|
システム・モニターは、障害の発生したインスタンスの再起動時にリカバリを実行します。Oracle Real Application Clustersデータベースでは、1つのインスタンスのSMONプロセスが、障害を起こした他のインスタンスのインスタンス・リカバリを実行できます。また、SMONにより、不要になった一時セグメントがクリーン・アップされ、ファイル読込みエラーやオフライン・エラーのためにシステム障害時やインスタンス・リカバリ時にスキップされた停止後のトランザクションがリカバリされます。これらのトランザクションは、表領域またはファイルがオンラインに戻るときに、SMONによって最後にリカバリされます。 |
|
|
プロセス・モニターは、ユーザー・プロセスが失敗したときにプロセス・リカバリを実行します。PMONは、キャッシュをクリーン・アップし、プロセスで使用されていたリソースを解放する役割を持ちます。また、PMONは、ディスパッチャ・プロセス(この表で後述)とサーバー・プロセスをチェックし、障害がある場合は再起動します。 |
|
|
REDOログ・ファイルは、ログ・ファイルが一杯になるか、ログ・スイッチが発生すると、1つ以上のアーカイバ・プロセスによってアーカイブ記憶域にコピーされます。アーカイバ・プロセスについては、第13章「アーカイブREDOログの管理」を参照してください。 |
|
|
リカバラ・プロセスは、ネットワーク障害やシステム障害が原因で分散データベース内で保留されている分散トランザクションを解決するために使用されます。ローカルRECOは一定周期でリモート・データベースへの接続を試み、保留中の分散トランザクションのローカル部分のコミットまたはロールバックを自動的に完了させる。このプロセスの詳細と開始方法は、第35章「分散トランザクションの管理」を参照してください。 |
|
|
ディスパッチャはオプションのバックグラウンド・プロセスで、共有サーバー構成の使用時にのみ存在します。共有サーバーの詳細は、前述の「Oracle Databaseの共有サーバー構成」を参照してください。 |
|
関連項目: Oracle Databaseバックグラウンド・プロセスの完全なリストは、『Oracle Databaseリファレンス』を参照してください。 |
|
注意: この項に記載されているパラレル実行機能は、Oracle Database Enterprise Editionで利用できます。 |
この項では、SQL文のパラレル実行の管理方法について説明します。この構成では、Oracle Databaseによって、SQL文の処理作業を複数のパラレル・プロセスに分割できます。
多数のSQL文の実行をパラレル化できます。並列度は、単一の処理に対応付け可能なパラレル実行サーバーの数で表されます。並列度は、次の要素によって決まります。
文のPARALLEL句
問合せ内で参照されているオブジェクトの場合は、オブジェクトが作成または変更されたときに使用されたPARALLEL句
データベースによって決定されたデフォルト
SQLのパラレル実行の使用例は、「表作成のパラレル化」を参照してください。
この項の内容は、次のとおりです。
インスタンスが起動すると、Oracle Databaseによって、パラレル操作に使用可能なパラレル実行サーバーのプールが作成されます。パラレル実行コーディネータと呼ばれるプロセスがパラレル実行サーバーのプールの実行をディスパッチし、これらすべてのパラレル実行サーバーからユーザーへの結果の送信を調整します。
PARALLEL_MAX_SERVERS初期化パラメータのデフォルト値は0(ゼロ)より大きい値に設定されているため、パラレル実行サーバーはデフォルトで使用可能です。これらのプロセスは、並列化を利用できる様々なOracle Databaseの機能によって使用されます。関連する初期化パラメータは、データベースによって大半のユーザー用にチューニングされますが、必要に応じて環境にあわせて変更できます。簡単にチューニングできるように、一部のパラメータは動的に変更できます。
並列化は、トランザクション・リカバリ、レプリケーション、SQL実行など、様々な機能で使用できます。ここで説明しているSQLのパラレル実行の場合、1つの文の実行フェーズ全体を通して、複数のパラレル・サーバー・プロセスが対応付けられます。文の処理が完了すると、その文に対応付けられていたプロセスが他の文を処理できるようになります。
|
関連項目: パラレル実行の使用に関する詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
セッションのSQLのパラレル実行は、ALTER SESSION文を使用して制御できます。
SQLのパラレル実行は、ALTER SESSION DISABLE PARALLEL DML|DDL|QUERY文で使用禁止にできます。この文を発行した後は、後続のすべてのDML(INSERT、UPDATE、DELETE)、DDL(CREATE、ALTER)または問合せ(SELECT)操作がシリアルに実行されます。関係する表または索引にパラレル属性が指定されている場合でも、それとは無関係に文はシリアルに実行されます。ただし、PARALLELヒントが指定された文は、セッションの設定を無効にします。
次の文は、パラレルDDL操作を使用禁止にします。
ALTER SESSION DISABLE PARALLEL DDL;
SQLのパラレル実行は、ALTER SESSION ENABLE PARALLEL DML|DDL|QUERY文で使用可能にできます。その後、PARALLEL句またはパラレル・ヒントを文に対応付けると、そのDML文、DDL文または問合せ文はパラレルで実行されます。DDL文と問合せ文のパラレル実行はデフォルトで使用可能です。
DML文は、ALTER SESSION文を明示的に発行して、パラレルDMLを使用可能にした場合のみパラレル化できます。
ALTER SESSION ENABLE PARALLEL DML;
ALTER SESSION FORCE PARALLEL DML|DDL|QUERY文を発行すると、後続のすべてのDML、DDLまたは問合せ文をパラレルで実行するように強制できます。また、特定の並列度を強制的に適用して、後続の文に対応付けられたPARALLEL句を無効にできます。この文で並列度を指定しなかった場合は、デフォルトの並列度が使用されます。パラレル実行を強制すると、SQL文のパラレル・ヒントが無効になります。
次の文は、後続の文のパラレル実行を強制し、優先する並列度を5に設定します。
ALTER SESSION FORCE PARALLEL DDL PARALLEL 5;
この項の内容は次のとおりです。
外部プロシージャは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ロールを持つユーザーのみがライブラリを作成および管理できます。このため、DBAは次のことを依頼される場合があります。
CREATE LIBRARY文を使用して、開発者が必要とするライブラリ・オブジェクトを作成します。
開発者への次の権限の付与: CREATE LIBRARY、CREATE ANY LIBRARY、ALTER ANY LIBRARY、EXECUTE ANY LIBRARYおよびEXECUTE ON library_name。
これらの権限の明示的付与は、信頼できるユーザーに対してのみ行ってください。決してPUBLICロールに対して付与しないでください。ライブラリにPL/SQLインタフェースを作成する場合、EXECUTE権限のみをPL/SQLインタフェースに付与してください。基礎となるライブラリにEXECUTEを付与しないでください。PL/SQLインタフェースを作成するには、ライブラリに対するEXECUTEオブジェクト権限が必要です。ただし、ユーザーは自らのスキーマに対しては自動的にこの権限を持っています。ライブラリに対してEXECUTEオブジェクト権限を明示的に付与する必要はほとんどりません。
|
関連項目: CREATE LIBRARY文の詳細は、 |
時々、現行のユーザー・セッションを停止する必要があります。たとえば、管理操作を実行する場合に、すべての管理セッション以外のセッションを停止する必要があります。ここでは、セッションの停止の様々な要素について説明します。この項の内容は、次のとおりです。
セッションが停止すると、そのセッションのアクティブ・トランザクションがロールバックされ、そのセッションが保持していたリソース(ロックやメモリー領域など)がただちに解放されて、他のセッションで使用可能になります。
SQL文ALTER SYSTEM KILL SESSIONを使用して、現行のセッションを停止します。次の文は、システム識別子が7でシリアル番号が15のセッションを停止します。
ALTER SYSTEM KILL SESSION '7,15';
停止するセッションを識別するには、セッションの索引番号とシリアル番号を指定します。セッションのシステム識別子(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以外の値になります。
停止時にセッションがOracle Databaseに対してSQLコールを実行していない場合(STATUSが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.
次の表に、プロセスとセッションの管理に役立つデータ・ディクショナリ・ビューを示します。
| ビュー | 説明 |
|---|---|
V$PROCESS |
現在アクティブになっているプロセスの情報が含まれています。 |
V$SESSION |
現行のセッションごとにセッション情報がリストされます。 |
V$SESS_IO |
各ユーザー・セッションのI/O統計情報が含まれています。 |
V$SESSION_LONGOPS |
6秒(絶対時間)以上実行されていた各種操作の状態が表示されます。現在、状態が表示される操作は、多数のバックアップおよびリカバリ機能、統計収集および問合せの実行などです。Oracle Databaseのリリースごとにさらに操作が追加されます。 |
V$SESSION_WAIT |
各セッションの現在または最後の待機が表示されます。 |
V$SESSION_WAIT_HISTORY |
各アクティブ・セッションの最後の10個の待機イベントがリストされます。 |
V$WAIT_CHAINS |
ブロックされたセッションに関する情報が表示されます。 |
V$SESSTAT |
システム統計情報が含まれています。 |
V$RESOURCE_LIMIT |
一部のシステム・リソースについて、現行および最大のグローバル・リソース使用率が表示されます。 |
V$SQLAREA |
共有SQL領域に関する統計情報が含まれています。SQL文字列ごとに1行ずつ含まれます。メモリー内にあり、解析済で、実行準備のできているSQL文に関する統計情報も提供します。 |
