4 パフォーマンスを考慮したデータベースの構成
この章では、パフォーマンスを考慮してデータベースを構成するための、オラクル社の方法論の概要を説明しています。パフォーマンスの修正はOracle Databaseに対して継続的に実行できますが、データベースの初期構成を適切に行うことにより、多大な利益を得ることができます。
この章の構成は、次のとおりです。
初期インスタンス構成のパフォーマンスの考慮事項
データベースに重要なパフォーマンス面の影響を与えるデータベース・インスタンスの初期構成オプションは次のとおりです。
-
初期化パラメータ
-
UNDO領域
-
REDOログ・ファイル
-
表領域
ノート:
Database Configuration Assistant (DBCA)を使用してデータベースを作成する場合、提供されるシード・データベースには必要な基本的初期化パラメータが組み込まれており、このドキュメントで説明するパフォーマンス推奨事項を満たしています。
関連項目:
-
Database Configuration Assistantを使用したデータベースの作成方法を学習するには、『Oracle Database管理者ガイド』を参照してください。
-
SQL文を使用したデータベースの作成方法を学習するには、『Oracle Database管理者ガイド』を参照してください。
初期化パラメータ
実行中のOracleデータベース・インスタンスは、初期化パラメータ・ファイルで設定される初期化パラメータを使用して構成されます。これらのパラメータは、パフォーマンスへの影響を含め、実行中のインスタンスの動作に影響を与えます。一般的に、関連する設定がほとんどない非常に単純な初期化ファイルで、ほとんどの状況に対応できます。次の表に示す少数のパラメータを除き、初期化ファイルはパフォーマンス・チューニングを行う最初の場所ではありません。
次の表に、最小初期化ファイルに必要なパラメータを示します。これらのパラメータは必須ですが、パフォーマンスに影響を与えません。
表4-1 パフォーマンスに影響を与えない必要な初期化パラメータ
パラメータ | 説明 |
---|---|
|
データベースの名前。これは、環境変数 |
|
インターネット・ドット表記法による、データベースの場所。 |
|
1セッション当たりのカーソル(アクティブなSQL文)の最大数に対する制限。設定はアプリケーションにより異なり、推奨値は500です。 |
|
異なるディスク・ドライブ上に少なくとも2つのファイルを含めるように設定して、制御ファイルの消失による障害を防ぎます。 |
|
データベースに割り当てることのできるファイルの最大数に設定します。 |
次の表に、パフォーマンスの考慮事項として設定する、最も重要なパラメータを示します。
表4-2 パフォーマンスに影響を与える重要な初期化パラメータ
パラメータ | 説明 |
---|---|
|
互換性を維持しておくOracleデータベースのリリースを指定します。このパラメータを使用すると、新しい機能を自分の環境でテストせずに、ただちに本番システムで新しいリリースで改善された機能を利用できるようになります。アプリケーションがOracle Databaseの特定のリリース用に設計されていて、実際にはそれより後のリリースをインストールする場合は、このパラメータをアプリケーション設計時のリリースに設定してください。 |
|
データベース・ファイルに格納され、SGAにキャッシュされるOracleデータベース・ブロックのサイズを設定します。値の範囲はオペレーティング・システムにより異なりますが、一般的にトランザクション処理システムの場合は8192で、データベース・ウェアハウス・システムの場合はさらに大きい値となります。 |
|
すべてのSGAコンポーネントのサイズ合計を指定します。 |
|
インスタンスに添付されたすべてのサーバー・プロセスに利用できるターゲット集計PGAメモリーを指定します。 |
|
そのインスタンスで起動できるプロセスの最大数を設定します。このパラメータは、他のパラメータ値の多くがこのパラメータから導出されるため、設定する最も重要なプライマリ・パラメータとなります。 |
|
これは、デフォルトでPROCESSESの値から設定されます。ただし、共有サーバーを使用する場合は、導出された値では不十分である可能性があります。 |
|
データベースで使用するUNDO領域管理モードを指定します。デフォルトは |
|
インスタンス起動時に使用されるUNDO表領域を指定します。 |
UNDO領域
データベースは、読取り一貫性、リカバリおよびロールバック文で使用するデータを格納するために、UNDO領域を使用します。このデータは1つ以上のUNDO表領域に格納されます。Database Configuration Assistant(DBCA)を使用してデータベースを作成すると、UNDO表領域が自動的に作成されます。UNDO表領域を手動で作成するには、CREATE DATABASE
文にUNDO
TABLESPACE
句を追加します。
UNDOデータを自動的に管理するため、Oracle Databaseでは、UNDOセグメントを透過的に作成および管理する自動UNDO管理を使用します。自動UNDO管理を有効にするには、UNDO_MANAGEMENT
初期化パラメータをAUTO
(デフォルト設定)に設定します。指定しない場合、UNDO_MANAGEMENT
初期化パラメータでは、AUTO
設定が使用されます。自動UNDO管理の使用をお薦めするのは、データベース管理が大幅に簡素化され、UNDO(ロールバック)セグメントを手動でチューニングする必要がないためです。ロールバック・セグメントを使用する手動UNDO管理は、下位互換性のためにサポートされています。
V$UNDOSTAT
ビューには、UNDO領域を監視およびチューニングするための統計が含まれています。このビューを使用して、現行のワークロードに必要なUNDO領域の大きさをより的確に見積ることができます。この情報を使用して、UNDO使用量を簡単にチューニングすることもできます。V$ROLLSTAT
ビューには、UNDO表領域内のUNDOセグメントの動作に関する情報が含まれています。
関連項目:
-
UNDO管理アドバイザについて学習するには、『Oracle Database 2日でデータベース管理者』と、Oracle Enterprise Manager Cloud Control (Cloud Control)のオンライン・ヘルプを参照してください
-
自動UNDO管理を使用したUNDO領域の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
-
V$ROLLSTAT
ビューの詳細は、Oracle Databaseリファレンスを参照してください。 -
V$UNDOSTAT
ビューの詳細は、Oracle Databaseリファレンスを参照してください。
REDOログ・ファイル
REDOログ・ファイルのサイズはパフォーマンスに影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下します。
REDOログ・ファイルのサイズはLGWRのパフォーマンスに影響を与えませんが、DBWRおよびチェックポイントの動作に影響を与える可能性があります。 チェックポイントの頻度には、ログ・ファイルのサイズやFAST_START_MTTR_TARGET
初期化パラメータの設定など、複数の要因が影響します。インスタンスのリカバリ時間を制限するためにFAST_START_MTTR_TARGET
パラメータが設定されている場合、Oracle Databaseは自動的にチェックポイントを必要に応じて頻繁に試みます。この場合は、ログ・ファイルが小さすぎることによるチェックポイントの追加発生を防ぐために、ログ・ファイルを十分なサイズに設定する必要があります。最適なサイズは、V$INSTANCE_RECOVERY
ビューからOPTIMAL_LOGFILE_SIZE
列を問い合せることで取得できます。また、Oracle Enterprise Manager Cloud Control (Cloud Control)の「REDOログ・グループ」ページでも、サイズ設定のアドバイスを取得できます。
REDOログ・ファイルに特定のサイズを推奨できない場合もありますが、100MBから数GBの範囲内にあるREDOログ・ファイルが妥当であると考えられます。システムが生成するREDOの量に従って、オンラインREDOログ・ファイルをサイズ設定します。およその目安として、多くても20分ごとに1回ログ・ファイルを切り替えます。
関連項目:
REDOログの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
表領域
Database Configuration Assistant(DBCA)を使用してデータベースを作成する場合、シード・データベースには必要な表領域すべてが自動的に組み込まれます。DBCAを使用しないように選択した場合は、データベースの作成後に追加表領域を作成する必要があります。
すべてのデータベースには、SYSTEM
およびSYSAUX
表領域に加えて複数の表領域が必要です。これらの追加表領域は次のとおりです。
-
読取り一貫性、リカバリおよびUNDO文に関する情報を格納するためのUNDO表領域
-
アプリケーションで使用する少なくとも1つの表領域(ほとんどの場合、アプリケーションには複数の表領域が必要です)
データ・ファイルが多数ある非常に大規模な表領域の場合は、複数のALTER TABLESPACE ... ADD DATAFILE
文を同時に実行できます。表領域の作成時、表領域を構成するデータファイルは特殊な空のブロック・イメージで初期化されます。一時ファイルは初期化されません。
Oracle Databaseでは、この初期化により、すべてのデータファイル全体に書込みが行えるようになりますが、この処理をシリアルに実行すると時間がかかります。したがって、複数のCREATE TABLESPACE
文を同時に実行して、表領域の作成を高速化します。永続的な表の場合、表領域作成時にローカルまたはグローバルのいずれかのエクステント管理を選択するかで、パフォーマンスに大きな影響を与える可能性があります。読取り操作と比べて、普通または大規模な、挿入、変更または削除操作を行う永続的な表領域の場合は、ローカル・エクステント管理を選択します。
永続表領域 - 自動セグメント領域管理
永続的な表領域では、自動セグメント領域管理を使用することをお薦めします。ビットマップ表領域と呼ばれることも多い永続表領域は、ビットマップ・セグメント領域管理によってローカルに管理される表領域です。
関連項目:
-
空き領域管理の詳細は、『Oracle Database概要』を参照してください。
-
表領域の自動セグメント領域管理の作成および使用の詳細は、『Oracle Database管理者ガイド』を参照してください。
一時表領域
一時表領域を正しく構成すると、ディスク・ソートのパフォーマンスの最適化に役立ちます。一時表領域はディクショナリ管理を行うこともローカル管理を行うこともできます。UNIFORM
エクステント・サイズが1MB
の、ローカル管理の一時表領域を使用することをお薦めします。
一時表領域アクティビティを監視して、一時セグメントに割り当てるエクステントの数をチェックする必要があります。たとえば、多数のユーザーが一時表を同時に使用しているような状況で、アプリケーションで一時表が頻繁に使用される場合は、1回の使用につき1つ以上のエクステントが必要になるため、エクステント・サイズを256KBなどの小さい値に設定できます。一時表領域はすべて均一サイズのローカル管理エクステントで作成されるため、EXTENT
MANAGEMENT
LOCAL
句は一時表領域ではオプションです。SIZE
のデフォルトは1MB
です。
関連項目:
-
一時表領域の管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
-
一時表領域の詳細は、『Oracle Database概要』を参照してください。
-
TEMPORARY
句を含むCREATE
文およびALTER
TABLESPACE
文の使用の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
最適なパフォーマンスを得る表の作成とメンテナンス
アプリケーションをインストールする際、最初のステップで、必要なすべての表および索引を作成します。表のようなセグメントを作成すると、データ用の領域がデータベースで割り当てられます。後続のデータベース操作によってデータ容量が増大し、割り当てられた領域を上回るようになると、Oracle Databaseはそのセグメントを拡張します。
表および索引を作成する際には、次の点に注意してください。
表の圧縮
ヒープ構成表は、どのような種類のアプリケーションにも透過的な圧縮形式で格納できます。データベース・ブロック内の圧縮データは自己完結型です。つまり、ブロック内の未圧縮データの再作成に必要なすべての情報がそのブロック内にあります。バッファ・キャッシュでも、ブロックは圧縮されています。表圧縮により、ディスク記憶域のみでなく、メモリー使用量、特にバッファ・キャッシュ要件も削減されます。表へのアクセスに必要なI/O操作の量が削減され、バッファ・キャッシュ・ヒットの確率が高まることで、パフォーマンスの向上が実現します。
Oracle Databaseの拡張圧縮オプションを使用すると、データ・ウェアハウスおよびOLTPアプリケーションを含め、どのタイプのアプリケーションもワークロードのパフォーマンスが向上し、データベースに必要なディスク領域を削減します。拡張圧縮機能は、構造化データ、非構造化データ、バックアップ・データおよびネットワーク・データを含め、すべてのタイプのデータに使用できます。
圧縮係数の見積り
表圧縮は、個々のブロック内の列値の繰返しを解消することによって機能します。ブロック内のすべての行と列の重複値は、ブロックの先頭にある、そのブロックのシンボル表と呼ばれるものに一度格納されます。こうした値の出現箇所はすべて、シンボル表への簡単な参照で置き換えられます。繰返しの値が多いブロックほど圧縮率が高くなります。
大規模な表を圧縮する前に、予測される圧縮係数を見積る必要があります。圧縮係数は、圧縮されていない形式で情報を格納するために必要なブロック数を、圧縮記憶域に必要なブロック数で除算した値として定義されます。圧縮される表を代表する少数のデータ・ブロックをサンプリングし、圧縮されていない場合と圧縮された場合の各ブロックの平均レコード数を比較することで、圧縮係数を見積ることができます。これまでの経験では、およそ1000のデータ・ブロックを使用することで、きわめて正確な圧縮係数の見積りが可能であることがわかっています。サンプリングのブロック数が多いほど、見積り結果が正確になる点に注意してください。
チューニングによる圧縮率向上
Oracle Databaseでは、多くの場合、特別なチューニングなしで、優れた圧縮係数を達成しています。DBAまたはアプリケーション開発者は、圧縮が行われる際にレコードを再構成することによって、圧縮係数のチューニングを試行できます。チューニングを行うと、圧縮係数が若干改善されるケースもあれば大きく改善されるケースもあります。
圧縮係数を高めるには、データ・ブロック内の値の繰返しの可能性を高くする必要があります。達成できる圧縮係数は、特定の列または列のペアのカーディナリティ(列値の繰返しの可能性を表す)およびこれらの列の行の平均長さによって異なります。表圧縮では、単一列の重複値が圧縮されるだけでなく、可能な場合は、複数列値のペアの使用が試行されます。データ配分について熟知していない場合、最適な順序の予測は非常に困難です。
属性クラスタ化表の使用
属性クラスタ化表は、ユーザー指定のクラスタリング・ディレクティブに基づいて近接度の近いデータをディスク上に格納する、ヒープ構成表です。表内に格納されるデータの順序付けが特定の列に基づくか、複数列のI/O削減を許容する特殊なアルゴリズムに基づくかはディレクティブによって判断されます。属性クラスタリングは一括挿入操作(INSERT/*+APPEND*/
またはALTER TABLE ... MOVE PARTITION
コマンドなど)のみに使用可能で、従来のDMLについては無視されます。
ゾーン・マップとともに物理I/Oを削減することで、属性クラスタ化表の使用は、表スキャンのI/Oコストを大幅に削減できます。さらに、同じ値がディスク上で近い場所にあるほどデータはより簡単に圧縮できるため、データ圧縮も改善できます。
関連項目:
-
属性クラスタ化表の詳細は、『Oracle Database概要』を参照してください
-
属性クラスタ化表の使用の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください
未使用領域の解放
一般に、時間経過とともにセグメント領域が断片化されたり、更新および削除操作の結果としてセグメントに多数の空き領域が生じます。このようにして粗密に移入されたオブジェクトは、問合せおよびDML操作中にパフォーマンスを低下させる可能性があります。オブジェクトに解放可能な領域がある場合は、セグメントを圧縮して縮小するか、またはセグメントの終わりにある未使用領域を割当て解除できます。
Oracle Databaseにはセグメント・アドバイザが用意されており、オブジェクト内の領域の断片化レベルに基づいて、オブジェクトに解放可能な領域があるかどうかのアドバイスを提供します。
関連項目:
セグメント・アドバイザおよびスキーマ・オブジェクトの領域の管理の詳細は、Oracle Database管理者ガイドを参照してください
データの索引付け
最も効率的に索引を作成するタイミングは、データのロード後です。この方法では、領域管理が簡単になり、行が挿入されるたびに索引がメンテナンスされることもありません。この技術は、SQL*Loaderにより自動的に使用されますが、他の方法で初期データをロードする場合は、手動で索引を作成する必要があります。また、CREATE
INDEX
文のPARALLEL
句を使用して、索引作成をパラレルで実行することもできます。ただし、SQL*Loaderでは索引作成をパラレル化できないため、データのロード後に索引を手動でパラレルに作成する必要があります。
関連項目:
SQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照してください。
ソート用データのメモリーの指定
データを含む表での索引の作成中に、データをソートする必要があります。このソートは、すべての使用可能なメモリーをソートに使用する場合に最も高速に行われます。PGA_AGGREGATE_TARGET
初期化パラメータを設定して、SQL作業領域の自動サイズ指定を有効にすることをお薦めします。
関連項目:
-
PGAメモリー管理の詳細は、「プログラム・グローバル領域のチューニング」を参照してください
-
PGA_AGGREGATE_TARGET
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
共有サーバーのパフォーマンスの考慮事項
共有サーバーを使用すると、プロセス数と、データベース・ホストでのメモリー使用量が削減されます。共有サーバーは、多数のOLTPユーザーが断続的なトランザクションを実行するデータベースに有効です。
また、データベースへの単位時間当たりの接続数が高いシステムでは、一般的に専用サーバーよりも共有サーバーを使用する方が適しています。共有サーバーでは、接続リクエストを受信する際に、ディスパッチャを使用して同時接続リクエストを処理できます。しかし、専用サーバーの場合は、接続固有の専用サーバーが、接続リクエストごとに順次初期化されます。
共有サーバー・アーキテクチャを使用すると、特定のデータベース機能のパフォーマンスが向上しますが、パフォーマンスがいくらか低下する機能もあります。たとえば、パラレル実行がアクティブな場合、セッションが別の共有サーバーに移行できないことがあります。
クライアントからのリクエストが処理された後でもセッションを移行できない場合があります。これは、すべてのユーザー情報がUGAに格納されているとは限らないためです。サーバーがクライアントからのリクエストを処理するとしても、UGAに格納されていなかったユーザー状態にはアクセスできません。この状況を回避するために、個々の共有サーバーは、しばしばユーザー・セッションにバインドされた状態のままである必要があります。
関連項目:
-
共有サーバーの管理方法を学習するには、『Oracle Database管理者ガイド』を参照してください。
-
共有サーバー用のディスパッチャの構成方法を学習するには、『Oracle Database Net Services管理者ガイド』を参照してください。
ある種の機能を使用する場合、あるサーバーがセッションに長期間バインドされる可能性があるため、追加の共有サーバーを構成する必要が生じる場合があります。
ディスパッチャ固有のビューを使用する競合の識別および低減
次のビューによってディスパッチャのパフォーマンス統計が提供されます。
-
V$DISPATCHER
: ディスパッチャ・プロセスの一般的な情報 -
V$DISPATCHER_RATE
: ディスパッチャ・プロセスの統計情報
V$DISPATCHER_RATE
ビューには、いくつかのカテゴリについてディスパッチャ統計の現在、平均および最大の値が含まれています。接頭辞CUR_
が付いている統計は、現在のサンプルの統計です。接頭辞AVG_
が付いている統計は、収集期間の開始後の統計の平均値です。接頭辞MAX_
が付いている統計は、統計収集の開始後のこれらのカテゴリでの最大値です。
ディスパッチャのパフォーマンスを調べるには、V$DISPATCHER_RATE
ビューを問い合せて、最大値と現在の値を比較します。現在のシステム・スループットが適切なレスポンス時間を提供し、このビューの現在の値が平均値に近くかつ最大値を下回る場合、共有サーバー環境は最適にチューニングされていると考えられます。
現在の値と平均値が最大値を大きく下回る場合は、ディスパッチャ数の削減を検討してください。反対に、現在の値と平均値が最大値に近い場合は、ディスパッチャを追加する場合があります。システム使用率が低い期間と高い期間の両方でV$DISPATCHER_RATE
統計を調べてみることを一般規則としてお薦めします。共有サーバーの負荷パターンを識別した後で、それに従ってパラメータを調整します。
必要に応じて、システムのストレス・テストを実行し、定期的にV$DISPATCHER_RATE
統計をポーリングすることによってワークロードをシミュレートすることもできます。これらの統計の正しい解釈方法は、プラットフォームごとに異なります。アプリケーションの種類が変わると、V$DISPATCHER_RATE
に記録される統計値も大幅に異なる可能性があります。
関連項目:
-
V$DISPATCHERおよびV$DISPATCHER_RATEビューの詳細は、
『Oracle Databaseリファレンス』
を参照してください。
ディスパッチャ・プロセスの競合の低減
-
ディスパッチャ・プロセスの追加
ディスパッチャ・プロセスの総数は、
MAX_DISPATCHERS
初期化パラメータの値で制限されます。ディスパッチャ・プロセスを追加する前に、この値を増やす必要がある場合があります。 -
接続プーリングの有効化
システム負荷が増加し、ディスパッチャ・スループットが最大限になった場合は、すぐにディスパッチャを追加することが必ずしも適切とはかぎりません。そのかわりに、接続プーリングによってより多くのユーザーをサポートできるようにディスパッチャを構成することを検討してください。
-
セッション多重化の有効化
多重化は、Connection Managerプロセスで、複数ユーザーから個別のディスパッチャへのネットワーク・セッションを確立およびメンテナンスする場合に使用されます。たとえば、いくつかのユーザー・プロセスがConnection Managerプロセスからの1つの接続を経由して1つのディスパッチャに接続できます。ディスパッチャ・プロセスが最大限に使用されるため、セッションの多重化は有効です。多重化は、ディスパッチャ間のデータベース・リンク・セッションを多重化する場合にも役立ちます。
関連項目:
-
ディスパッチャ・プロセスの構成方法を学習するには、『Oracle Database管理者ガイド』を参照してください
-
接続ポーリングの構成方法を学習するには、『Oracle Database Net Services管理者ガイド』を参照してください。
-
DISPATCHERS
およびMAX_DISPATCHERS
初期化パラメータについて学習するには、『Oracle Databaseリファレンス』を参照してください
-
共有サーバーの競合の識別
リクエスト・キューにおいて待機時間が一貫して増加する場合、それは共有サーバーの競合を示します。待機時間のデータを調べるには、動的パフォーマンス・ビューV$QUEUE
を使用します。このビューには、共有サーバーのリクエスト・キューのアクティビティを示す統計が含まれます。デフォルトでは、SYS
ユーザーと、SELECT
ANY
TABLE
システム権限を持っている他のユーザー(SYSTEM
など)のみがこのビューを使用できます。表4-3は、リクエストの待機時間とキュー内のリクエスト数を示す列のリストです。
表4-3 V$QUEUE内の待機時間およびリクエストの列
列 | 説明 |
---|---|
|
キューに存在していた全リクエストについての待機時間の合計(100分の1秒単位) |
|
キューに存在していたリクエストの総数 |
アプリケーションの実行時に次のSQL文を発行して、この統計を数回監視してください。
SELECT DECODE(TOTALQ, 0, 'No Requests', WAIT/TOTALQ || ' HUNDREDTHS OF SECONDS') "AVERAGE WAIT TIME PER REQUESTS" FROM V$QUEUE WHERE TYPE = 'COMMON';
この問合せは、次のような計算結果を戻します。
AVERAGE WAIT TIME PER REQUEST ----------------------------- .090909 HUNDREDTHS OF SECONDS
この結果から、リクエストは処理される前にキューにおいて平均0.09待機したことがわかります(単位は100分の1秒)。
また、次の問合せを発行することによって、現在実行中の共有サーバーの数が判断できます。
SELECT COUNT(*) "Shared Server Processes" FROM V$SHARED_SERVER WHERE STATUS != 'QUIT';
この問合せの結果を次に示します。
Shared Server Processes ----------------------- 10
共有サーバーでのリソース競合を検出した場合は、まず、共有プールとラージ・プールを調査し、これがメモリー競合でないことを確認します。パフォーマンスが改善されない場合は、共有サーバー・プロセス競合を低減するためにさらにリソースを作成してください。その場合は、オプションのサーバー・プロセス初期化パラメータを変更します。
-
MAX_DISPATCHERS
-
MAX_SHARED_SERVERS
-
DISPATCHERS
-
SHARED_SERVERS
関連項目:
共有サーバー・プロセスの初期化パラメータの設定方法を学習するには、『Oracle Database管理者ガイド』を参照してください。
事前起動プロセスによるクライアント接続のパフォーマンスの向上
Oracle Databaseでは、専用ブローカ接続モードが有効化されたとき、またはスレッド化実行モードが有効化されたときに、サーバー・プロセスのプールが事前起動されます。この場合、クライアントがデータベース接続をリクエストしたときは常に、プロセス・プールから既存のサーバー・プロセスへの専用の接続が取得されるため、クライアント接続の効率が向上します。
V$PROCESS_POOL
ビューにこれらのサーバー・プロセス・プールの情報が表示され、DBMS_PROCESS
パッケージを使用してこれらのプールを管理できます。
関連項目:
-
Oracle Databaseでの事前起動プロセスの管理の詳細は、Oracle Database管理者ガイドを参照してください
-
DBMS_PROCESS
パッケージの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください