日本語PDF

5 プロセスの管理

Oracle Databaseでは、複数のユーザーおよびアプリケーションが同時に1つのデータベース・インスタンスに接続できるように、複数のプロセスを使用しています。

5.1 専用サーバー・プロセスと共有サーバー・プロセスについて

Oracle Databaseでは、インスタンスに接続されているユーザー・プロセスの要求を処理するために、サーバー・プロセスが作成されます。

サーバー・プロセスには、次の2つのプロセスがあります。

  • 専用サーバー・プロセス。単一のユーザー・プロセスのみを処理します。

  • 共有サーバー・プロセス。複数のユーザー・プロセスを処理できます。

データベースでは、専用サーバー・プロセスは常に使用可能な状態ですが、共有サーバーは、1つ以上の初期化パラメータを特別に設定して、構成および使用可能にする必要があります。

5.1.1 専用サーバー・プロセス

専用サーバー・プロセスは、1つのユーザー・プロセスのみを処理します。

図5-1は、専用サーバー・プロセスの仕組みを示しています。この図では、専用サーバー・プロセスを介して、2つのユーザー・プロセスがデータベースに接続されています。

一般的には、共有サーバーを使用し、ディスパッチャを介して接続することをお薦めします。これを図5-2に示します。共有サーバー・プロセスは、実行中のインスタンスに必要なプロセスの数を少なくできるため、効率が向上します。

ただし、次の状況では、ユーザーと管理者は、専用サーバー・プロセスを使用して明示的にインスタンスに接続する必要があります。

  • バッチ・ジョブを実行する場合(たとえば、ジョブがサーバー・プロセスに対して持つアイドル時間がほとんどないか、まったくない場合)

  • Recovery Manager(RMAN)を使用して、データベースをバックアップ、リストアまたはリカバリする場合

Oracle Databaseが共有サーバー用に構成されている場合に専用サーバー接続を要求するには、専用サーバーを使用するように構成されているネット・サービス名を使用して接続する必要があります。具体的に言うと、ネット・サービス名の接続記述子にSERVER=DEDICATED句を含めます。

関連項目:

専用サーバー接続を要求する方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

図5-1 Oracle Databaseの専用サーバー・プロセス

図5-1の説明が続きます
「図5-1 Oracle Databaseの専用サーバー・プロセス」の説明

5.1.2 共有サーバー・プロセス

共有サーバー・プロセスは、複数のユーザー・プロセスを処理できます。

専用サーバー・プロセスを使用した注文入力システムを例にとって考えてみます。顧客が注文受付に電話で商品を注文すると、担当者はその注文をデータベースに入力します。取引のほとんどの間、担当者は顧客と電話で話しています。この間、サーバー・プロセスは必要ないため、担当者のユーザー・プロセス専用のサーバー・プロセスはアイドル状態のままです。アイドル状態のサーバー・プロセスはシステム・リソースを保持しているため、他の担当者が注文を入力する際にシステムのパフォーマンスが低下します。

共有サーバー・アーキテクチャでは、接続ごとに専用サーバー・プロセスは必要ありません(図5-2を参照)。

図5-2 Oracle Databaseの共有サーバー・プロセス

図5-2の説明が続きます
「図5-2 Oracle Databaseの共有サーバー・プロセス」の説明

共有サーバー構成を使用する場合、クライアントのユーザー・プロセスはディスパッチャに接続します。ディスパッチャは複数のクライアント接続を同時にサポートできます。各クライアント接続はバーチャル・サーキットにバインドされており、これはディスパッチャが使用する共有メモリーの1つで、クライアント・データベースの接続要求および応答を目的としています。ディスパッチャは、リクエストが到着するとバーチャル・サーキットを共通キューに配置します。

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

リソース管理をさらに向上させるために、共有サーバーにセッション多重化を構成でき、これにより、オペレーティング・システムのリソースを節約するために、単一のネットワーク接続で通信用の複数のセッションが結合されます。

共有サーバー・アーキテクチャには、Oracle Net Servicesが必要です。共有サーバーを使用するユーザー・プロセスは、Oracle Databaseインスタンスと同じシステム上にある場合でも、必ずOracle Net Servicesを介して接続してください。

関連項目:

セッションの多重化などの機能を含む共有サーバーの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

5.2 データベース常駐接続プーリングの理解

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

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

DRCPは、中間層接続プーリングを実行できない(PHP/Apacheなどの)マルチプロセスのシングル・スレッド・アプリケーション・サーバーを含むアーキテクチャに特に適しています。データベースは、DRCPを使用すると同時接続の数を数万まで増やすことができます。

ノート:

  • Oracle Database 12cリリース2 (12.2)以降では、同じユーザーに属するプロキシ・セッションを共有できます。

  • Windowsプラットフォームでは、SQLNET.AUTHENTICATION_SERVICESパラメータ値のnts設定がDRCPでサポートされていません。

関連項目:

データベース常駐接続プーリングを使用する場合

データベース常駐接続プーリングは、複数のクライアントがデータベースにアクセスする場合で、次のいずれかに該当する場合に有効です。

  • 大量のクライアント接続を最小限のメモリー使用でサポートする必要がある場合。

  • 複数の類似クライアント・アプリケーションがあり、セッションの共有または再利用が可能な場合。

    類似アプリケーションとは、同じデータベース資格証明で接続し、同じスキーマを使用するアプリケーションです。

  • クライアント・アプリケーションでデータベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放する場合。

  • クライアント要求にまたがるセッション・アフィニティが必要ない場合。

  • クライアント側に複数のプロセスおよび複数のホストが存在する場合。

データベース常駐接続プーリングの利点

データベース常駐接続プーリングの使用には次の利点があります。

  • 複数の中間層クライアント・アプリケーション間でリソースを共有できます。

  • リソース使用量が減少するため、データベースおよびアプリケーションのスケーラビリティが向上します。

データベース常駐接続プーリングおよびLOGON/LOGOFFトリガー

LOGONトリガーは、DRCPで認証が実施されるたびに、または新規セッションが作成されるたびに起動します。

LOGOFFトリガーは、DRCPでログオフされるたび、またセッションが破棄されると起動します。このため、LOGOFFトリガーは、アイドル時間制限のために、セッションが終了すると起動します。

5.2.1 DRCP、専用サーバーおよび共有サーバーの比較

専用サーバー、共有サーバーおよびデータベース常駐接続プーリングの相違点を理解します。

表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です。

5.3 プロキシ常駐接続プーリングについて

