Oracle データベース アーキテクチャ（データファイル）

データファイル

マルチテナントコンテナーデータベース（CDB）は、ユーザーデータとメタデータを格納する物理ファイルのセット。
メタデータは、データベースサーバーに関する構造/構成/制御情報で構成される。

CDB

CDBは、1つのCDBルートコンテナー（ルートとも呼ばれる）、1つのシードプラガブルデータベース（シードPDB）、0個以上のユーザー作成プラガブルデータベース（単にPDBと呼ばれる）、および0個以上のアプリケーションコンテナーで構成される。
CDB全体はシステムコンテナーと呼ばれる。 ユーザーまたはアプリケーションにとって、PDBは論理的には別個のデータベースとして表示される。

CDB$ROOTという名前のCDBルートには、複数のデータファイル、制御ファイル、REDOログファイル、フラッシュバックログ、およびアーカイブREDOログファイルが含まれている。
データファイルには、Oracle社が提供するメタデータと、すべてのPDBで共有される一般的なユーザー（すべてのコンテナーで既知のユーザー）が格納される。

PDB

PDB$SEEDという名前のシードPDBは、新しいPDBの作成に使用できる複数のデータファイルを含むシステム提供のPDBテンプレート。

通常のPDBには、アプリケーションのサポートに必要なデータとコードを含む複数のデータファイルが含まれている。 例えば、人事アプリケーションなどがある。
ユーザーはPDBのみを操作し、シードPDBまたはルートコンテナーは操作しない。 CDBには複数のPDBを作成できる。
マルチテナントアーキテクチャの目標の1つは、各PDBがアプリケーションと1対1の関係を持つこと。

アプリケーションコンテナー

アプリケーションコンテナーは、アプリケーションのデータを格納するCDB内のPDBのオプションのコレクション。
アプリケーションコンテナを作成する目的は、単一のマスターアプリケーション定義を持つこと。
CDBには複数のアプリケーションコンテナを含めることができる。

データベースは、すべてのデータベースデータをまとめて格納するテーブルスペースと呼ばれる論理ストレージユニットに分割される。
各テーブルスペースは、1つ以上のデータファイルを表す。
ルートコンテナーと通常のPDBには、SYSTEM、SYSAUX、USERS、TEMP、およびUNDOテーブルスペース（通常のPDBではオプション）がある。
シードPDBには、SYSTEM、SYSAUX、TEMP、およびオプションのUNDOテーブルスペースがある。

Oracle データベース アーキテクチャ（データベース バッファキャッシュ）

バッファキャッシュ

データベースバッファキャッシュは、バッファキャッシュとも呼ばれ、データファイルから読み取られたデータブロックのコピーを格納するシステムグローバル領域（SGA）のメモリ領域。
バッファは、データベースのブロックサイズのメモリのチャンク。各バッファには、データベースバッファアドレス（DBA）と呼ばれるアドレスがある。
データベースインスタンスに同時に接続されているすべてのユーザーは、バッファキャッシュへのアクセスを共有する。
バッファキャッシュの目的は、物理I/Oを最適化し、頻繁にアクセスされるブロックをバッファキャッシュに保持し、アクセス頻度の低いブロックをディスクに書き込むこと。

Oracle Databaseユーザー・プロセスが特定のデータを初めて必要とするとき、データベース・バッファ・キャッシュでデータを検索する。
プロセスがすでにキャッシュにあるデータを見つけた場合（キャッシュヒット）、メモリから直接データを読み取ることができる。
プロセスがキャッシュ内のデータを見つけられない場合（キャッシュミス）、データにアクセスする前に、ディスク上のデータファイルからキャッシュ内のバッファーにデータブロックをコピーする必要がある。
キャッシュヒットを介してデータにアクセスする方が、キャッシュミスを介してデータにアクセスするよりも高速。

