ラージ・プール

ラージ・プールは、データベース・インスタンスおよびシステム・グローバル領域(SGA)内のオプションのメモリー領域です。次の領域に対して大きなメモリー割当てを提供するように、ラージ・プールを構成できます。

共有サーバー環境およびOracle XAインタフェース(トランザクションが複数のデータベースと対話する場合に使用される)のユーザー・グローバル領域(UGA)(セッション・メモリー)。専用サーバー環境では、UGAはプログラム・グローバル領域(PGA)に格納されます。
I/Oバッファ領域には、I/Oサーバー・プロセス、パラレル問合せ操作のためのメッセージ・バッファ、Recovery Manager (RMAN) I/Oワーカー用のバッファ、およびアドバンスト・キューイングのメモリー表記憶域が含まれます。
遅延挿入プールは、高速収集機能によって使用され、MEMOPTIMIZE FOR WRITEとして定義されている表に対して、高頻度で単一行データ挿入をデータベースに実行できます。高速収集による挿入は、遅延挿入とも呼ばれます。最初はラージ・プールにバッファされ、その後、各オブジェクトのセッションごとに1MB相当の書込みが行われた後または60秒後に、領域管理コーディネータ・プロセス(SMCO)およびWxxxワーカーのバックグラウンド・プロセスによってディスクに非同期に書き込まれます。SMCOバックグラウンド・プロセスがスイープするまで、セッションはコミットしても、このプールにバッファされているデータを読み取れません。プールは、ラージ・プール内のmemoptimizeされた表の最初に挿入された行で初期化されます。十分な領域がある場合は、ラージ・プールから2Gが割り当てられます。ラージ・プールに十分な領域がない場合は、ORA-4031が内部的に検出され、自動的にクリアされます。割当ては、リクエストされたサイズの半分で再試行されます。依然としてラージ・プールに十分な領域がない場合は、512Mおよび256Mで割当てが再試行され、その後インスタンスが再起動されるまでこの機能は無効になります。プールの初期化後もサイズは静的なままです。拡大または縮小できません。
空きメモリー

ラージ・プールは、共有プールから割り当てられた他のメモリーと同じ最低使用頻度(LRU)リストを使用する、共有プール内に予約された領域とは異なります。ラージ・プールには、LRUリストはありません。割り当てられた各メモリーは、そのメモリーの使用が終了するまでは解放できません。

ユーザーからのリクエストは、ユーザーのSQL文の一部である単一のAPIコールです。

専用サーバー環境では、1つの専用のサーバー・プロセスが、単一のクライアント・プロセスのリクエストを処理します。各サーバー・プロセスは、CPUサイクルやメモリーなどのシステム・リソースを使用します。

共有サーバー環境では、次の処理が発生します。

クライアント・プロセスはデータベース・インスタンスにリクエストを送信し、ディスパッチャ・プロセス(Dnnn)はそのリクエストを受信します。
ディスパッチャは、リクエストをラージ・プールのリクエスト・キューに配置します。
次に使用可能な共有サーバー・プロセス(Snnn)がリクエストを取得します。共有サーバー・プロセスは、共通のリクエスト・キューをチェックして新しいリクエストがないかどうかを調べ、先入れ先出し方式に基づいて新しいリクエストをピックアップします。1つの共有サーバー・プロセスが、キュー内の1つのリクエストをピックアップします。
共有サーバー・プロセスは、データベースに対して必要なすべてのコールを実行してリクエストを完了します。まず、共有サーバー・プロセスは、共有プール内のライブラリ・キャッシュにアクセスして、要求された項目を確認します。たとえば、表が存在するかどうか、ユーザーが適切な権限を持っているかどうかなどがチェックされます。次に、共有サーバー・プロセスはバッファ・キャッシュにアクセスしてデータを取得します。データが存在しない場合は、共有サーバー・プロセスがディスクにアクセスします。各データベース・コールは異なるサーバー・プロセスで処理できます。したがって、問合せを解析するリクエスト、最初の行をフェッチするリクエスト、次の行をフェッチするリクエスト、結果セットをクローズするリクエストは、それぞれ異なる共有サーバー・プロセスで処理できます。異なる共有サーバー・プロセスで各データベース・コールを処理する可能性があり、UGAには各クライアント・セッションに関する情報が含まれているため、UGAは共有メモリー領域である必要があります。逆の視点でも、UGAには各クライアント・セッションに関する情報が格納されており、任意の共有サーバー・プロセスがセッションのデータベース・コールを処理する可能性があるため、すべての共有サーバー・プロセスがUGAを使用できる必要があります。
リクエストが完了した後、共有サーバー・プロセスは、ラージ・プール内のコール元ディスパッチャのレスポンス・キューにレスポンスを配置します。各ディスパッチャには、固有のレスポンス・キューがあります。
レスポンス・キューは、ディスパッチャにレスポンスを送信します。
ディスパッチャは、完了したリクエストを適切なクライアント・プロセスに戻します。