プロキシ常駐接続プーリングには、Traffic DirectorモードのOracle Connection Managerを使用して構成できるプロキシ常駐接続プールを使用します。プロキシ常駐接続プーリングにより、データベース・クライアントの高可用性、高度なセキュリティおよびパフォーマンスが提供されます。

プロキシ常駐接続プーリングを使用してデータベース・インスタンスに接続できるデータベース・クライアントは、Oracle Call Interface (OCI)、Java Database Connectivity (JDBC)、Oracle Data Provider for .NET (ODP.Net)、Open Database Connectivity (ODBC)、Pro*C、Pro*COBOL、PHP OCI8拡張モジュール、Node.js node-oracledbドライバ、Python cx_Oracle、ROracle、Ruby-oci8、Perl DBD::OracleまたはOracle C++ Call Interface (OCCI)のいずれかのテクノロジに基づいている必要があります。

ノート:

プロキシ常駐接続プーリングは、Oracle Database 18c以降で使用できます。

プロキシ常駐接続プーリングを使用する場合

プロキシ常駐接続プーリングは、複数のクライアントがデータベースにアクセスする場合で、次のいずれかに該当する場合に有効です。

  • 大量のクライアント接続を、それより少ないデータベースへの接続数でサポートする必要がある場合。

  • 1つのデータベース接続を中間層接続プール間で共有する必要がある場合。

  • 64Kを超えるセッションをサポートする必要がある場合(64kセッションの制限があるため共有サーバーを使用できない場合)。

  • 透過アプリケーション・フェイルオーバー(TAF)とOracle RACをサポートしていない古いクライアントや、Oracleデータベース常駐接続プーリング(DRCP)、高速アプリケーション通知(FAN)またはアプリケーション・コンティニュイティ(AC)を使用しないクライアントで高可用性をサポートする必要がある場合。

プロキシ常駐接続プーリングの利点

プロキシ常駐接続プーリングの使用には、次の主な利点があります。

  • 高可用性の向上(計画と計画外)

  • データベース・セキュリティの向上

  • データベース接続の多重化

関連項目:

Traffic DirectorモードのOracle Connection Managerを使用したプロキシ常駐接続プーリングの有効化の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

5.4 Oracle Databaseの共有サーバー構成

共有サーバーを有効にし、共有サーバーの初期化パラメータを設定または変更できます。

5.4.1 共有サーバー用初期化パラメータ

初期化パラメータのセットにより、共有サーバー操作を制御します。

共有サーバー操作を制御する初期化パラメータは、次のとおりです。

  • SHARED_SERVERS: 起動する初期共有サーバー数および最低限保持する共有サーバー数を指定します。共有サーバーを使用するための必須パラメータはこのパラメータのみです。

  • MAX_SHARED_SERVERS: 同時に実行可能な共有サーバーの最大数を指定します。

  • SHARED_SERVER_SESSIONS: 同時に実行可能な共有サーバー・ユーザー・セッションの合計数を指定します。このパラメータを設定すると、専用サーバーのユーザー・セッションを確保することが可能になります。

  • DISPATCHERS: 共有サーバー・アーキテクチャのディスパッチャ・プロセスを構成します。

  • MAX_DISPATCHERS: 同時に実行できるディスパッチャ・プロセスの最大数を指定します。このパラメータは、現在は無視できます。将来のリリースで、同時接続数によってディスパッチャ数が自動的にチューニングされるようになるまで使用しません。

  • CIRCUITS: 受信および発信用のネットワーク・セッションに使用可能なバーチャル・サーキットの合計数を指定します。

関連項目:

これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』

5.4.2 共有サーバーのメモリー管理

共有サーバーが動作するには、共有プールまたはラージ・プールにユーザー・グローバル領域(UGA)が必要です。同時セッション数が少ないインストールでは、通常、これらのシステム・グローバル領域(SGA)コンポーネントのデフォルト・サイズで十分です。ただし、セッション数が多い場合は、共有サーバーに対応できるようにメモリーをチューニングする必要があります。

ガイドラインは、『Oracle Databaseパフォーマンス・チューニング・ガイド』のメモリーの構成と使用に関する項を参照してください。

5.4.3 共有サーバーの使用可能化

共有サーバーを使用可能にするには、SHARED_SERVERS初期化パラメータに0(ゼロ)より大きい値を設定します。他の共有サーバー初期化パラメータの設定は不要です。

  • 動的に共有サーバーを設定するには、ALTER SYSTEM文でSHARED_SERVERS初期化パラメータを0以外の値に設定します。

  • データベースの起動時にSHARED_SERVERS初期化パラメータを0以外の値に設定するには、それを初期化パラメータ・ファイルに含めます。

共有サーバーが動作するには最低1つのディスパッチャが必要であるため、構成されていない場合でも、ディスパッチャは起動されます。ディスパッチャについては、「ディスパッチャの構成」を参照してください。

ノート:

SHARED_SERVERSがデータベースの起動時に初期化パラメータ・ファイルに組み込まれていない場合でも、DISPATCHERSが組み込まれ、少なくとも1つのディスパッチャが指定されていると、共有サーバーは使用可能になります。この場合、SHARED_SERVERSのデフォルトは1です。

SHARED_SERVERSDISPATCHERSのいずれも初期化ファイルに組み込まれていない場合は、インスタンスが起動された後に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固有ではない構成に置き換える必要があります。手順については、「ディスパッチャの構成」を参照してください。

5.4.3.1 SHARED_SERVERSの値の決定について

SHARED_SERVERS初期化パラメータは、インスタンスの起動時に作成する共有サーバーの最小数を指定します。インスタンスの起動後は、既存の共有サーバーがビジーになる頻度と要求キューの長さに基づいて、Oracle Databaseが共有サーバーの数を動的に調整します。

標準的なシステムでは、共有サーバーの数は、10接続ごとに共有サーバー1つという割合で安定します。OLTPアプリケーションでは、要求率が低い場合、または要求に対してサーバー使用の比率が低い場合は、接続数/サーバー数の割合が高くなります。対照的に、要求率が高いか、要求に対してサーバー使用の比率が大きいアプリケーションの場合は、接続数/サーバー数の割合が低くなります。

PMON(プロセス・モニター)バックグラウンド・プロセスは、SHARED_SERVERSで指定された値を下回る状態まで共有サーバーを終了させることはできません。したがって、このパラメータを使用すると、偶発的な負荷の変動のためにPMONが共有サーバーを終了および再起動することがなくなるため、負荷が安定し、システムへの過負荷を最小にできます。

システムの平均的な負荷がわかっている場合は、SHARED_SERVERSを最適な値に設定できます。次に、このパラメータの使用方法の例を示します。