キャッシュ内のバッファーは、最長時間未使用（LRU）リストとタッチカウントの組み合わせを使用する複雑なアルゴリズムによって管理される。
LRUは、最近使用されたブロックがディスクアクセスを最小限に抑えるためにメモリにとどまる傾向があることを保証するのに役立つ。

データベースバッファキャッシュは、次のもので構成されています。

• Defaultプール：ブロックが通常キャッシュされる場所。デフォルトのブロックサイズは 8KBです。個別のプールを手動で構成しない限り、デフォルトのプールが唯一のバッファープールとなる。他のプールのオプションの構成は、デフォルトのプールには影響しない。

• KEEPプール：頻繁にアクセスされたが、スペース不足のためにデフォルトのプールから古くなったブロックを対象としている。キープバッファプールの目的は、指定されたオブジェクトをメモリに保持することで、I/O操作を回避すること。

• Recycleプール：使用頻度の低いブロックを対象とする。リサイクルプールは、指定されたオブジェクトがキャッシュ内の不要なスペースを消費するのを防ぐ。

• デフォルト以外のバッファー・プール：2KB/4KB/16KB/32KBの非標準ブロック・サイズを使用するテーブルスペース用。デフォルト以外の各ブロックサイズには、独自のプールがある。 Oracle Databaseは、これらのプールのブロックをデフォルトのプールと同じ方法で管理する。

• データベーススマートフラッシュキャッシュ（フラッシュキャッシュ）：フラッシュデバイスを使用して、メインメモリを追加せずにバッファーキャッシュの有効サイズを増やすことができる。フラッシュキャッシュは、磁気ディスクからデータを読み取る代わりに、データベースキャッシュの頻繁にアクセスされるデータをフラッシュメモリに格納することで、データベースのパフォーマンスを向上させることができる。データベースがデータを要求すると、システムは最初にデータベースバッファキャッシュを調べる。データが見つからない場合、システムはDatabase Smart Flash Cacheバッファを調べる。 そこでデータが見つからない場合にのみ、ディスクストレージを調べる。 Oracle Real Application Clusters環境では、すべてのインスタンスでフラッシュ・キャッシュを構成するか、インスタンスでフラッシュ・キャッシュを構成しないようにするべき。

• Least Recently Used list (LRU): ダーティおよびダーティでないバッファへのポインタが含まれている。LRUリストには、ホットエンドとコールドエンドがある。コールドバッファは、最近使用されていないバッファ。 ホットバッファは頻繁にアクセスされ、最近使用されている。 概念的には、LRUは1つだけだが、データの並行性のために、データベースは実際には複数のLRUを使用する。

• Checkpoint queue

• フラッシュバッファ領域：DEFAULTフラッシュLRUチェーンとKEEPフラッシュLRUチェーンで構成される。Database Smart Flash Cacheがない場合、プロセスがブロックにアクセスしようとして、そのブロックがバッファーキャッシュに存在しない場合、最初にブロックがディスクからメモリに読み込まれる（物理読み込み）。 インメモリバッファキャッシュがいっぱいになると、バッファは、最長時間未使用（LRU）メカニズムに基づいてメモリから追い出されます。 データベーススマートフラッシュキャッシュを使用すると、クリーンなインメモリバッファーが期限切れになった場合に、バッファーの内容がデータベースライタープロセス（DBWn）によってバックグラウンドでフラッシュキャッシュに書き込まれ、バッファーヘッダーはいずれかのメタデータとしてメモリに保持される。FLASH_CACHEオブジェクト属性の値に応じて、DEFAULTフラッシュまたはKEEPフラッシュLRUリスト。 KEEPフラッシュLRUリストは、バッファーヘッダーを別のリストに保持して、通常のバッファーヘッダーがそれらを置き換えないようにするために使用される。したがって、KEEPとして指定されたオブジェクトに属するフラッシュバッファヘッダーは、フラッシュキャッシュに長く留まる傾向がある。FLASH_CACHEオブジェクト属性がNONEに設定されている場合、システムは対応するバッファをフラッシュキャッシュまたはメモリに保持しない。すでにメモリ不足になっているバッファに再度アクセスすると、システムはフラッシュキャッシュをチェックする。バッファーが見つかると、フラッシュキャッシュからバッファーを読み取る。これは、ディスクからの読み取り時間のほんの一部しかかからない。Real Application Clusters（RAC）全体のフラッシュキャッシュバッファーの一貫性は、キャッシュフュージョンと同じ方法で維持される。フラッシュキャッシュは拡張キャッシュであり、ダイレクトパスI/Oはバッファキャッシュを完全にバイパスするため、この機能はダイレクトパスI/Oをサポートしない。フラッシュキャッシュへの書き込みはチェックポイントにカウントされないため、バッファをチェックポイントするためにバッファをメモリに読み込む必要がある場合があるため、システムはダーティバッファをフラッシュキャッシュに配置しないことに注意する。

