11gリリース1（11.1）
E05765-03
 目次 |
 索引 |
| Oracle Database 概要 11gリリース1（11.1） E05765-03 |
|
この章では、Oracle Databaseインスタンスのメモリー・アーキテクチャについて説明します。この章の内容は、次のとおりです。
Oracle Databaseでは、メモリーを使用して次のような情報を格納します。
Oracle Databaseに関連する基本的なメモリー構造は、次のような領域で構成されています。
ソフトウェア・コード領域とは、実行中または実行される可能性があるコードを格納するためのメモリー部分です。Oracle Databaseのコードはソフトウェア領域に格納されます。この場所は通常ユーザー・プログラムの格納場所とは異なり、排他的であるかまたは保護されています。
SGAは、SGAコンポーネントと呼ばれる共有メモリー構造のグループで、1つのOracle Databaseインスタンスに関するデータと制御情報が保存されています。SGAは、すべてのサーバーおよびバックグラウンド・プロセスで共有されます。SGAに保存されるデータの例としては、キャッシュ・データ・ブロックや共有SQL領域があります。
PGAは、サーバー・プロセス用のデータや制御情報を含むメモリー領域です。PGAは、サーバー・プロセスの起動時に、Oracle Databaseによって作成される非共有メモリーです。PGAにアクセスできるのはサーバー・プロセスのみです。各サーバー・プロセスにはPGAが1つあります。バックグラウンド・プロセスにも独自のPGAが割り当てられます。すべての個々のPGAで使用されるメモリーの合計は、合計インスタンスPGAメモリーと呼ばれ、個々のPGAの集合は、合計インスタンスPGA、または単にインスタンスPGAと呼ばれます。個々のPGAではなく、データベース初期化パラメータを使用してインスタンスPGAのサイズを設定します。
図8-1にこれらのメモリー構造の関係を示します。
Oracle Databaseインスタンスは、システム・グローバル領域（SGA）および一連のデータベース・プロセスにより構成されます。インスタンスを起動すると、Oracle Databaseが自動的にSGA用のメモリーを割り当て、インスタンスを停止すると、オペレーティング・システムがそのメモリーの割当てを解除します。各インスタンスには、それぞれ専用のSGAがあります。
SGAは読取り/書込み可能です。ユーザーにかわって実行するすべてのデータベース・バックグラウンド・プロセスおよびサーバー・プロセスにより、インスタンスのSGAに含まれている情報が読み取られ、データベース操作中に一部のサーバー・プロセスによりSGAへの書込みが実行されます。
SGAの一部には、バックグラウンド・プロセスがアクセスする必要のある、データベースとインスタンスの状態に関する一般的な情報が含まれています。この部分を固定SGAと呼びます。ここには、ユーザー・データは格納されません。SGAには、ロック情報などのプロセス間でやりとりされる情報も格納されます。
システムが共有サーバー・アーキテクチャを使用している場合、要求キューとレスポンス・キュー、およびPGA領域の内容の一部はSGAに格納されます。
図8-1で示すように、SGAは、いくつかのメモリー・コンポーネントで構成されています。このコンポーネントは、特定のクラスのメモリー割当て要求を満たすために使用するメモリーのプールです。
次に、最も重要なSGAコンポーネントを示します。
関連項目
データベース・バッファ・キャッシュはSGAの一部であり、データファイルから読み取ったデータ・ブロックのコピーが保持される領域です。インスタンスに同時接続されたユーザーはすべて、データベース・バッファ・キャッシュへのアクセスを共有します。
この項の内容は、次のとおりです。
このキャッシュのバッファは、書込みリストおよび最低使用頻度リスト（LRU）の2つのリストで編成されます。書込みリストには使用済バッファが保持されます。使用済バッファとは、修正されたが、まだディスクに書き込まれていないデータを含むバッファです。LRUリストは、使用可能バッファ、使用中バッファおよび書込みリストに移動していない使用済バッファを保持します。使用可能バッファは、有効なデータが含まれておらず、使用可能なバッファです。使用中バッファは、現在アクセスされているバッファです。
Oracle Databaseプロセスからバッファにアクセスするとき、そのバッファはLRUリストの最高使用頻度（MRU）側に移動します。さらに多くのバッファがLRUリストのMRU側へ移動されるにつれて、使用済バッファはLRUリストのLRU側に向かって古くなります。
Oracle Databaseユーザー・プロセスでデータの特定の部分が初めて必要になると、データベース・バッファ・キャッシュ内のデータを検索します。キャッシュ内にデータが見つかった場合（キャッシュ・ヒット）、プロセスはデータをメモリーから直接読み取ることができます。キャッシュ内にデータが見つからなかった場合（キャッシュ・ミス）、プロセスはデータにアクセスする前に、ディスク上のデータファイルからキャッシュ内のバッファにデータ・ブロックをコピーする必要があります。キャッシュ・ヒットによるデータのアクセスは、キャッシュ・ミスによるデータのアクセスよりも高速です。
プロセスはキャッシュ内にデータ・ブロックを読み取る前に、使用可能バッファを見つける必要があります。プロセスは、LRUリストのLRU側から検索を開始します。使用可能バッファが見つかるか、検索したバッファ数が制限しきい値に達するまで、プロセスは検索を続けます。
ユーザー・プロセスがLRUリストの検索時に使用済バッファを見つけた場合、プロセスはそのバッファを書込みリストに移動してから検索を続けます。使用可能バッファが見つかると、プロセスはディスクからバッファにデータ・ブロックを読み取って、バッファをLRUリストのMRU側に移動します。
使用可能バッファが見つからず、検索したバッファ数が制限しきい値に達すると、Oracle Databaseユーザー・プロセスはLRUリストの検索を停止し、使用済バッファの一部をディスクに書き込むように、DBW0バックグラウンド・プロセスに信号を送ります。
ユーザー・プロセスは、全表スキャンを実行するときに、表のブロックをバッファに読み取ってLRUリストの（MRU側ではなく）LRU側に入れます。通常、全表スキャンされた表は一時的に必要なため、使用頻度の高いブロックをキャッシュ内に残しておくために、全表スキャンされた表のブロックをすぐにキャッシュから移動する必要があるためです。
表スキャンに関連するブロックのこのデフォルトの動作は、表ごとに制御できます。全表スキャン時に表のブロックをリストのMRU側に格納するように指定するには、表やクラスタの作成時または変更時にCACHE句を使用します。それ以後の表へのアクセスでI/Oを防止するために、小さな参照表や大きな静的履歴表にこの動作を指定することがあります。
REDOログ・バッファとは、SGA内の循環バッファであり、データベースに加えられた変更についての情報を保持します。この情報は、REDOエントリに格納されます。REDOエントリには、INSERT、UPDATE、DELETE、CREATE、ALTERまたはDROPの各操作によってデータベースに加えられた変更の再構築または再実行に必要な情報が含まれます。REDOエントリは、必要に応じてデータベースのリカバリ時に使用されます。
REDOエントリは、Oracle Databaseプロセスによってユーザーのメモリー領域からSGA内のREDOログ・バッファにコピーされます。REDOエントリは、バッファ内で連続した領域を占めます。バックグラウンド・プロセスLGWRは、REDOログ・バッファをディスク上のアクティブなREDOログ・ファイル（またはREDOログ・ファイルのグループ）に書き込みます。
|
関連項目
|
SGAの共有プール部分には、ライブラリ・キャッシュ、ディクショナリ・キャッシュ、結果キャッシュ、パラレル実行メッセージ用バッファおよび制御構造が含まれます。
この項の内容は、次のとおりです。
ライブラリ・キャッシュには、共有SQL領域、プライベートSQL領域（共有サーバー構成の場合）、PL/SQLプロシージャおよびパッケージの他、ロックやライブラリ・キャッシュ・ハンドルなどの制御構造が含まれます。
共有SQL領域にはすべてのユーザーがアクセス可能であるため、ライブラリ・キャッシュはSGA内の共有プールに含まれます。
Oracle Databaseでは、実行される各SQL文が、共有SQL領域とプライベートSQL領域によって表されます。Oracle Databaseは、2人のユーザーが同じSQL文を実行する場合にそれを認識し、これらのユーザーのために共有SQL領域を再利用します。ただし、各ユーザーは、その文のプライベートSQL領域のコピーを各自で持つ必要があります。
共有SQL領域には、特定のSQL文の解析ツリーと実行計画が含まれます。Oracle Databaseでは、多数のユーザーが同じアプリケーションを実行するときには特に、複数回実行されるSQL文に1つの共有SQL領域を使用することによってメモリーを節約します。
Oracle Databaseでは、新しいSQL文が解析された時点でメモリーが共有プールから割り当てられ、共有SQL領域に格納されます。このメモリーのサイズは、文の複雑度に応じて決められます。共有プール全体が割当て済の場合、Oracle Databaseでは、新しい文の共有SQL領域のための空き領域が十分になるまで、修正したLRUアルゴリズムを使用してその共有プールからエントリの割当てを解除できます。Oracle Databaseが共有SQL領域の割当て解除する場合、対応付けられていたSQL文は次の実行時に再解析され、別の共有SQL領域に再び割り当てられます。
Oracle Databaseでは、PL/SQLプログラム・ユニット（プロシージャ、ファンクション、パッケージ、無名ブロックおよびデータベース・トリガー）が、個々のSQL文と同じ方法で処理されます。また、プログラム・ユニットを解析およびコンパイル済の形で保持するために、Oracle Databaseにより共有領域が割り当てられます。さらに、ローカル変数、グローバル変数、パッケージ変数（パッケージ・インスタンス化とも呼ばれる）およびSQL実行用のバッファなど、プログラム・ユニットを実行するセッションに固有な値を保持するために、Oracle Databaseによりプライベート領域が割り当てられます。複数のユーザーが同じプログラム・ユニットを実行している場合、単一の共有領域はすべてのユーザーによって使用されますが、各ユーザーは、自分のセッションに固有の値を保持するプライベートSQL領域のコピーを個別にメンテナンスします。
PL/SQLプログラム・ユニット内に含まれる個々のSQL文は、先の項で説明したように処理されます。PL/SQLプログラム・ユニット内の起点には関係なく、これらのSQL文は解析された表現を保持するために共有領域を使用し、その文を実行するセッションごとにプライベートSQL領域を使用します。
一般に、共有プール内のあらゆる項目（共有SQL領域やディクショナリ行）は、修正LRUアルゴリズムに基づいてフラッシュされるまでは、そのまま存在します。新しい項目に領域を割り当てるために共有プール内にさらに領域が必要になると、定期的には使用されていない項目のメモリーが解放されます。修正LRUアルゴリズムを使用すると、多数のセッションが使用している共有プール項目は、その項目を作成したプロセスが終了しても、その項目が使用されているかぎりメモリーに残ります。その結果、マルチユーザーOracle Databaseシステムに関連するSQL文のオーバーヘッドと処理が、最小限に抑えられます。
SQL文が実行のためにOracle Databaseに送られると、Oracle Databaseでは次のメモリー割当ての手順が自動的に実行されます。
Oracle Databaseでは、次のような場合にも共有プールから共有SQL領域がフラッシュされます。
ANALYZE文を使用する場合、分析されたスキーマ・オブジェクトを参照する文を含んでいるすべての共有SQL領域は、共有プールからフラッシュされます。フラッシュされた文を次に実行するときには、その文はスキーマ・オブジェクトの新しい統計を反映するように新しい共有SQL領域で解析されます。
ALTER SYSTEM FLUSH SHARED_POOLは、このフラッシュを実行するのに使用します。
関連項目
ALTER SYSTEM FLUSH SHARED_POOLの使用方法は、『Oracle Database SQL言語リファレンス』を参照してください。
V$SQLおよびV$SQLAREA動的ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
データ・ディクショナリとは、データベース、データベースの構造およびそのユーザーについての参照情報を含むデータベースの表およびビューの集合のことです。Oracle Databaseは、SQL文の解析時にデータ・ディクショナリに頻繁にアクセスします。このアクセスは、Oracle Databaseの操作を続けるためには不可欠です。
データ・ディクショナリはOracle Databaseによって頻繁にアクセスされるので、ディクショナリ・データを保持するために、メモリー内に2箇所の特別な場所が指定されています。一方の領域は、データのブロック全体を保持するバッファのかわりに行としてデータを保持するため、データ・ディクショナリ・キャッシュまたは行キャッシュと呼ばれます。ディクショナリ・データを保持するメモリー内の他方の領域は、ライブラリ・キャッシュです。これら2つのキャッシュは、データ・ディクショナリ情報にアクセスするすべてのOracle Databaseユーザー・プロセスによって共有されます。
結果キャッシュは、同一のインフラストラクチャを共有しているSQL問合せ結果キャッシュとPL/SQLファンクション結果キャッシュで構成されています。
DBMS_RESULT_CACHEパッケージには、たとえばキャッシュされた結果をすべてフラッシュしたり、結果のキャッシングの有効化/無効化をシステム全体で切り替えたりするための管理サブプログラムが用意されています。動的パフォーマンス・ビューV$RESULT_CACHE_*を使用すると、開発者やDBAは、特定のSQL問合せまたはPL/SQLファンクションにキャッシュ・ヒットしたかなどを判断できます。
クライアント結果キャッシュでは、キャッシングがクライアント側で行われるという点を除けば、結果キャッシュと同じように結果のキャッシュが行われます。
問合せの結果および問合せ断片を、SQL問合せ結果キャッシュのメモリーにキャッシュできます。その後、データベースはキャッシュされた結果を使用して、これらの後続の問合せおよび問合せ断片の実行に対応します。問合せを再実行するよりSQL問合せ結果キャッシュから結果を取得する方が速いため、頻繁に実行される問合せパフォーマンスは、結果がキャッシュされている場合には大幅に向上します。ユーザーは、結果キャッシュ・ヒントを使用して問合せまたは問合せ断片に注釈を付け、結果をSQL問合せ結果キャッシュに保存することを指定できます。
RESULT_CACHE_MODE初期化パラメータの設定内容により、SQL問合せ結果キャッシュをすべての問合せに使用するか（可能な場合）、注釈付きの問合せにのみ使用するかを制御できます。
データまたはキャッシュされた結果の構成に使用されているデータベース・オブジェクトのメタデータがトランザクションで変更されると、キャッシュされた結果はデータベースにより自動的に無効化されます。
PL/SQLファンクションは、1つ以上のパラメータ化問合せを発行し、それを入力とした計算の結果を返すのに使用されることがあります。これらの問合せによりアクセスするデータ（ショッピング・アプリケーションの商品カタログなど）の中には、変更される頻度がファンクションをコールする頻度に比べてはるかに低いものもあります。PL/SQLファンクションのソース・テキストには、その結果をキャッシュするよう要求する構文や、正確性を確保するため、表のリストに対してDMLが実行された場合にはキャッシュをパージすることを要求する構文を含めることができます。また、ファンクションの起動に使用された実引数の組が、キャッシュに対する参照キーになります。結果がキャッシュされたファンクションを起動し、それがキャッシュ・ヒットした場合は、そのファンクション本体は実行されず、かわりにキャッシュに置かれた値が即座に返されます。
データベース管理者は、次の目的で大量のメモリーを割り当てるために、ラージ・プールと呼ばれるオプションのメモリー領域を構成できます。
ラージ・プールからセッション・メモリーを共有サーバー、Oracle XAまたはパラレル問合せバッファ用に割り当てることにより、Oracle Databaseでは共有プールと主に共有SQLのキャッシュに使用して、共有SQLキャッシュの縮小によるパフォーマンスのオーバーヘッドを回避できます。
さらに、Oracle Databaseのバックアップおよびリストア操作用のメモリー、I/Oサーバー・プロセス用のメモリーおよびパラレル・バッファ用のメモリーは、数百KBのバッファ内で割り当てられます。ラージ・プールのほうが、共有プールよりも適切に、これらの大量のメモリー要求を満たすことができます。
ラージ・プールには、LRUリストはありません。これに対して、共有プール内で確保されている領域では、その共有プールから割り当てられる他のメモリーと同じLRUリストが使用されます。
|
関連項目
|
Javaプールのメモリーは、サーバー・メモリー内でJVMに含まれるセッション固有のJavaコードとデータすべてに使用されます。Javaプールのメモリーの使用方法は、Oracle Databaseの実行モードにより異なります。
Java Pool Advisor統計は、Javaに使用されるライブラリ・キャッシュ・メモリーに関する情報を提供し、Javaプールのサイズの変化が解析率に及ぼす影響を予測します。Java Pool Advisorは、statistics_levelをTYPICAL以上に設定すると内部的にオンに設定されます。これらの統計は、アドバイザをオフにするとリセットされます。
ストリーム・プールは、Oracle Streamsによって排他的に使用されます。ストリーム・プールには、バッファ・キュー・メッセージが保存され、Oracle Streamsの取得プロセスおよび適用プロセス用のメモリーが用意されています。
明示的に構成しないかぎり、ストリーム・プールのサイズはゼロから開始されます。プール・サイズは、Oracle Streamsの使用時に必要に応じて動的に増加します。
Oracle Databaseにより、各サーバー・プロセスにプログラム・グローバル領域（PGA）が割り当てられます。PGAはSQL文の処理や、ログオンおよびその他のセッション情報の保持に使用されます。メモリー管理の目的では、すべてのPGAの集合はインスタンスPGAと呼ばれます。初期化パラメータを使用してインスタンスPGAのサイズを設定すると、データベースにより個々のPGAに必要に応じてメモリーが分配されます。
この項の内容は、次のとおりです。
PGAメモリーの内容は、インスタンスが共有サーバー・オプションを起動しているかどうかにより変わります。一般的に、PGAメモリーは次の領域に分割されます。
セッション・メモリーとは、セッションの変数（ログイン情報）およびセッションに関係する他の情報を保持するために割り当てられたメモリーです。共有サーバーでは、セッション・メモリーが共有されます（プライベートではありません）。
プライベートSQL領域には、バインド変数値、問合せ実行状況の情報、および問合せ実行作業領域などのデータが格納されます。SQL文を発行するそれぞれのセッションには、プライベートSQL領域があります。同一のSQL文を発行するそれぞれのユーザーは、1つの共有SQL領域を使用する専用のプライベートSQL領域を持っています。これにより、プライベートSQL領域の多くは、同一の共有SQL領域に対応付けることができます。
プライベートSQL領域の位置は、セッションのために確立される接続のタイプによって異なります。セッションが専用サーバーを介して接続されている場合、プライベートSQL領域はサーバー・プロセスのPGA内にあります。ただし、セッションが共有サーバーを介して接続されている場合、プライベートSQL領域の一部はSGA内に保持されます。
この項の内容は、次のとおりです。
Oracle Databaseプリコンパイラ・プログラムやOCIプログラムのアプリケーション開発者は、カーソル、つまり特定のプライベートSQL領域へのハンドルを明示的にオープンし、それらのカーソルをプログラムの実行中に名前付きリソースとして使用できます。Oracle Databaseが一部のSQL文のために暗黙的に発行する再帰カーソルにも共有SQL領域が使用されます。
プライベートSQL領域は、ユーザー・プロセスが管理します。ユーザー・プロセスが割り当てることのできるプライベートSQL領域の数は初期化パラメータOPEN_CURSORSによって制限されますが、プライベートSQL領域の割当ておよび割当て解除は、使用するアプリケーション・ツールに大きく依存します。このパラメータのデフォルト値は50です。
プライベートSQL領域は、対応するカーソルがクローズされるか、文ハンドルが解放されるまで存在します。Oracle Databaseでは、文の実行が完了するとランタイム領域は解放されますが、持続領域は待機状態が維持されます。持続領域を解放し、アプリケーションのユーザーが必要とするメモリー容量を最小限に抑えるには、オープンされているカーソルのうち再利用しないものを、すべてアプリケーション開発者側でクローズします。
カーソルのプライベートSQL領域は、存続期間が異なる次の2つの領域に分割されます。
たとえば、全表スキャンの場合、この領域にはスキャンの進行情報が格納されます。
これらの領域は、ソートやハッシュ結合など、メモリー集中型の操作に必要な場合に割り当てられます。詳細は、この章で後から説明します。
DMLでは、文の実行が終了するとランタイム領域が解放されます。問合せの場合は、すべての行がフェッチされた後、または問合せが取り消された後に解放されます。
SQL作業領域は、次のようなメモリー集中型の操作をサポートするために割り当てられます。
たとえば、ソート演算子は作業領域（ソート領域とも呼ばれる）を使用して、行の集合のメモリー内ソートを実行します。同様に、ハッシュ結合演算子も作業領域（ハッシュ領域とも呼ばれます）使用して、左入力からハッシュ表を構築します。これら2つの演算子で処理するデータが作業領域に収まらない場合は、入力データを小さく分割します。これにより、メモリー内でデータの一部を処理できます。残りのデータは、処理待ちとして一時ディスク記憶域に収められます。ビットマップ演算子では、対応する作業領域が非常に小さい場合でもディスクに収まらないことはありませんが、ビットマップ演算の複雑度は使用する作業領域のサイズに反比例します。このため、これらの演算子は、作業領域が大きくなればより高速に実行できます。
作業領域のサイズは、制御およびチューニング可能です。自動PGAメモリー管理が有効になっている場合、作業領域サイズはデータベースにより自動的にチューニングされます。詳細は、「メモリー管理方法の概要」を参照してください。
通常、作業領域を増やすとメモリーの使用は増えるものの、演算子の種類によってはパフォーマンスが著しく改善されます。オプションの使用により、入力データや関連のSQL演算子が割り当てた補助メモリー構造に応じた作業領域のサイズを十分確保できます。このオプションを使用しない場合、一部の入力データが一時ディスク記憶域に収容できなくなるため、応答時間が長くなります。作業領域のサイズが入力データ・サイズに比べ、きわめて小さい場合は、データを分割して複数に分けて渡すことが必要となります。このため、演算子の応答時間が大幅に増加します。
システムが使用するアーキテクチャが専用サーバーなのか、共有サーバーなのかにより、PGAメモリーの割当て方法が変わることがあります。表8-1にこれらの相違点を示しています。
| メモリー領域 | 専用サーバー | 共有サーバー |
|---|---|---|
|
セッション・メモリーの性質 |
プライベート |
共有 |
|
持続領域の位置 |
PGA |
SGA |
|
|
PGA |
PGA |
|
DML/DDL文のランタイム領域の位置 |
PGA |
PGA |
メモリー管理では、Oracleデータベースのインスタンス・メモリー構造に対する最適なサイズが、データベースでの需要に応じて維持されます。管理が必要なメモリーは、システム・グローバル領域（SGA）メモリーおよびインスタンス・プログラム・グローバル領域（インスタンスPGA）メモリーです。インスタンスPGAメモリーとは、すべての個別PGAに対するメモリー割当ての集合のことです。
Oracle Databaseでは、様々なメモリー管理方法がサポートされており、どの方法を使用するかは初期化パラメータの設定により選択できます。自動メモリー管理方法を有効化することをお薦めします。
Oracle Database 11gから、Oracle DatabaseでSGAメモリーおよびインスタンスPGAメモリーを完全に自動的に管理できるようになりました。ユーザーが指定するのはインスタンスで使用される合計メモリー・サイズのみで、Oracle Databaseにより、処理要求を満たすために必要に応じてSGAとインスタンスPGAの間でメモリーが動的に交換されます。この機能は、自動メモリー管理と呼ばれます。このメモリー管理方法を使用すると、データベースでは、個々のSGAコンポーネントのサイズおよび個々のPGAのサイズが動的にチューニングされます。
SGAのサイズをより直接的に制御する場合には、自動メモリー管理を無効化し、自動共有メモリー管理を有効化します。自動共有メモリー管理では、SGAに対するターゲット・サイズおよび最大サイズをユーザーが設定します。データベースは、指定したターゲットに対してSGAの合計サイズをチューニングし、SGAコンポーネントすべてのサイズを動的にチューニングします。
個々のSGAコンポーネントのサイズを完全に制御するには、自動メモリー管理および自動共有メモリー管理をともに無効化します。これによって、手動共有メモリー管理が有効化されます。このモードでは、ユーザーが個々のSGAコンポーネントのサイズを設定し、それによりSGA全体のサイズが決定します。またユーザーは処理ごとに、個々のSGAコンポーネントのチューニングを手動で行います。
自動メモリー管理を無効化した上で、自動共有メモリー管理または手動共有メモリー管理を有効化すると、自動PGAメモリー管理も暗黙的に有効化されます。自動PGAメモリー管理では、PGAに対するターゲット・サイズをユーザーが設定します。データベースは、ターゲットに対してインスタンスPGAのサイズをチューニングし、個々のPGAのサイズを動的にチューニングします。自動PGAメモリー管理は、インスタンスPGAに対するデフォルトの管理方法であるため、ターゲット・サイズを明示的に設定しないかぎり、適切なデフォルト値の計算と構成がデータベースによって自動的に行われます。
Oracle Databaseの以前のリリースでは、DBAが作業領域の最大サイズをSQL演算子（ソートやハッシュ結合など）のタイプごとに手動で指定する必要がありました。しかし、ワークロードは常に変化するため、この作業は非常に困難であることがわかりました。Oracle Databaseの現行リリースではこの手動PGAメモリー管理もサポートされていますが、自動PGAメモリー管理を有効化することをお薦めします。
表8-2で、各メモリー管理方法を説明します。自動メモリー管理を有効化しない場合は、SGAおよびPGAのそれぞれに対して個別にメモリー管理方法を構成する必要があります。
Database Configuration Assistant（DBCA）を使用してデータベースを作成し、基本インストール・オプションを選択した場合、デフォルトでは自動メモリー管理が有効化されます。拡張インストールを選択した場合、Database Configuration Assistant（DBCA）では、次の3つのメモリー管理構成からいずれかを選択できます。
CREATE DATABASE SQL文を使用してデータベースを作成する際、必要なメモリー初期化パラメータを指定することによりメモリー管理モードを選択しない場合は、デフォルトで手動共有メモリー管理および自動PGAメモリー管理が構成されます。
ソフトウェア・コード領域とは、実行中または実行される可能性があるコードを格納するためのメモリー部分です。Oracle Databaseのコードはソフトウェア領域に格納されます。この場所は通常ユーザー・プログラムの格納場所とは異なり、排他的であるかまたは保護されています。
ソフトウェア領域のサイズは通常固定されており、ソフトウェアの更新時か再インストール時にかぎり変化します。これらの領域に必要なサイズは、オペレーティング・システムによって異なります。
ソフトウェア領域は読取り専用であり、共有または非共有でインストールされます。Oracle Databaseコードは、メモリー内に複数のコピーを格納することなくすべてのユーザーがアクセスできるよう、可能なかぎり共有されます。これにより、実際の主メモリーが節約され、全体のパフォーマンスが改善されます。
ユーザー・プログラムは共有でも非共有でもかまいません。Oracle FormsやSQL*PlusなどのOracleのツール製品およびユーティリティによっては、共有でインストールできるものもありますが、共有にできないものもあります。Oracle Databaseの複数のインスタンスが同じコンピュータ上で実行されている場合、それらのインスタンスは異なるデータベースにおいても同じOracle Databaseコード領域を使用できます。
|
 Copyright © 1993, 2008 Oracle Corporation. All Rights Reserved. |
|