1000人の従業員が勤務するテレマーケティング・センターでデータベースが使用されているとします。従業員は、平均して勤務時間の90%を顧客との電話応対に費やし、レコードの検索と更新には10%のみ費やしています。従業員が顧客と電話をしている間に共有サーバーが終了し、データベースにアクセスしたときに再び起動することがないように、DBAは最適な共有サーバー数として100を指定しています。

ただし、すべての勤務時間帯で同じ数の従業員が勤務しているわけではありません。夜間の時間帯は200人の従業員で十分です。SHARED_SERVERSは動的なパラメータであるため、DBAは、夜間の共有サーバーの数を20に減らし、バッチ・ジョブなどの他のタスクにリソースが解放されるようにします。

5.4.3.2 共有サーバー・プロセス数の削減

最低限アクティブに保つ必要がある共有サーバーの数を削減するには、SHARED_SERVERSパラメータを小さい値に動的に設定します。設定後は、共有サーバー数がSHARED_SERVERSパラメータの値に減少するまで、非アクティブになる共有サーバーにはPMONによって終了のマークが付けられます。

  • 動的に共有サーバーを設定するには、ALTER SYSTEM文でSHARED_SERVERS初期化パラメータを0以外の値に設定します。

たとえば、次の文は、共有サーバーの数を削減します。

ALTER SYSTEM SET SHARED_SERVERS = 5;

SHARED_SERVERSを0(ゼロ)に設定すると、共有サーバーは使用禁止になります。詳細は、「共有サーバーの無効化」を参照してください。

5.4.3.3 共有サーバー・プロセス数の制限

MAX_SHARED_SERVERS初期化パラメータは、PMONが自動的に作成可能な共有サーバーの最大数を指定します。デフォルト値はありません。

値が指定されていない場合、PMONは次の制限内で、負荷によって必要とされる共有サーバーを可能なかぎり起動します。

  • プロセスの制限(PROCESSES初期化パラメータによって設定)

  • 最小空きプロセス・スロット数(少なくとも総プロセス・スロット数の1/8、またはPROCESSESが24未満に設定されている場合は2スロット)

  • システム・リソース

共有サーバーのプロセス数を制限するには:

  • MAX_SHARED_SERVERS初期化パラメータを設定します。

SHARED_SERVERSの値が、MAX_SHARED_SERVERSの値より優先されます。したがって、SHARED_SERVERSMAX_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の値を非常に小さい数に設定しておき、ユーザーが応答時間の遅延を認識しない数まで増やすことができます。

5.4.3.4 共有サーバー・セッション数の制限

SHARED_SERVER_SESSIONS初期化パラメータは、同時共有サーバー・ユーザー・セッションの最大数を指定します。

動的パラメータであるこのパラメータを設定すると、データベース・セッションを専用サーバー用に確保できます。この結果、データベースのバックアップやリカバリなど、専用サーバーを必要とする管理タスクが共有サーバー・セッションによって専有されることはありません。

共有サーバーのセッション数を制限するには:

  • SHARED_SERVER_SESSIONS初期化パラメータを設定します。

このパラメータにデフォルト値はありません。値が指定されていない場合は、SESSIONS初期化パラメータの制限範囲内で共有サーバー・セッションが必要に応じて作成されます。

5.4.3.5 共有メモリーの保護

CIRCUITS初期化パラメータは、共有メモリーに作成可能なバーチャル・サーキットの最大数を設定します。このパラメータにデフォルトはありません。値が指定されていない場合は、DISPATCHERS初期化パラメータおよびシステム・リソースの制限範囲内でサーキットが必要に応じて作成されます。

共有メモリーに作成可能なバーチャル・サーキット数を制限することにより共有メモリーを保護するには:

  • CIRCUITS初期化パラメータを設定します。

5.4.4 ディスパッチャの構成

DISPATCHERS初期化パラメータは、共有サーバー・アーキテクチャ内のディスパッチャ・プロセスを構成します。共有サーバーが動作するためには、1つのディスパッチャ・プロセスが最小限必要です。ディスパッチャを指定せずに、SHARED_SERVERを0(ゼロ)以外の値に設定して共有サーバーを使用可能にすると、デフォルトで、Oracle Databaseによって1つのディスパッチャがTCPプロトコル用に作成されます。

この構成に相当する初期化パラメータDISPATCHERSの明示的設定は次のとおりです。

dispatchers="(PROTOCOL=tcp)"

次のいずれかの条件に適合する場合は、DISPATCHERS初期化パラメータを使用して、追加のディスパッチャを構成できます。

  • TCP/IP以外のプロトコルを構成する必要がある場合。DISPATCHERSパラメータの次のいずれかの属性でプロトコル・アドレスを構成します。

  • 次のオプションのディスパッチャ属性を1つ以上構成する場合。

TCP/IP以外のプロトコルを構成するか、追加のディスパッチャを構成するには:

  • DISPATCHERS初期化パラメータを設定し、適切な属性を指定します。

5.4.4.1 DISPATCHERS初期化パラメータの属性

DISPATCHERS初期化パラメータには、複数の属性を設定できます。

プロトコル・アドレスは必須です。プロトコル・アドレスは次の属性を1つ以上使用して指定します。

属性 説明

ADDRESS

ディスパッチャがリスニングするエンドポイントのネットワーク・プロトコル・アドレスを指定します。

DESCRIPTION

ネットワーク・プロトコル・アドレスなど、ディスパッチャがリスニングするエンドポイントのネットワークの説明を指定します。構文は次のとおりです。

(DESCRIPTION=(ADDRESS=...))

PROTOCOL

ディスパッチャによってリスニング・エンドポイントが生成されるネットワーク・プロトコルを指定します。たとえば:

(PROTOCOL=tcp) 

プロトコル・アドレスの構文の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

次の属性は、この構成が使用するディスパッチャ数を指定します。これはオプションで、デフォルトは1です。

属性 説明

DISPATCHERS

起動する初期ディスパッチャの数を指定します。

次の属性は、構成の各ディスパッチャのネットワーク属性に関する情報をインスタンスに通知します。これらの属性はすべてオプションです。

属性 説明

CONNECTIONS

各ディスパッチャに対して許容されるネットワーク接続の最大数を指定します。

SESSIONS

各ディスパッチャに対して許容されるネットワーク・セッションの最大数を指定します。

LISTENER

LREGプロセスがディスパッチャ情報を登録するリスナーの別名を指定します。ネーミング・メソッドによって解決される別名を設定してください。

MULTIPLEX

Oracle Connection Managerのセッションの多重化機能を使用可能にする場合に使用します。

SERVICE

ディスパッチャがリスナーに登録するサービス名を指定します。