Oracle データベース アーキテクチャ（ラージプール）

ラージプール

ラージプールは、データベース管理者が構成できるオプションのメモリ領域であり、次のものに大容量のメモリを割り当てることができる。
- ユーザーグローバルエリア（UGA）：共有サーバーとOracle XAインターフェースのセッションメモリ（トランザクションが複数のデータベースと対話する場合に使用）
- I/Oバッファー領域：I/Oサーバープロセス、並列クエリ操作で使用されるメッセージバッファー、Recovery Manager（RMAN）I/Oスレーブ用のバッファー、アドバンスドキューイングメモリテーブルストレージ
- 遅延挿入プール：高速取り込み機能により、MEMOPTIMIZE FOR WRITEとして定義されたテーブルのデータベースへの高頻度の単一行データ挿入が可能になる。 高速取り込みによる挿入は、遅延挿入とも呼ばれます。 これらは最初に大きなプールにバッファーされ、後でオブジェクトごとにセッションごとに1MB相当の書き込みの後、または60秒後に、スペース管理コーディネーター（SMCO）およびWxxxスレーブバックグラウンドプロセスによって非同期にディスクに書き込まれる。 このプールでバッファリングされたデータは、コミットされていても、SMCOバックグラウンドプロセスがスイープするまで、ライターを含むどのセッションでも読み取ることができない。
プールは、最適化されたテーブルの最初に挿入された行の大きなプールで初期化される。 十分なスペースがある場合、2Gは大きなプールから割り当てられる。 大きなプールに十分なスペースがない場合、ORA-4031が内部的に検出され、自動的にクリアされる。 割り当ては、要求されたサイズの半分で再試行される。 それでも大きなプールに十分なスペースがない場合は、割り当てが512Mおよび256Mで再試行される。その後、インスタンスが再起動されるまで、機能は無効になる。 プールが初期化されると、サイズは静的なままで、伸び縮みすることはない。
- Free memory

ラージプールは、共有プールから割り当てられた他のメモリと同じLRU（Least Recently Used）リストを使用する共有プールの予約スペースとは異なる。 ラージプールにはLRUリストがない。 メモリの一部が割り当てられ、使用が完了するまで解放できない。

クライアントからの接続

