11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
この章の内容は次のとおりです。
Oracle Databaseでは、インスタンスに接続されているユーザー・プロセスの要求を処理するために、サーバー・プロセスが作成されます。サーバー・プロセスには、次の2つのプロセスがあります。
データベースでは、専用サーバー・プロセスは常に使用可能な状態ですが、共有サーバーは、1つ以上の初期化パラメータを特別に設定して、構成および使用可能にする必要があります。
図4-1「Oracle Databaseの専用サーバー・プロセス」は、専用サーバー・プロセスの動作の仕組みを示しています。この図では、専用サーバー・プロセスを介して、2つのユーザー・プロセスがデータベースに接続されています。
一般的には、共有サーバーを使用し、ディスパッチャを介して接続することをお薦めします。これは、図4-2「Oracle Databaseの共有サーバー・プロセス」に図示されています。共有サーバー・プロセスは、実行中のインスタンスに必要なプロセスの数を少なくすることができるため、効率が向上します。
ただし、次の状況では、ユーザーと管理者は、専用サーバー・プロセスを使用して明示的にインスタンスに接続する必要があります。
Oracle Databaseが共有サーバー用に構成されている場合に専用サーバー接続を要求するには、専用サーバーを使用するように構成されているネット・サービス名を使用して接続する必要があります。具体的に言うと、ネット・サービス名の接続記述子にSERVER=DEDICATED句を含めます。
専用サーバー・プロセスを使用した注文入力システムを例にとって考えてみます。顧客が注文受付に電話で商品を注文すると、担当者はその注文をデータベースに入力します。取引のほどんどの間、担当者は顧客と電話で話しています。この間、サーバー・プロセスは必要ないため、担当者のユーザー・プロセス専用のサーバー・プロセスはアイドル状態のままです。アイドル状態のサーバー・プロセスはシステム・リソースを保持しているため、他の担当者が注文を入力する際にシステムのパフォーマンスが低下します。
共有サーバー・アーキテクチャでは、接続ごとに専用サーバー・プロセスは必要ありません（図4-2を参照）。
共有サーバー構成では、クライアントのユーザー・プロセスはディスパッチャに接続します。このディスパッチャには、同時に複数のクライアント接続をサポートする機能があります。各クライアント接続はバーチャル・サーキットにバインドされます。バーチャル・サーキットとは、ディスパッチャがクライアントのデータベース接続要求と応答に使用する共有メモリーの一部です。ディスパッチャは、要求が到着すると、バーチャル・サーキットを共通キューに入れます。
アイドル状態の共有サーバー・プロセスは、共通キューからバーチャル・サーキットを選択して要求を処理し、そのバーチャル・サーキットを解放して、共通キューから別のバーチャル・サーキットを取り出します。このアプローチでは、小さいサーバー・プロセス・プールで大量のクライアントを処理することが可能です。専用サーバー・モデルと比較した共有サーバー・アーキテクチャの大きな利点は、システム・リソースが少なくて済むため、ユーザー数の増加に対応できることです。
リソース管理を容易にするために、共有サーバーを接続プーリングに対応するように構成できます。接続プーリングを使用すると、データベース・サーバーでプロトコル接続のタイムアウトを実行し、これらの接続をアクティブ・セッションの処理に使用できるようにすることで、1つのディスパッチャでサポートするユーザー数が増加します。さらに、共有サーバーはセッションの多重化に対応するよう構成できます。セッションの多重化では、オペレーティング・システムのリソースを節約するために、複数のセッションが単一のネットワーク接続を介して転送されるように結合されます。
共有サーバー・アーキテクチャには、Oracle Net Servicesが必要です。共有サーバーを使用するユーザー・プロセスは、Oracle Databaseインスタンスと同じマシン上にある場合でも、必ずOracle Net Servicesを介して接続してください。
データベース常駐接続プーリング（DRCP）は、データベース接続を取得し、比較的短時間の処理を実行した後、データベース接続を解放するような一般的なWebアプリケーション使用に対して、データベース・サーバーの接続プールを提供します。 DRCPは専用サーバーをプールします。 プール・サーバーは、サーバー・フォアグラウンド・プロセスとデータベース・セッションの組合せに相当します。
DRCPは、中間層プロセス内のスレッド間で接続を共有する中間層接続プールを補完します。また、DRCPを使用すると、同じ中間層ホスト上の中間層プロセス間、および異なる中間層ホスト上の中間層プロセス間でもデータベース接続を共有できます。この結果、大量のクライアント接続をサポートするために必要となる基本データベース・リソースが大幅に減少するため、データベース層のメモリー・フットプリントが縮小し、中間層とデータベース層の両方のスケーラビリティが向上します。すぐに使用できるサーバーのプールを保持することで、クライアント接続の作成と切断のコストが削減されるという利点もあります。
DRCPは、中間層接続プーリングを実行できない（PHP/Apacheなどの）マルチプロセスのシングル・スレッド・アプリケーション・サーバーを含むアーキテクチャに特に適しています。データベースは、DRCPを使用すると同時接続の数を数万まで増やすことができます。
データベース常駐接続プーリングは、複数のクライアントがデータベースにアクセスする場合で、次のいずれかに該当する場合に有効です。
類似アプリケーションとは、同じデータベース資格証明で接続し、同じスキーマを使用するアプリケーションです。
データベース常駐接続プーリングの使用には次の利点があります。
表4-1に、専用サーバー、共有サーバーおよびデータベース常駐接続プーリングの相違点を示します。
各セッションに必要なメモリーが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
プール・サーバーを使用して次の処理を実行することはできません。
プール内のデータベース・ユーザーに関係するDDL文の実行には注意が必要です。これは、プール内のDDL前のセッションをDDL後にクライアントに渡すことができるためです。たとえば、ユーザーを削除する場合は、プール内にそのユーザーのセッションが存在していないこと、およびそのユーザーとして認証されたブローカへの接続が存在していないことを確認してください。
明示的なロールが使用可能であり、プールに解放されるセッションは、後でデフォルトのログイン・ロールを必要とする（同じユーザーの）接続に渡される可能性があります。明示的なロールのあるセッションは解放せずに、かわりにセッションを終了してください。
共有メモリー・リソースは、実行時に共有サーバーを使用可能にできるように事前に構成されています。初期化パラメータ・ファイルにパラメータを指定して共有メモリー・リソースを構成する必要はありませんが、さらに環境にあわせて構成できます。ディスパッチャおよび共有サーバー・プロセス（共有サーバー）は、ALTER SYSTEM文を使用して動的に起動できます。
この項では、共有サーバーを使用可能にする方法、および共有サーバーの初期化パラメータを設定または変更する方法を説明します。この章の内容は、次のとおりです。
共有サーバー操作を制御する初期化パラメータは、次のとおりです。
SHARED_SERVERS: 起動する初期共有サーバー数および最低限保持する共有サーバー数を指定します。共有サーバーを使用するための必須パラメータはこのパラメータのみです。
MAX_SHARED_SERVERS: 同時に実行可能な共有サーバーの最大数を指定します。
SHARED_SERVER_SESSIONS: 同時に実行可能な共有サーバー・ユーザー・セッションの合計数を指定します。このパラメータを設定すると、専用サーバー用のユーザー・セッションを予約できます。
DISPATCHERS: 共有サーバー・アーキテクチャのディスパッチャ・プロセスを構成します。
MAX_DISPATCHERS: 同時に実行可能なディスパッチャ・プロセスの最大数を指定します。このパラメータは現在は無視してかまいません。将来のリリースで、同時接続数に基づいてディスパッチャ数が自動調整されるときに使用されます。
CIRCUITS: 受信および発信用のネットワーク・セッションに使用可能なバーチャル・サーキットの合計数を指定します。共有サーバーを使用可能にするには、SHARED_SERVERS初期化パラメータに0（ゼロ）より大きい値を設定します。他の共有サーバー初期化パラメータの設定は不要です。共有サーバーが動作するには最低1つのディスパッチャが必要であるため、構成されていない場合でも、ディスパッチャは起動されます。ディスパッチャについては、「ディスパッチャの構成」を参照してください。
共有サーバーを動的に起動するには、ALTER SYSTEM文を使用してSHARED_SERVERSパラメータに0（ゼロ）以外の値を設定するか、またはデータベースの起動時にSHARED_SERVERSを初期化パラメータ・ファイルに組み込みます。SHARED_SERVERSが初期化パラメータ・ファイルに組み込まれていない場合、または値が0（ゼロ）に設定されている場合、共有サーバーはデータベースの起動時に使用可能になりません。
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初期化パラメータによって設定）
PROCESSESが24未満に設定されている場合は2スロット）
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初期化パラメータは、同時共有サーバー・ユーザー・セッションの最大数を指定します。動的パラメータであるこのパラメータを設定すると、データベース・セッションを専用サーバー用に確保できます。この結果、データベースのバックアップやリカバリなど、専用サーバーを必要とする管理タスクが共有サーバー・セッションによって専有されることはありません。
このパラメータにデフォルト値はありません。値が指定されていない場合は、SESSIONS初期化パラメータの制限範囲内で共有サーバー・セッションが必要に応じて作成されます。
CIRCUITSパラメータによって、共有メモリーに作成可能なバーチャル・サーキットの許容最大数が設定されます。このパラメータにデフォルトはありません。値が指定されていない場合は、DISPATCHERS初期化パラメータおよびシステム・リソースの制限範囲内でサーキットが必要に応じて作成されます。
DISPATCHERS初期化パラメータは、共有サーバー・アーキテクチャのディスパッチャ・プロセスを構成します。共有サーバーが動作するには、少なくとも1つのディスパッチャ・プロセスが必要です。ディスパッチャを指定しない場合でも、SHARED_SERVERに0（ゼロ）以外の値を設定して共有サーバーを使用可能にすると、Oracle Databaseによって、TCPプロトコルに対して1つのディスパッチャがデフォルトで作成されます。この構成に相当するDISPATCHERS初期化パラメータの明示的な設定は次のようになります
dispatchers="(PROTOCOL=tcp)"
次のいずれかの条件に適合する場合は、DISPATCHERS初期化パラメータを使用して、追加のディスパッチャを構成できます。
この項では、DISPATCHERS初期化パラメータで指定可能な属性について簡単に説明します。
プロトコル・アドレスは必須です。プロトコル・アドレスは次の属性を1つ以上使用して指定します。
次の属性は、構成に必要なディスパッチャの数を指定します。この属性はオプションで、デフォルトは1です。
| 属性 | 説明 |
|---|---|
|
|
起動する初期ディスパッチャの数を指定します。 |
次の属性は、構成の各ディスパッチャのネットワーク属性に関する情報をインスタンスに通知します。これらの属性はすべてオプションです。
完全な属性名または先頭の3文字以上で構成されたサブストリングを指定できます。たとえば、SESSIONS=3、SES=3、SESS=3またはSESSI=3のように指定できます。
オペレーティング・システムに対して各プロセスごとに可能な接続数を把握した後、インスタンス起動時に各ネットワーク・プロトコルに対して作成する初期ディスパッチャの数を、次の式を使用して計算します。
Number of dispatchers = CEIL ( max. concurrent sessions / connections for each dispatcher )
CEILは、最も近い整数に切り上げた結果を返します。
たとえば、各プロセスごとに970の接続数をサポートできるシステムがある場合に、次の最大セッション数を仮定します。
この場合は、次のように、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アドレスでリスニングする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が考慮される予定です。
次のビューを監視し、ディスパッチャ・プロセスの負荷を判別します。
これらのビューによって、ディスパッチャ・プロセスに対する負荷が一貫して高いことが判明した場合は、追加のディスパッチャ・プロセスを起動してユーザー要求をルーティングすることで、パフォーマンスを改善できます。逆に、ディスパッチャの負荷が一貫して低い場合は、ディスパッチャの数を少なくすることにより、パフォーマンスを改善できます。
インスタンスの実行中にディスパッチャの数を動的に変更するには、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)';
現在起動しているTCP/IP用のディスパッチャ・プロセスが2以下の場合は、新しいプロセスが作成されます。複数のSSL付きTCP/IP用のディスパッチャ・プロセスが現在1つ以上起動している場合は、接続ユーザーの切断にあわせて余分なプロセスが停止されます。
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（ゼロ）に設定して使用禁止にします。新しいクライアントは共有モードでは接続できなくなります。ただし、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 = '';
次のビューは、共有サーバー構成情報の取得やパフォーマンスの監視に使用できます。
データベース・サーバーは、データベース常駐接続プーリングを使用できるように事前に構成されています。ただし、この機能は、接続プールを起動して明示的に使用可能にする必要があります。
この項の内容は、次のとおりです。
Oracle Databaseには、SYS_DEFAULT_CONNECTION_POOLと呼ばれるデフォルトの接続プールがあります。デフォルトでは、このプールは作成されますが起動はされません。データベース常駐接続プーリングを使用可能にするには、接続プールを明示的に起動する必要があります。
接続プールを起動する手順は、次のとおりです。
起動されると、接続プールは明示的に停止されるまでこの状態のままです。接続プールは、データベース・インスタンスが再起動されると、インスタンスの停止時点でアクティブだった場合は自動的に再起動されます。
Oracle Real Application Clusters（RAC）環境では、インスタンスを使用して接続プールを管理できます。プール構成に対する変更は、すべてのOracle RACインスタンスで適用されます。
クライアント・アプリケーションでは、接続文字列で接続タイプをPOOLEDに指定する必要があります。
次の例は、クライアントをデータベース常駐接続プールに接続する簡単な接続文字列を示しています。
oraclehost.company.com:1521/books.company.com:POOLED
次の例は、クライアントをデータベース常駐接続プールに接続するTNS接続記述子を示しています。
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=myhost) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales) (SERVER=POOLED)))
データベース常駐接続プーリングを使用禁止にするには、接続プールを明示的に停止する必要があります。次の手順を実行します。
接続プールはデフォルトのパラメータ値を使用して構成されます。DBMS_CONNECTION_POOLパッケージ内のプロシージャを使用すると、使用方法に応じて接続プールを構成できます。Oracle Real Application Clusters（RAC）環境では、構成パラメータは各Oracle RACインスタンスに適用されます。
表4-2に、接続プール用に構成可能なパラメータを示します。
DBMS_CONNECTION_POOLパッケージのCONFIGURE_POOLプロシージャを使用すると、拡張オプションを指定して接続プールを構成できます。このプロシージャは通常、接続プールのすべてのパラメータを変更する必要がある場合に使用します。
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();
表4-3に、データベース常駐接続プーリングに関する情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューを使用すると、接続プールに関する情報を取得し、データベース常駐接続プーリングのパフォーマンスを監視できます。
マルチプロセスのOracle Databaseシステムでは、最高のパフォーマンスを提供し、多くのユーザーが同時に使用できるように、バックグラウンド・プロセスが使用されています。バックグラウンド・プロセスでは、ユーザー・プロセスごとに実行される複数のデータベース・プログラムによって処理される機能が統合されます。バックグラウンド・プロセスは、非同期的にI/Oを実行して他のOracle Databaseプロセスを監視することによって、並列性を高め、パフォーマンスと信頼性を向上させます。
表4-4は、基本的なOracle Databaseバックグラウンド・プロセスを示しています。これらの多くは、このマニュアルの別の箇所に詳細な解説があります。データベース・サーバーの機能またはオプションを追加すると、バックグラウンド・プロセスの数が増える場合があります。たとえば、アドバンスト・キューイングを使用している場合は、キュー・モニター（QMNn）バックグラウンド・プロセスが存在します。また、データファイルをストレージ・サブシステムの物理デバイスにマッピングするためにFILE_MAPPING初期化パラメータを指定している場合は、FMONプロセスが存在します。
| プロセス名 | 説明 |
|---|---|
|
データベース・ライター（DBWn） |
データベース・ライターは、変更があったブロックをデータベース・バッファ・キャッシュからデータファイルに書き込みます。Oracle Databaseでは、最大20のデータベース・ライター・プロセス（DBW0〜DBW9およびDBWa〜DBWj）を使用できます。DBWnプロセスの数は、
|
|
ログ・ライター（LGWR） |
ログ・ライター・プロセスは、REDOログ・エントリをディスクに書き込みます。REDOログ・エントリは、SGAのREDOログ・バッファ内で生成されます。LGWRによって、REDOログ・エントリはREDOログ・ファイルに順次書き込まれます。データベースのREDOログが多重化されている場合、LGWRはREDOログ・エントリをREDOログ・ファイルのグループに書き込みます。ログ・ライター・プロセスの詳細は、第10章「REDOログの管理」を参照してください。 |
|
チェックポイント（CKPT） |
SGA内で変更があったすべてのデータベース・バッファは、特定の時点でDBWnによってデータファイルに書き込まれます。このイベントはチェックポイントと呼ばれます。チェックポイント・プロセスは、最新のチェックポイントを示すために、チェックポイントでDBWnにシグナルを出し、データベースのすべてのデータファイルと制御ファイルを更新する役割を持ちます。 |
|
システム・モニター（SMON） |
システム・モニターは、障害の発生したインスタンスの再起動時にリカバリを実行します。Oracle Real Application Clustersデータベースでは、1つのインスタンスのSMONプロセスが、障害を起こした他のインスタンスのインスタンス・リカバリを実行できます。また、SMONにより、不要になった一時セグメントがクリーン・アップされ、ファイル読込みエラーやオフライン・エラーのためにシステム障害時やインスタンス・リカバリ時にスキップされたデッド・トランザクションがリカバリされます。これらのトランザクションは、表領域またはファイルがオンラインに戻るときに、SMONによって最後にリカバリされます。 |
|
プロセス・モニター（PMON） |
プロセス・モニターは、ユーザー・プロセスが失敗したときにプロセス・リカバリを実行します。PMONは、キャッシュをクリーン・アップし、プロセスで使用されていたリソースを解放する役割を持ちます。また、PMONは、ディスパッチャ・プロセス（この表で後述）とサーバー・プロセスをチェックし、障害がある場合は再起動します。 |
|
アーカイバ（ARCn） |
REDOログ・ファイルは、ログ・ファイルがいっぱいになるか、ログ・スイッチが発生すると、1つ以上のアーカイバ・プロセスによってアーカイブ記憶域にコピーされます。アーカイバ・プロセスについては、第11章「アーカイブREDOログの管理」を参照してください。 |
|
リカバラ（RECO） |
リカバラ・プロセスは、ネットワーク障害やシステム障害が原因で分散データベース内で保留されている分散トランザクションを解決するために使用されます。ローカルRECOは、一定の間隔でリモート・データベースに接続し、保留されている分散トランザクションのローカル部分のコミットまたはロールバックを自動的に完了しようとします。このプロセスの詳細と開始方法は、第33章「分散トランザクションの管理」を参照してください。 |
|
ディスパッチャ（Dnnn） |
ディスパッチャは、オプションのバックグラウンド・プロセスです。これが存在するのは、共有サーバー構成を使用している場合のみです。共有サーバーについては、「Oracle Databaseの共有サーバー構成」を参照してください。 |
|
グローバル・キャッシュ・サービス（LMS） |
グローバル・キャッシュ・サービスは、Oracle Real Application Clusters環境でリソースを管理し、インスタンス間のリソース制御機能を提供します。 |
この項では、SQL文のパラレル実行の管理方法について説明します。この構成では、Oracle Databaseによって、SQL文の処理作業を複数のパラレル・プロセスに分割できます。
多数の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句が指定されている場合や、関係する表または索引にパラレル属性が指定されている場合でも、それとは無関係に文はシリアルに実行されます。
次の文は、パラレル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句を無効にできます。この文で並列度を指定しなかった場合は、デフォルトの並列度が使用されます。ただし、ヒントによって文に指定された並列度は、強制された並列度を無効にします。
次の文は、後続の文のパラレル実行を強制し、優先する並列度を5に設定します。
ALTER SESSION FORCE PARALLEL DDL PARALLEL 5;
外部プロシージャは、異なる言語で記述されている別のプログラムからコールされるプロシージャです。例として、PL/SQLプログラムから、特別な用途の処理に必要な1つ以上のCルーチンをコールする場合があげられます。
これらのコール可能ルーチンは、Dynamic Link Library（DLL）またはJavaクラス・メソッドの場合はライブラリ・ユニットに格納されており、ベース言語で登録されています。Oracle Databaseにはコール仕様という特別な用途のインタフェースが用意されており、ユーザーはこのインタフェースを使用して他の言語から外部プロシージャをコールできます。
外部プロシージャをコールするには、アプリケーションがネットワーク・リスナー・プロセスにアラートを送り、続いて、そのプロセスが外部プロシージャ・エージェントを起動します。エージェントのデフォルト名はextprocです。このエージェントは、データベース・サーバーと同じコンピュータ上に存在している必要があります。アプリケーションは、リスナーによって確立されたネットワーク接続を使用して、外部プロシージャ・エージェントにDLLまたはライブラリ・ユニットの名前、外部プロシージャの名前および関連するパラメータを渡します。次に、外部プロシージャ・エージェントはDLLまたはライブラリ・ユニットをロードして外部プロシージャを実行し、外部プロシージャから返された値をアプリケーションに返送します。
DLLへのアクセスを制御するには、データベース管理者がアプリケーション開発者に適切なDLLの実行権限を付与します。アプリケーション開発者は外部プロシージャを作成し、他のユーザーに特定の外部プロシージャの実行権限を付与します。
外部プロシージャをコールするための環境はtnsnames.oraおよびlistener.oraエントリで構成され、データベースのインストール中にデフォルトで構成されます。セキュリティ・レベルを上げるには、追加のネットワーク構成手順の実行が必要になることがあります。 これらの手順の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
現行のユーザー・セッションを停止することが必要になる場合があります。たとえば、管理操作を実行するために、管理に関係のないセッションをすべて停止する必要がある場合などです。ここでは、セッションの停止について説明します。この項の内容は、次のとおりです。
セッションが停止すると、そのセッションのアクティブ・トランザクションがロールバックされ、そのセッションが保持していたリソース（ロックやメモリー領域など）がただちに解放されて、他のセッションで使用可能になります。
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です。
セッションの停止時にユーザー・セッションがトランザクションを処理している場合（STATUSがACTIVE）、トランザクションはロールバックされ、ユーザーはただちに次のメッセージを受け取ります。
ORA-00028: セッションは強制終了されました。
ユーザーが、ORA-00028のメッセージを受け取った後、データベースに再接続する前に追加の文を実行すると、Oracle Databaseは次のメッセージを返します。
ORA-01012: ログオンされていません。
ネットワーク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.
次の表に、プロセスとセッションの管理に役立つデータ・ディクショナリ・ビューを示します。