完全な属性名または先頭の3文字以上で構成されたサブストリングを指定できます。たとえば、SESSIONS=3SES=3SESS=3またはSESSI=3のように指定できます。

関連項目:

DISPATCHERS初期化パラメータの属性の詳細は、『Oracle Databaseリファレンス』を参照してください。

5.4.4.2 ディスパッチャ数の決定

オペレーティング・システムに対して各プロセスごとに可能な接続数を把握した後、インスタンス起動時に各ネットワーク・プロトコルに対して作成する初期ディスパッチャの数を計算します。

インスタンスの起動時に作成される初期のディスパッチャ数を計算するには、次の式を使用します。

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

パフォーマンスによっては、ディスパッチャ数の調整が必要になる場合があります。

5.4.4.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))"
5.4.4.4 ディスパッチャ数の変更

インスタンス内のディスパッチャ・プロセスの数を制御できます。共有サーバー数と異なり、ディスパッチャ数は自動的に変更されません。ディスパッチャの数は、明示的にALTER SYSTEM文で変更します。ディスパッチャ数は、MAX_DISPATCHERSパラメータで指定された制限を超えて増加することができます。

  1. 次のビューを監視し、ディスパッチャ・プロセスの負荷を判別します。
    • V$QUEUE

    • V$DISPATCHER

    • V$DISPATCHER_RATE

      これらのビューによって、ディスパッチャ・プロセスに対する負荷が一貫して高いことが判明した場合は、追加のディスパッチャ・プロセスを起動してユーザー要求をルーティングすることで、パフォーマンスを改善できます。逆に、ディスパッチャの負荷が一貫して低い場合は、ディスパッチャの数を少なくすることにより、パフォーマンスを改善できます。

      関連項目:

      これらのビューを監視してディスパッチャの負荷とパフォーマンスを判別する方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』

  2. インスタンスの実行中にディスパッチャの数を動的に変更するには、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用のディスパッチャ・プロセスが現在複数起動している場合は、接続ユーザーの切断にあわせて余分なプロセスが停止されます。

5.4.4.4.1 ディスパッチャ数変更時のノート

ディスパッチャの変更の詳細を理解します。

  • INDEXキーワードを使用すると、変更するディスパッチャ構成を識別できます。このINDEXを指定しないと、指定したDESCRIPTIONADDRESSまたはPROTOCOLと一致する最初のディスパッチャ構成が変更されます。既存のディスパッチャ構成の中で一致するものが見つからなかった場合は、新しいディスパッチャが追加されます。

  • INDEX値の範囲は0からn-1で、nは現行のディスパッチャ構成の数です。ALTER SYSTEM文でINDEX値にnを指定すると(nは現行のディスパッチャ構成の数)、新しいディスパッチャ構成が追加されます。

  • 現行のディスパッチャ構成の値、つまり、ディスパッチャの数などを確認するには、V$DISPATCHER_CONFIG動的パフォーマンス・ビューを問い合せます。ディスパッチャが関連付けられているディスパッチャ構成を確認するには、V$DISPATCHERビューのCONF_INDX列を問い合せます。

  • ディスパッチャ構成のDESCRIPTIONADDRESSPROTOCOLCONNECTIONSおよびMULTIPLEX属性を変更しても、その変更は既存のディスパッチャには反映されず、新しいディスパッチャにのみ反映されます。したがって、構成に関連付けられているすべてのディスパッチャに対して変更を反映するには、DISPATCHERSパラメータを変更した後で、既存のディスパッチャを強制的に停止し、新しく指定したプロパティに配置された新しいディスパッチャをデータベースで起動する必要があります。

    LISTENER属性とSERVICES属性は、同じ制約の対象となりません。これらの属性は、変更した構成に関連付けられている既存のディスパッチャに適用されます。SESSIONS属性は、その値が減らされた場合のみ、既存のディスパッチャに適用されます。反対に値が増加された場合は、新しく起動されるディスパッチャにのみ適用されます。

5.4.4.5 特定のディスパッチャ・プロセスの停止

ALTER SYSTEM SET DISPATCHERS文では、ディスパッチャ数の削減のために停止されるディスパッチャは、データベースによって決定されます。別の方法として、特定のディスパッチャ・プロセスを停止できます。

  1. 停止するディスパッチャ・プロセスの名前を識別するには、V$DISPATCHER動的パフォーマンス・ビューを使用します。
    SELECT NAME, NETWORK FROM V$DISPATCHER;
    
    各ディスパッチャは、Dnnn形式の名前で一意に識別されます。
  2. ALTER SYSTEM SHUTDOWN IMMEDIATE文を実行し、ディスパッチャの名前を指定します。

    たとえば、ディスパッチャD002を停止するには、次の文を発行します。
    ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002';
    
    IMMEDIATEキーワードを指定すると、ディスパッチャによる新規接続の受入れが停止し、データベースはそのディスパッチャを介した既存のすべての接続を即時に終了します。すべてのセッションがクリーン・アップされてから、ディスパッチャ・プロセスが停止します。IMMEDIATEを指定しなかった場合、ディスパッチャは、接続ユーザーがすべて切断され、接続がすべて終了するまで待ってから停止します。

5.4.5 共有サーバーの使用禁止

共有サーバーを無効にするには、SHARED_SERVERSを0に設定します。この操作は、ALTER SYSTEM文を使用して動的に行うことができます。

  • SHARED_SERVERS初期化パラメータを0に設定します。

共有サーバーを無効にすると、新しいクライアントは共有モードで接続できなくなります。ただし、Oracle Databaseではすべての共有サーバーの接続がクローズされるまで一部の共有サーバーが保持されます。保持される共有サーバーの数は、SHARED_SERVERSの変更前の設定で指定されていた数、またはMAX_SHARED_SERVERSパラメータの値のいずれか小さい値です。SHARED_SERVERSMAX_SHARED_SERVERSの両方が0(ゼロ)に設定されている場合は、すべての共有サーバーが停止し、残りの共有サーバー・クライアントからの要求は、SHARED_SERVERSまたはMAX_SHARED_SERVERSの値が再度引き上げられるまでキューで待機します。

ディスパッチャを一度停止して、すべての共有サーバー・クライアントを切断するには、次の文を入力します。

ALTER SYSTEM SET DISPATCHERS = '';

5.4.6 共有サーバーのデータ・ディクショナリ・ビュー

共有サーバーの構成情報およびパフォーマンスの監視のためにデータ・ディクショナリ・ビューを問い合せることができます。

ビュー 説明

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パフォーマンス・チューニング・ガイド』

5.5 データベース常駐接続プーリングの構成