ユーザーからの要求は、ユーザーのSQLステートメントの一部である単一のAPI呼び出し。 専用サーバー環境では、1つのサーバープロセスが1つのクライアントプロセスの要求を処理する。 各サーバープロセスは、CPUサイクルやメモリなどのシステムリソースを使用する。 共有サーバー環境では、次のアクションが発生する。
1. クライアントアプリケーションがデータベースインスタンスに要求を送信し、その要求がディスパッチャーによって受信される。
2. ディスパッチャは、リクエストを大きなプールのリクエストキューに配置する。
3. 要求は、次に使用可能な共有サーバープロセスによって取得される。 共有サーバープロセスは、共通の要求キューで新しい要求をチェックし、先入れ先出し方式で新しい要求を取得する。 1つの共有サーバープロセスがキュー内の1つの要求を取得する。
4. 共有サーバープロセスは、データベースに必要なすべての呼び出しを行って、要求を完了する。まず、共有サーバープロセスが共有プールのライブラリキャッシュにアクセスして、要求されたアイテムを確認する。たとえば、テーブルが存在するかどうか、ユーザーに適切な権限があるかどうかなどをチェックする。次に、共有サーバープロセスがバッファキャッシュにアクセスしてデータを取得する。データがそこにない場合、共有サーバープロセスはディスクにアクセスする。異なる共有サーバープロセスが各データベース呼び出しを処理できる。したがって、クエリを解析し、最初の行をフェッチし、次の行をフェッチし、結果セットを閉じる要求は、それぞれ異なる共有サーバープロセスによって処理される場合がある。異なる共有サーバープロセスが各データベース呼び出しを処理する可能性があるため、UGAには各クライアントセッションに関する情報が含まれているため、ユーザーグローバル領域（UGA）は共有メモリ領域である必要がある。または逆に、UGAには各クライアントセッションに関する情報が含まれており、共有サーバープロセスはセッションのデータベース呼び出しを処理できるため、すべての共有サーバープロセスで使用できる必要がある。
5. 要求が完了すると、共有サーバープロセスは、応答を大きなプールの呼び出し側ディスパッチャーの応答キューに配置する。 各ディスパッチャーには独自の応答キューがある。
6. 応答キューはディスパッチャに応答を送信する。
7. ディスパッチャは完了したリクエストを適切なクライアントアプリケーションに返す。

Oracle データベース アーキテクチャ（共有プール）

共有プールはシステムグローバルエリア（SGA）のコンポーネントであり、さまざまなタイプのプログラムデータのキャッシュを担当する。
例えば、共有プールには、解析されたSQL、PL/SQLコード、システムパラメータ、およびデータディクショナリ情報が格納される。
共有プールは、データベースで発生するほとんどすべての操作に関与している。
例えば、ユーザーがSQL文を実行すると、Oracle Databaseは共有プールにアクセスする。

共有プールはいくつかのサブコンポーネントに分かれている。

ライブラリキャッシュ

実行可能なSQLおよびPL/SQLコードを格納する共有プールのメモリ構造。
このキャッシュには、共有SQLおよびPL/SQL領域と、ロックやライブラリキャッシュハンドルなどの制御構造が含まれている。
SQL文が実行されると、データベースは以前に実行されたコードを再利用しようとする。
SQLステートメントの解析済み表現がライブラリキャッシュに存在し、共有できる場合、データベースはコードを再利用する。
このアクションは、ソフト解析またはライブラリキャッシュヒットと呼ばれる。
それ以外の場合、データベースは、ハード解析またはライブラリキャッシュミスと呼ばれる、アプリケーションコードの新しい実行可能バージョンを構築する必要がある。

予約済みプール

共有プール内のメモリー領域であり、Oracle Databaseはこれを使用して、連続した大量のメモリーを割り当てることができる。
データベースは、共有プールからチャンクでメモリを割り当てる。
チャンキングにより、1つの連続した領域を必要とせずに、ラージオブジェクト（5 KB以上）をキャッシュにロードできる。
このようにして、データベースは断片化のために連続したメモリが不足する可能性を減らす。

データディクショナリキャッシュ

データベースオブジェクト（ディクショナリデータ）に関する情報を格納する。
このキャッシュは、データをバッファではなく行として保持するため、行キャッシュとも呼ばれる。

サーバー結果キャッシュ

共有プール内のメモリプールであり、結果セットを保持する。
サーバー結果キャッシュには、同じインフラストラクチャを共有するSQLクエリ結果キャッシュとPL/SQL関数結果キャッシュが含まれる。
SQLクエリ結果キャッシュには、クエリの結果とクエリフラグメントが格納される。
ほとんどのアプリケーションは、このパフォーマンスの向上の恩恵を受けている。
PL/SQLファンクションの結果キャッシュには、ファンクションの結果セットが格納される。
結果のキャッシュに適した候補は、比較的静的なデータに依存する、頻繁に呼び出される関数。