データベース・サーバーは、データベース常駐接続プーリングを使用できるように事前に構成されています。ただし、この機能は、接続プールを起動して明示的に使用可能にする必要があります。

5.5.1 データベース常駐接続プーリングの初期化パラメータ

データベース常駐接続プーリングを構成するには、初期化パラメータを設定します。

データベース常駐接続プーリング(DRCP)に専用最適化の使用を構成するには、DRCP_DEDICATED_OPT初期化パラメータを使用します。専用最適化を有効にするには、DRCP_DEDICATED_OPTYesを設定します。専用最適化では、DRCPブローカへの接続数がDRCP最大サイズよりも少ない場合、DRCPは専用サーバーと同様に動作します。

認証プールを構成するには、次の初期化パラメータを使用します。

  • MAX_AUTH_SERVERS

    認証プール内の認証サーバーの最大数を指定します。認証プールは、接続プールとは分離されており、クライアント・アプリケーションがDRCPに接続するときにユーザー接続を認証します。このパラメータには、MIN_AUTH_SERVERS初期化パラメータに指定した値より大きい正の整数を設定します。

  • MIN_AUTH_SERVERS

    認証プール内の認証サーバーの最小数を指定します。このパラメータには、MAX_AUTH_SERVERS初期化パラメータに指定した値より小さい正の整数を設定します。

5.5.2 データベース常駐接続プーリングを使用可能にする方法

Oracle Databaseには、SYS_DEFAULT_CONNECTION_POOLと呼ばれるデフォルトの接続プールがあります。デフォルトでは、このプールは作成されますが起動はされません。データベース常駐接続プーリングを使用可能にするには、接続プールを明示的に起動する必要があります。

データベース常駐接続プーリングを使用可能にするには:

  1. 「データベース常駐接続プールの起動」の説明に従って、データベース常駐接続プールを起動します。

  2. 「接続プールへのクライアント接続要求のルーティング」の説明に従って、クライアント接続要求を接続プールにルーティングします。

データベース常駐接続プールの起動

接続プールを起動するには:

  1. SQL*Plusを起動して、SYSユーザーとしてデータベースに接続します。

  2. 次のコマンドを発行します。

    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プロトコルのみがサポートされます。

データベース常駐接続プーリングを使用禁止にする方法

データベース常駐接続プーリングを使用禁止にするには、接続プールを明示的に停止する必要があります。次のステップを実行します。

  1. SQL*Plusを起動して、SYSユーザーとしてデータベースに接続します。
  2. 次のコマンドを発行します。
    SQL> EXECUTE DBMS_CONNECTION_POOL.STOP_POOL();

    関連項目:

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

ノート:

データベース常駐接続プールを使用禁止にする操作は、サーバーに渡されたすべてのクライアント要求が完了しないと完了できません。

5.5.3 データベース常駐接続プーリングの接続プールの構成

接続プールはデフォルトのパラメータ値を使用して構成されます。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パッケージおよびタイプ・リファレンス』を参照してください。

5.5.3.1 データベース常駐接続プーリングの構成パラメータ

DBMS_CONNECTION_POOLパッケージ内のサブプログラムのパラメータを指定して、データベース常駐接続プーリングを構成できます。

次の表は、接続プールのために設定できるパラメータを示しています。

表5-2 データベース常駐接続プーリングの構成パラメータ

パラメータ名 説明

MINSIZE

プール内のプール・サーバーの最小数。デフォルト値は4です。

MAXSIZE

プール内のプール・サーバーの最大数。デフォルト値は40です。

接続プールでは、プールされたサーバーの5%が認証のために保持され、少なくとも1つのプールされたサーバーが認証のために常時保持されます。このパラメータを設定する場合は、認証と接続の両方に十分なプール・サーバーがあることを確認します。

INCRSIZE

クライアント・アプリケーション要求の受取り時にサーバーが使用可能でない場合にプールが増分されるプール・サーバーの数。デフォルト値は2です。

SESSION_CACHED_CURSORS

各プール・サーバー・セッションでキャッシュするセッション・カーソルの数。デフォルト値は20です。

INACTIVITY_TIMEOUT

プール・サーバーがプールでアイドル状態のままで待機する最大時間(秒数)。この時間を過ぎると、サーバーは終了される。デフォルト値は300です。

このパラメータはプールがMINSIZEの場合は適用されません。

MAX_THINK_TIME

クライアントがプールからプール・サーバーを取得した後で非アクティブ状態でいる最大時間(秒数)。クライアント・アプリケーションがプールからプール・サーバーを取得した後、MAX_THINK_TIMEで指定した時間内にデータベース・コールを発行しない場合、プール・サーバーは解放されてクライアント接続が終了します。そのため、このような接続でラウンドトリップ・コールが試行されると、アプリケーションでORA-3113またはORA-3115エラーが発生する可能性があります。

MAX_TXN_THINK_TIME

プールからオープン・トランザクションを含むプール・サーバーを取得した後のクライアントの最大非アクティブ時間(秒数)。クライアント・アプリケーションがプールからプール・サーバーを取得した後、MAX_TXN_THINK_TIMEで指定した時間内にデータベース・コールを発行しない場合、プール・サーバーは解放されてクライアント接続が終了します。このパラメータのデフォルト値は、MAX_THINK_TIMEパラメータの値です。オープン・トランザクションを含む接続のための時間を確保するために、MAX_TXN_THINK_TIMEパラメータの値は、MAX_THINK_TIME値よりも高い値に設定できます。

MAX_USE_SESSION

プール・サーバーがプールから取得されプールに解放される回数。デフォルト値は500000です。

MAX_LIFETIME_SESSION

プール・サーバーがプールに存在している時間(秒数)。デフォルト値は86400です。

NUM_CBROK

クライアント要求を処理するために作成される接続ブローカの数。デフォルト値は1です。

複数の接続ブローカ・プロセスを作成すると、大量のクライアント・アプリケーションがある場合に、クライアント接続要求の負荷を分散できます。

MAXCONN_CBROK

各接続ブローカで処理できる最大接続数。

デフォルト値は40000です。ただし、データベースがインストールされているプラットフォームで許可される最大接続がデフォルト値より少ない場合は、MAXCONN_CBROKを使用して設定した値はその値で上書きされます。

MAXCONN_CBROKで指定した接続数がサポートされるように、オペレーティング・システムのプロセスごとのファイル記述子に関する制限は十分大きい値に設定してください。

関連項目:

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

5.5.4 データベース常駐接続プーリングのデータ・ディクショナリ・ビュー

接続プールの情報の取得およびデータベース常駐接続プーリングのパフォーマンスの監視のために、データ・ディクショナリ・ビューを問い合せることができます。

表5-3 データベース常駐接続プーリングのデータ・ディクショナリ・ビュー

ビュー 説明

DBA_CPOOL_INFO

プール・ステータス、接続の最大数と最小数、アイドル・セッションのタイムアウトなど、接続プールに関する情報が含まれます。

V$CPOOL_CONN_INFO

接続ブローカへの各接続に関する情報が含まれます。

V$CPOOL_STATS

セッション要求の数、要求と一致するセッションがプールで検出された回数、セッション要求の合計待機時間など、プール統計が含まれます。

V$CPOOL_CC_INFO

プールと接続のクラス・マッピングに関する情報が含まれています。

V$CPOOL_CC_STATS

プールの接続クラス・レベルの統計が含まれます。

5.5.5 接続プールの接続状態の判別

接続プールの各接続の現在の状態を調べるために、V$CPOOL_CONN_INFOビューを問い合せることができます。

このビューの問合せにより、各接続の状態についての詳細を得ることができます。たとえば、ビジーまたはアイドル状態の接続を判別できます。この情報を判別するには:

  • V$CPOOL_CONN_INFOビューを問い合せます。

例5-1 接続の待ち時間の判別

次の問合せは、WAITING状態の接続の待ち時間を示します。

SELECT USERNAME, SERVICE, LAST_WAIT_TIME
   FROM V$CPOOL_CONN_INFO
   WHERE CONNECTION_STATUS = 'WAITING';

例5-2 接続がアクティブになってからの経過時間の判別

次の問合せは、ACTIVE状態の接続について、各接続がアクティブになってからの経過時間を示します。

SELECT USERNAME, SERVICE, LAST_ACTIVE_TIME
   FROM V$CPOOL_CONN_INFO
   WHERE CONNECTION_STATUS = 'ACTIVE';

例5-3 最長のアクティブ状態を持つ実行中の接続のリスト

次の問合せは、ACTIVE状態が最長時間となっている接続を示します。

SELECT USERNAME, SERVICE, ACTIVE_TIME
   FROM V$CPOOL_CONN_INFO
   WHERE CONNECTION_STATUS = 'ACTIVE'
   ORDER BY ACTIVE_TIME DESC;

例5-4 待機キュー内の最も古い接続の待ち時間の判別

次の問合せは、WAITING状態のセッションの待ち時間を示します。

SELECT USERNAME, SERVICE, LAST_WAIT_TIME
   FROM V$CPOOL_CONN_INFO
   WHERE LAST_WAIT_TIME = (
      SELECT max(LAST_WAIT_TIME)
         FROM V$CPOOL_CONN_INFO
         WHERE CONNECTION_STATUS = 'WAITING');  

5.6 Oracle Databaseバックグラウンド・プロセスについて

マルチプロセスの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です。

データベース・ライター・プロセスの数は、DB_WRITER_PROCESSES初期化パラメータで指定します。データベースは、CPU数とプロセッサ・グループ数に基づいて、この初期化パラメータに適切なデフォルト設定を選択またはユーザー指定の設定を調整します。