その他のコンポーネント

エンキュー、ラッチ、情報ライフサイクル管理（ILM）ビットマップテーブル、アクティブセッション履歴（ASH）バッファー、およびその他のマイナーメモリ構造が含まれる。
エンキューは、データベースリソースへのアクセスをシリアル化する共有メモリ構造（ロック）。
これらは、セッションまたはトランザクションに関連付けることができる。
例：制御ファイルトランザクション、データファイル、インスタンスリカバリ、メディアリカバリ、トランザクションリカバリ、ジョブキューなど。
ラッチは、SGA内の共有データ構造を同時アクセスから保護するために使用される低レベルのシリアル化制御メカニズムとして使用される。
例：行キャッシュオブジェクト、ライブラリキャッシュピン、ログファイルの並列書き込み。

Oracle データベース アーキテクチャ（バックグラウンドプロセス）

バックグラウンドプロセス

バックグラウンドプロセスはデータベースインスタンスの一部であり、データベースを操作し、複数のユーザーのパフォーマンスを最大化するために必要なメンテナンスタスクを実行する。
各バックグラウンドプロセスは固有のタスクを実行しますが、他のプロセスと連携する。
Oracle Databaseでは、データベース・インスタンスを起動すると、バックグラウンド・プロセスが自動的に作成される。
存在するバックグラウンドプロセスは、データベースで使用されている機能によって異なる。
データベースインスタンスを開始すると、必須のバックグラウンドプロセスが自動的に開始される。
必要に応じ、オプションのバックグラウンドプロセスを後で開始できる。

必須バックグラウンドプロセス

必須のバックグラウンドプロセスは、すべての典型的なデータベース構成に存在する。
これらのプロセスは、最小構成の初期化パラメーターファイルで開始された読み取り/書き込みデータベースインスタンスでデフォルトで実行される。
読み取り専用データベースインスタンスは、これらのプロセスの一部を無効にする。
必須のバックグラウンドプロセスには、プロセスモニタープロセス（PMON）、プロセスマネージャープロセス（PMAN）、リスナー登録プロセス（LREG）、システムモニタープロセス（SMON）、データベースライタープロセス（DBWn）、チェックポイントプロセス（CKPT）、管理機能モニタープロセス（ MMON）、Manageability Monitor Liteプロセス（MMNL）、Recovererプロセス（RECO）、およびLog Writerプロセス（LGWR）がある。

オプションのバックグラウンドプロセス

ほとんどのオプションのバックグラウンドプロセスは、タスクまたは機能に固有。
一般的なオプションのプロセスには、アーカイバプロセス（ARCn）、ジョブキューコーディネータプロセス（CJQ0）、リカバリライタプロセス（RVWR）、フラッシュバックデータアーカイブプロセス（FBDA）、スペース管理コーディネータプロセス（SMCO）などがある。

スレーブプロセス

スレーブプロセスは、他のプロセスに代わって作業を実行するバックグラウンドプロセス。
たとえば、ディスパッチャプロセス（Dnnn）や共有サーバープロセス（Snnn）など。

参考資料

Oracle Database データベース・リファレンス 20c
F バックグラウンド・プロセス
https://docs.oracle.com/cd/F32587_01/refrn/background-processes.html#GUID-86184690-5531-405F-AA05-BB935F57B76D

Oracle データベース アーキテクチャ（PGA）