DB_WRITER_PROCESSES初期化パラメータの設定の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ログ・ライター(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は、CLMNプロセスおよびCLnnスレーブによって実行されるクリーンアップを調整する役割を担います。クリーンアップにより、プロセスが使用していたリソースが開放されます。

アーカイバ(ARCn)

REDOログ・ファイルは、ログ・ファイルが一杯になるか、ログ・スイッチが発生すると、1つ以上のアーカイバ・プロセスによってアーカイブ記憶域にコピーされます。アーカイバ・プロセスは、「アーカイブREDOログ・ファイルの管理」の主題です。

リカバラ(RECO)

リカバラ・プロセスは、ネットワーク障害やシステム障害が原因で分散データベース内で保留されている分散トランザクションを解決するために使用されます。ローカルRECOは一定周期でリモート・データベースへの接続を試み、保留中の分散トランザクションのローカル部分のコミットまたはロールバックを自動的に完了させる。このプロセスの詳細と開始方法は、「分散トランザクションの管理」を参照してください。

ディスパッチャ(Dnnn)

ディスパッチャはオプションのバックグラウンド・プロセスで、共有サーバー構成の使用時にのみ存在します。共有サーバーの詳細は、前述の「Oracle Databaseの共有サーバー構成」を参照してください。

関連項目:

Oracle Databaseバックグラウンド・プロセスの完全なリストは、『Oracle Databaseリファレンス』を参照してください。

5.7 事前作成されたプロセスの管理

Oracle Databaseでは、プロセスを事前に作成してクライアント接続パフォーマンスを向上できます。

5.7.1 事前作成されたプロセスの管理について

Oracle Databaseは、プロセス・プールのフォアグラウンドおよびバックグラウンド・プロセスを事前作成できます。

専用ブローカが有効にされるか、スレッド実行モードが有効にされると、Oracle Databaseはフォアグラウンド・プロセスを事前作成します。フォアグラウンド・プロセスが必要となったときに、事前作成されたプロセスを内部的に使用して作成時間を短縮します。THREADED_EXECUTION初期化パラメータをTRUEに設定すると、データベースはスレッド実行モードで実行されます。このパラメータがFALSE(デフォルト)に設定されている場合、データベースはプロセス・モードで実行され、Oracle Databaseはプロセス・プールにフォアグラウンドおよびバックグラウンド・プロセスを事前作成しません。

プロセスが事前作成されている場合、クライアントの接続時間を効率化できます。スレッド実行モードが有効な場合、Oracle Databaseはデフォルトで様々なリクエスト・プールにプロセスを事前作成します。リクエスト・プールごとにプロセスの種類が異なります。V$PROCESS_POOLビューにこれらのプールの情報が表示され、DBMS_PROCESSパッケージを使用してこれらのプールを管理できます。

5.7.2 事前作成されたプロセスのプールの管理

DBMS_PROCESSパッケージを使用して、フォアグラウンド・プロセス・プールの事前作成プロセスの数を構成および変更できます。

Oracle Databaseは、クライアント接続の効率を改善するプロセス・プールを作成できます。これらのプールを管理するために、DBMS_PROCESSパッケージを使用できます。V$PROCESS_POOLビューの問合せにより、現在のプロセス・プールを表示できます。

プロセス・プールは、データベースがマルチスレッドOracle Databaseモデルで実行されている場合にのみ作成されます。
  1. 必要な権限を持つユーザーとしてデータベースに接続します。
    ユーザーにはSYSDBA管理権限が必要であり、接続時にAS SYSDBAを使用してこの権限を行使する必要があります。
  2. プロセス・プールを管理するために、DBMS_PROCESSパッケージのサブプログラムを実行します。

例5-5 プロセス・プールの停止

この例では、SYS_DEFAULT_FOREGROUND_POOLプロセス・プールを停止します。
exec DBMS_PROCESS.STOP_POOL('SYS_DEFAULT_FOREGROUND_POOL');

プロセス・プールが停止しているとき、それに対するV$PROCESS_POOLビューのENABLED列はFALSEです。

例5-6 プロセス・プールの開始

この例では、SYS_DEFAULT_FOREGROUND_POOLプロセス・プールを開始します。
exec DBMS_PROCESS.START_POOL('SYS_DEFAULT_FOREGROUND_POOL');

プロセス・プールが有効であるとき、それに対するV$PROCESS_POOLビューのENABLED列はTRUEです。

例5-7 プロセス・プールの構成

V$PROCESS_POOLビューの問合せにより、プロセス・プールの現在の構成を確認できます。たとえば、次の問合せは、プロセス・プールの現在の構成を表示します。

COLUMN POOL_NAME FORMAT A30
COLUMN ENABLED FORMAT A7
COLUMN MIN_COUNT FORMAT 9999999
COLUMN BATCH_COUNT FORMAT 9999999
COLUMN INIT_COUNT FORMAT 9999999

SELECT POOL_NAME, ENABLED, MIN_COUNT, BATCH_COUNT, INIT_COUNT
   FROM V$PROCESS_POOL;

次のような結果を想定します。

POOL_NAME                      ENABLED MIN_COUNT BATCH_COUNT INIT_COUNT
------------------------------ ------- --------- ----------- ----------
SYS_DEFAULT_FOREGROUND_POOL    TRUE           10          20         29

このプロセス・プールで、事前作成される最小プロセス数を20、バッチで事前作成されるプロセスの数を30、および事前作成される初期のプロセス数を40に変更するには、次のプロシージャを実行します。

BEGIN
   DBMS_PROCESS.CONFIGURE_POOL(
      POOL_NAME   => 'SYS_DEFAULT_FOREGROUND_POOL',
      MIN_COUNT   => 20,
      BATCH_COUNT => 30,
      INIT_COUNT  => 40);
END;
/

問合せを再度実行することにより、変更を確認できます。

関連項目:

5.8 SQLのパラレル実行用プロセスの管理

SQL文のパラレル実行を管理できます。この構成では、Oracle Databaseによって、SQL文の処理作業を複数のパラレル・プロセスに分割できます。

ノート:

この項に記載されているパラレル実行機能は、Oracle Database Enterprise Editionで利用できます。

5.8.1 パラレル実行サーバーについて

多数のSQL文の実行をパラレル化できます。並列度は、単一の処理に対応付け可能なパラレル実行サーバーの数で表されます。

並列度は、次の要素によって決まります。

  • 文のPARALLEL

  • 問合せ内で参照されているオブジェクトの場合は、オブジェクトが作成または変更されたときに使用されたPARALLEL

  • 文に挿入されたパラレル・ヒント

  • データベースによって決定されたデフォルト

SQLのパラレル実行の使用例は、「表作成のパラレル化」を参照してください。

インスタンスが起動すると、Oracle Databaseによって、パラレル操作に使用可能なパラレル実行サーバーのプールが作成されます。パラレル実行コーディネータと呼ばれるプロセスがパラレル実行サーバーのプールの実行をディスパッチし、これらすべてのパラレル実行サーバーからユーザーへの結果の送信を調整します。

PARALLEL_MAX_SERVERS初期化パラメータ値はデフォルトで0より大きい値に設定されているため、パラレル実行サーバーはデフォルトで使用可能です。これらのプロセスは、並列化を利用できる様々なOracle Databaseの機能によって使用されます。関連する初期化パラメータは、データベースによって大半のユーザー用にチューニングされますが、必要に応じて環境にあわせて変更できます。簡単にチューニングできるように、一部のパラメータは動的に変更できます。

並列化は、トランザクション・リカバリ、レプリケーション、SQL実行など、様々な機能で使用できます。ここで説明しているSQLのパラレル実行の場合、1つの文の実行フェーズ全体を通して、複数のパラレル実行サーバー・プロセスが対応付けられます。文の処理が完了すると、その文に対応付けられていたプロセスが他の文を処理できるようになります。

ノート:

データベースでパラレルSQL実行を無効にするには、PARALLEL_MAX_SERVERS初期化パラメータ値を0に設定します。

関連項目:

5.8.2 セッションのパラレル実行の変更

セッションのSQLのパラレル実行は、ALTER SESSION文を使用して制御できます。

5.8.2.1 SQLのパラレル実行を使用禁止にする方法

SQLのパラレル実行は、ALTER SESSION DISABLE PARALLEL DML|DDL|QUERY文で使用禁止にできます。この文を発行した後は、後続のすべてのDML(INSERTUPDATEDELETE)、DDL(CREATEALTER)または問合せ(SELECT)操作がシリアルに実行されます。関係する表または索引にパラレル属性が指定されている場合でも、それとは無関係に文はシリアルに実行されます。ただし、PARALLELヒントが指定された文は、セッションの設定を無効にします。

  • DML、DDLまたは問合せ操作を無効にするために、適切なALTER SESSION DISABLE PARALLEL文を実行します。

たとえば、パラレルDDL操作を無効にするには、次の文を実行します。

ALTER SESSION DISABLE PARALLEL DDL;
5.8.2.2 SQLのパラレル実行を使用可能にする方法

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;
5.8.2.3 SQLのパラレル実行の強制

ALTER SESSION FORCE PARALLEL DML|DDL|QUERY文を発行すると、後続のすべてのDML、DDLまたは問合せ文をパラレルで実行するように強制できます。

特定の並列度を強制的に適用して、後続の文に対応付けられたPARALLEL句を無効にできます。ALTER SESSION文で並列度を指定しなかった場合は、デフォルトの並列度が使用されます。文レベルのパラレル・ヒントを指定すると、強制的な並列度がオーバーライドされます。表レベルのパラレル・ヒントの場合、動作は、すべての表にヒントが提供されているかどうかによって異なります。すべての表に表レベルのパラレル・ヒントが含まれる場合、それらのヒントの中で最大の値が使用されます。少なくとも1つの表に表レベルのパラレル・ヒントが含まれていない場合、使用される並列度は、パラレル・ヒント間で最も高い値およびALTER SESSIONコマンドで指定された並列度です。

パラレル実行を強制する手順は、次のとおりです。

  • ALTER SESSION FORCE PARALLEL文を実行します。

たとえば、次の文は、後続の文のパラレル実行を強制し、優先する並列度を5に設定します。

ALTER SESSION FORCE PARALLEL DDL PARALLEL 5;

5.9 外部プロシージャのプロセスの管理

外部プロシージャは、プログラミング言語で作成され、共有ライブラリに格納されるプロシージャまたはファンクションです。Oracleサーバーは、PL/SQLルーチンを使用して、外部プロシージャまたはファンクションをコールできます。

5.9.1 外部プロシージャについて

外部プロシージャはC、C++、Javaなどのプログラミング言語で記述されているプロシージャであり、データベースの外部でコンパイルおよび格納された後、ユーザー・セッションによってコールされます。たとえば、PL/SQLプログラム・ユニットから、特別な用途の処理を実行するのに必要な1つ以上のCルーチンをコールできます。

これらのコール可能ルーチンは、Dynamic Link Library(DLL)またはJavaクラス・メソッドの場合はライブラリ・ユニットに格納されており、ベース言語で登録されています。Oracle Databaseには、コール仕様という特別な用途のインタフェースが用意されており、ユーザーはこのインタフェースを使用して外部プロシージャをコールできます。

ユーザー・セッションによって外部プロシージャが呼び出されると、データベースによって外部プロシージャ・エージェントがデータベースのホスト・コンピュータ上で開始されます。エージェントのデフォルトの名前はextprocです。各セッションには専用エージェントがあります。必要に応じて、エージェントが特定のオペレーティング・システム・ユーザーとして実行されるよう、資格証明を作成できます。セッションが終了すると、データベースではそのエージェントを終了します。

ユーザー・アプリケーションは、外部プロシージャ・エージェントに対してDLLまたはライブラリ・ユニットの名前、外部プロシージャの名前およびすべての関連するパラメータを渡します。次に、外部プロシージャ・エージェントはDLLまたはライブラリ・ユニットをロードして外部プロシージャを実行し、外部プロシージャから返された値をアプリケーションに返送します。

関連項目:

外部プロシージャの詳細は、『Oracle Database開発ガイド』

5.9.2 外部プロシージャ・コールを有効化するためのDBAのタスク

外部プロシージャ・コールを有効にするには、リスナーの変更およびライブラリの管理が必要です。

外部プロシージャ・コールを有効にするには、次の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 LIBRARYCREATE ANY LIBRARYALTER ANY LIBRARYEXECUTE ANY LIBRARYEXECUTE ON library_nameおよびEXECUTE ON directory_objectを開発者に付与します。

      これらの権限の明示的付与は、信頼できるユーザーに対してのみ行ってください。決してPUBLICロールに対して付与しないでください。ライブラリにPL/SQLインタフェースを作成する場合、EXECUTE権限のみをPL/SQLインタフェースに付与してください。基礎になるライブラリにEXECUTEを付与しないでください。PL/SQLインタフェースを作成するには、ライブラリに対するEXECUTEオブジェクト権限が必要です。ただし、ユーザーは自らのスキーマに対しては自動的にこの権限を持っています。ライブラリに対してEXECUTEオブジェクト権限を明示的に付与する必要はほとんどりません。

関連項目:

5.10 セッションの終了

時々、現行のユーザー・セッションを停止する必要があります。たとえば、管理操作を実行する場合に、すべての管理セッション以外のセッションを停止する必要があります。

5.10.1 セッションの終了について

セッションが停止すると、そのセッションのアクティブ・トランザクションがロールバックされ、そのセッションが保持していたリソース(ロックやメモリー領域など)がただちに解放されて、他のセッションで使用可能になります。

SQL文ALTER SYSTEM KILL SESSIONを使用して、現行のセッションを停止します。次の文は、システム識別子が7でシリアル番号が15のセッションを停止します。

ALTER SYSTEM KILL SESSION '7,15';

DBMS_SERVICE.DISCONNECT_SESSIONプロシージャを使用して、現行インスタンスにおいて指定したサービスからセッションを停止することもできます。

関連項目:

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

5.10.2 停止するセッションの識別

停止するセッションを識別するには、セッションの索引番号とシリアル番号を指定します。

セッションのシステム識別子(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リファレンス』

5.10.3 アクティブ・セッションの停止

アクティブなセッションを終了すると、セッションが終了します。

セッションの終了時にユーザー・セッションがトランザクションを処理している場合(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;
/

5.10.4 非アクティブ・セッションの停止

停止時にセッションがOracle Databaseに対してSQLコールを実行していない場合(INACTIVE)、ORA-00028のメッセージはただちには返されません。このメッセージは、その後ユーザーが停止したセッションを使用しようとしたときに返されます。

非アクティブ・セッションを停止すると、V$SESSIONビューのセッションのSTATUSKILLEDになります。停止したセッションの行は、ユーザーが再びそのセッションを使用しようとしてORA-00028メッセージを受け取った後、V$SESSIONから削除されます。

次の例では、非アクティブ・セッションを停止しています。最初にV$SESSIONを問い合せてセッションのSIDSERIAL#を識別してから、セッションを停止しています。

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.

5.10.5 セッション内のSQL文の取消し

セッション内のSQL文は、ALTER SYSTEM CANCEL SQL文を使用して取消しできます。

セッションを終了するのではなく、セッション内の高負荷SQL文を取り消すことができます。DML文を取り消すと、その文はロールバックされます。

ALTER SYSTEM CANCEL SQL文に必須の句は次のとおりです。

  • SID – セッションID

  • SERIAL – セッション・シリアル番号

ALTER SYSTEM CANCEL SQL文のオプションの句は次のとおりです。

  • INST_ID – インスタンスID

  • SQL_ID – SQL文のSQL ID

セッションのこの情報は、GV$SESSIONビューを問い合せることで確認できます。

SQL文を取り消す場合の構文は、次のとおりです。

ALTER SYSTEM CANCEL SQL 'SID, SERIAL, @INST_ID, SQL_ID';

次の例では、セッション識別子が20、セッション・シリアル番号が51142、SQL IDが8vu7s907prbgrのSQL文を取り消します。

ALTER SYSTEM CANCEL SQL '20, 51142, 8vu7s907prbgr';

ノート:

  • @INST_IDの指定を省略すると、現在のセッションのインスタンスIDが使用されます。

  • SQL_IDの指定を省略すると、指定されたセッションで現在実行中のSQL文が終了されます。

関連項目:

5.11 プロセスおよびセッションのデータ・ディクショナリ・ビュー

プロセスおよびセッションの情報について一連のデータ・ディクショナリ・ビューを問い合せることができます。

ビュー 説明

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文に関する統計情報も提供します。