プログラムグローバルエリア（PGA）は、サーバーとバックグラウンドプロセスでのみ使用されるデータと制御情報を含む非共有メモリ領域。
Oracle Databaseは、クライアント・プログラムにかわってデータベースへの接続を処理するサーバー・プロセスを作成する。
専用サーバー環境では、開始されるサーバーおよびバックグラウンドプロセスごとに1つのPGAが作成される。
各PGAは、スタックスペース、ハッシュ領域、ビットマップマージ領域、およびユーザーグローバル領域（UGA）で構成される。
PGAは、関連するサーバーまたはそれを使用するバックグラウンドプロセスが終了すると割り当て解除される。

共有サーバー接続

複数のクライアントユーザーがサーバープロセスを共有する。
UGAは大きなプールに移動され、PGAにはスタックスペース、ハッシュ領域、およびビットマップマージ領域のみが残る。

専用サーバー接続

PGAは次のコンポーネントで構成される。
- SQL作業域：ソート域は、ORDER BYやGROUP BYなどのデータを順序付ける関数によって使用される。
- セッションメモリ：このユーザーセッションデータストレージ領域は、ログオン情報やデータベースセッションで必要なその他の情報などのセッション変数に割り当てられる。
- OLAPプール：データブロックに相当するOLAPデータページを管理する。
- プライベートSQL領域：この領域には、解析されたSQLステートメントに関する情報と、処理のためのその他のセッション固有の情報が保持される。
サーバープロセスがSQLまたはPL/SQLコードを実行すると、プロセスはプライベートSQL領域を使用して、バインド変数値、クエリ実行状態情報、およびクエリ実行作業領域を格納する。
同じまたは異なるセッションの複数のプライベートSQL領域は、SGAの単一の実行プランを指すことができる。
永続領域にはバインド変数値が含まれている。
ランタイム領域には、クエリ実行状態情報が含まれている。
カーソルは、プライベートSQL領域の特定の領域への名前またはハンドル。カーソルは、クライアント側ではポインタとして、サーバー側では状態と考えることができる。
カーソルはプライベートSQL領域と密接に関連しているため、これらの用語は同じ意味で使用される場合がある。
- スタック領域：スタックスペースは、セッション変数と配列を保持するために割り当てられたメモリ。
- ハッシュ領域：この領域は、テーブルのハッシュ結合を実行するために使用される。
- ビットマップマージ領域：この領域は、複数のビットマップインデックスのスキャンから取得したデータをマージするために使用される。

Oracle データベース アーキテクチャ（SGA）

システム・グローバル領域（SGA）は、1つのOracleデータベース・インスタンスのデータおよび制御情報を含むメモリー領域。
すべてのサーバープロセスとバックグラウンドプロセスがSGAを共有する。
データベースインスタンスを開始すると、SGAに割り当てられたメモリの量が表示される。
SGAには、以下のデータ構造が含まれている。

共有プール

ユーザー間で共有できるさまざまな構成をキャッシュする。例えば、共有プールには、解析されたSQL、PL/SQLコード、システムパラメータ、およびデータディクショナリ情報が格納される。
共有プールは、データベースで発生するほとんどすべての操作に関与している。例えば、ユーザーがSQL文を実行すると、Oracle Databaseは共有プールにアクセスする。

フラッシュバック・バッファ

SGAのオプションのコンポーネント。フラッシュバックデータベースを有効にすると、リカバリライタープロセス（RVWR）と呼ばれるバックグラウンドプロセスが開始される。
RVWRは、変更されたブロックを定期的にバッファキャッシュからフラッシュバックバッファにコピーし、フラッシュバックデータベースデータをフラッシュバックバッファからフラッシュバックデータベースログに順次書き込む。

データベースバッファキャッシュ

データファイルから読み取られたデータブロックのコピーを格納するメモリ領域。
バッファは、バッファマネージャが現在または最近使用されたデータブロックを一時的にキャッシュするメインメモリアドレス。
データベースインスタンスに同時に接続されているすべてのユーザーは、バッファキャッシュへのアクセスを共有する。

データベーススマートフラッシュキャッシュ

SolarisまたはOracle Linuxで実行されているデータベースのデータベースバッファーキャッシュのオプションのメモリ拡張。
データベースブロックにレベル2キャッシュを提供する。データウェアハウス（DW）環境での読み取り集中型オンライントランザクション処理（OLTP）ワークロードとアドホッククエリおよび一括データ変更の両方で、応答時間と全体的なスループットを向上させることができる。
データベーススマートフラッシュキャッシュは、フラッシュメモリを使用するソリッドステートストレージデバイスである1つ以上のフラッシュディスクデバイスに存在する。
データベーススマートフラッシュキャッシュは、通常、追加のメインメモリよりも経済的で、ディスクドライブより1桁高速。

REDOログ・バッファ

データベースに加えられた変更に関する情報を保持するSGAの循環バッファ。
この情報は、REDOエントリに格納される。
REDOエントリーには、データ操作言語（DML）、データ定義言語（DDL）、または内部操作によってデータベースに加えられた変更を再構築（またはREDO）するために必要な情報が含まれている。
REDOエントリーは、必要に応じてデータベースのリカバリーに使用される。

ラージプール

共有プールに適切なサイズよりも大きいメモリ割り当て用のオプションのメモリ領域。
ラージプールは、共有サーバーのユーザーグローバル領域（UGA）とOracle XAインターフェース（トランザクションが複数のデータベースとやり取りする場合に使用）、ステートメントの並列実行で使用されるメッセージバッファー、Recovery Managerのバッファー（RMAN）I/Oスレーブにに大きなメモリ割り当てを提供できる。

インメモリ領域

オプションのコンポーネントであり、オブジェクト（テーブル、パーティション、およびその他のタイプ）を、列形式と呼ばれる新しい形式でメモリに格納できる。
この形式では、スキャン、結合、および集計を従来のディスク上の形式よりもはるかに高速に実行できるため、OLTP環境とDW環境の両方に高速なレポートとDMLパフォーマンスを提供する。
この機能は、多くの列を返す少数の行を操作するOLTPではなく、多くの行を返す少数の列を操作する分析アプリケーションに特に役立つ。

Memoptimizeプール

キーベースのクエリに高いパフォーマンスとスケーラビリティを提供するオプションのコンポーネント。
Memoptimizeプールには、memoptimizeバッファー領域とハッシュインデックスの2つの部分がある。
高速ルックアップはmemoptimizeプールのハッシュインデックス構造を使用して、バッファーキャッシュに永続的に固定された特定のテーブル（MEMOPTIMIZE FOR READに対して有効）のブロックへの高速アクセスを提供し、ディスクI/Oを回避する。
memoptimizeプール内のバッファーは、データベースバッファーキャッシュから完全に分離されている。
ハッシュインデックスは、Memoptimized Rowstoreの構成時に作成され、Oracleデータベースによって自動的に維持される。

Shared I/Oプール（SecureFiles）

SecureFileラージオブジェクト（LOB）での大規模なI / O操作に使用される。
LOBは、大量のデータを保持するように設計された一連のデータ型。 SecureFileは、重複排除、暗号化、および圧縮を可能にするLOBストレージパラメータ。

Streamsプール

Oracle Streams、Data Pump、GoldenGateの統合された取得および適用プロセスで使用される。
Streamsプールは、バッファリングされたキューメッセージを格納し、Oracle Streamsのキャプチャプロセスと適用プロセスにメモリを提供する。
特に構成しない限り、Streamsプールのサイズはゼロから始まる。
Oracle Streamsを使用すると、プール・サイズは必要に応じて動的に増加する。

Javaプール

Java仮想マシン（JVM）内のすべてのセッション固有のJavaコードおよびデータに使用される。
Javaプール・メモリーは、Oracle Databaseが実行されているモードに応じて、様々な方法で使用される。

固定SGA

データベースとデータベースインスタンスの状態に関する一般的な情報、およびプロセス間で通信される情報を含む内部のハウスキーピングエリア。