自
自
己
己
管
管
理
理
デ
デ
ー
ー
タ
タ
ベ
ベ
ー
ー
ス
ス
:
:
自
自
動
動
S
S
G
G
A
A
メ
メ
モ
モ
リ
リ
ー
ー
管
管
理
理
Tirthankar Lahiri, Arvind Nithrakasyhap, Brian Hirano, Kant Patel, Poojan Kumar, Sushil Kumar Oracle Corporation
概要
Oracle Database 10g の自己管理に関する主要な機能拡張の 1 つが、自動共有（SGA）メモリー管理です。この機能では Oracle データベース・インスタンスが使用する共有メモリーの管理を自動化できるので、管理者は共有メモリー･コンポー ネントを手動で構成する必要がありません。自動共有メモリー管理機能では、利用可能なメモリーの使用をさらに効率化 することで追加ハードウェア･メモリー･リソースの取得費用を削減する他、さらに動的で柔軟性の高い、適応性のあるメ モリー管理スキームの導入で、Oracle データベース管理を大幅に簡素化します。 このペーパーでは、自動共有メモリー管理機能とその利点について説明します。
現在の課題
Oracle の共有グローバル領域（SGA）は、複数のメモリー･コンポーネントで構成されています。コンポーネントとは、 特定クラスのメモリー割当て要求に使用されるメモリー･プールです。メモリー･コンポーネントには、共有プール（SQL と PL/SQL 実行へのメモリー割当てに使用）、Java プール（Java オブジェクトとその他の Java 実行メモリーに使用）、 バッファ･キャッシュ（ディスク･ブロックのキャッシュに使用）などがあります。 過去のリリースでは、SGA コンポーネントのサイズ指定には、shared_pool_size、db_cache_size、java_pool_size および large_pool_size など多数のパラメータを手動で設定する必要がありました。 個々の SGA コンポーネントサイズを手動で調整することはきわめて骨の折れるタスクです。これらのコンポーネントサ イズをワークロードに最適化するのは至難の業です。Oracle9i では、アドバイザ･メカニズムを導入し、DBA によるバッ ファ･キャッシュおよび共有プールの最適なサイズ決定の支援で、この問題が大幅に改善されました。しかし、アドバイ ザによる推奨事項の実装は、やはり管理者が行う必要がありました。日中のオンライン･ユーザーと夜間のバッチ･ジョブ など、時間によってワークロードが変化する状況では、さらに困難をきわめます。最も高い負荷に合わせてサイズを指定 すればメモリーが浪費され、かといってサイズを小さくすればメモリー不足エラー（ORA-4031）が発生します。たとえ ば、毎夜実行される Recovery Manager のバックアップ･ジョブに合わせてシステムに大きなラージ・プールを構成すると、 日中このメモリーは、バッファ･キャッシュや共有プールで OLTP アクティビティに利用することもできるのに、ほとん どが未使用な状態のままです。同時に、ビジネス観点からの失敗コストは膨大になり得るため、管理者はメモリー構成を 必ず成功させなければなりません。自動共有メモリー管理の導入
これらの困難さの解消に、Oracle Database 10g では、自動共有メモリー管理を導入しました。Oracle 10g では、DBA は新 しいパラメータ SGA_TARGET を使用して、インスタンスで使用可能な SGA メモリーの合計量を指定すればよいだけで す。後は、利用可能なメモリーが必要に応じて各コンポーネントに自動的に配分されます。自動共有メモリー管理機能は、 データベースの高度な経験則に基づくワークロードの需要に応じたメモリー配分を監視および変更します。
SGA_TARGET パラメータ
SGA_TARGET パラメータは、SGA の合計サイズを示し、次のメモリーを含みます。 1. Oracle インスタンスに必要な固定 SGA およびその他の内部割当て 2. ログ･バッファ 3. 共有プール 4. Java プール 5. バッファ・キャッシュ 6. 保持/リサイクル･バッファ･キャッシュ（指定されている場合） 7. 非標準ブロック･サイズ･バッファ･キャッシュ（指定されている場合） 8. ストリーム･プール（Oracle Database 10g の新機能）重要なことは、SGA のすべてのメモリーが SGA_TARGET に含まれていることです。この点が、構成済みの SGA メモリー･ パラメータの合計に内部割当てと固定 SGA のメモリーが追加されていた旧来のリリースとは異なります。したがって、 Oracle によって割り当てられている共有メモリー領域のサイズを SGA_TARGET を使用することで正確に制御できます。
SGA コンポーネントの自動管理
SGA_TARGET を設定すると、一般的に構成されているコンポーネントのサイズが自動的に指定されます。たとえば、次 のようなコンポーネントです。 1. 共有プール（SQL および PL/SQL 実行） 2. Java プール（Java 実行状態） 3. ラージ・プール（Recovery Manager バックアップ･バッファなど、大量の割当て） 4. バッファ・キャッシュ これらのコンポーネントサイズは明示的に指定する必要がなく、またこれらのパラメータはデフォルトでゼロに設定され ています。コンポーネントはメモリーが必要になると、別のコンポーネントからのメモリー転送を内部の自動チューニン グ･メカニズムを介して要求します。この作業は、ユーザーの介在なしに透過的に行われます。 各コンポーネントのパフォーマンスも Oracle インスタンスによって監視されます。インスタンスは内部ビューと統計を 使用して、自動的にサイズが指定される各コンポーネントへのメモリー配分を最適化する方法を決定します。このように、 ワークロードの変化に応じたメモリーが再配分され、新しいワークロードのパフォーマンスは常に最適化されます。この アルゴリズムには終わりがなく、長期および短期の傾向を考慮して、常に最適な配分が模索されます。次の例では、曲線 の屈曲部分よりも低い値に共有プールのサイズが指定されており、共有プールを大きくすれば解析時間が大幅に改善され ることを共有プール･アドバイザは示しています。このシナリオでは、メモリーをバッファ･キャッシュから共有プールへ 転送することで、メモリー配分を最適化できます。図 1a: 共有プール･アドバイザ 管理者は、各コンポーネントの最小値を指定することで、自動チューニングされるコンポーネントのサイズを制御できま す。この作業は、コンポーネントの適切な動作には一定量のメモリーが必要であることを管理者が把握している場合に便 利です。コンポーネントの最小値を指定するには、各コンポーネントのパラメータを設定します。次に構成例を示します。 SGA_TARGET = 256MB • • • • • • • SHARED_POOL_SIZE = 32MB DB_CACHE_SIZE = 100MB この例では、共有プールとデフォルトのバッファ･プールのサイズが指定値（それぞれ 32MB、100MB）を下回ることは ありません。これは、残りの 124MB が 4 つのコンポーネントに配分できることを意味します。したがって、SGA コンポー ネントに実際に配分される値は、次のようになります。 実際の共有プール･サイズ = 64MB 実際のバッファ･キャッシュ･サイズ = 128MB 実際の Java プール･サイズ = 60MB 実際のラージ･プール･サイズ = 4MB
各 SGA コンポーネントの現在のサイズは固定ビューV$SGA_DYNAMIC_COMPONENTS に表示されます。最小値はパラ メータ値（DB_CACHE_SIZE、SHARED_POOL_SIZE など）で指定されています。SGA コンポーネントの現在値は、Enterprise Manager メモリー構成ページで確認できます。 図 1b: 自動チューニングされた現在の SGA コンポーネントサイズを表示する EM
SGA コンポーネントの手動サイズ指定
SGA コンポーネントの中には、サイズが自動調整されないものもあります。このようなコンポーネントのサイズは、ア プリケーションの必要性に応じて、管理者が明示的に指定する必要があります。次のコンポーネントでは、サイズが自動 調整されません。 保持/リサイクル･バッファ･キャッシュ（DB_KEEP_CACHE_SIZE と DB_RECYCLE_CACHE_SIZE により制御） • • 非表示ブロック･サイズの追加バッファ･キャッシュ（DB_<N>K_CACHE_SIZE、N = {2、4、8、16、32}により制ストリーム･プール（新規パラメータ STREAMS_POOL_SIZE により制御） • • • • これらのコンポーネントのサイズは、管理者が指定するパラメータ値によって決まります。これらの値は、Enterprise Manager または ALTER SYSTEM コマンドで随時変更できます。
コンポーネントのサイズを手動で指定すると、その分だけ自動調整で使用可能なメモリー量が減少します。次の構成を例 に考えてみましょう。 SGA_TARGET = 256MB DB_8K_CACHE_SIZE = 32MB STREAMS_POOL_SIZE = 24MB 自動的にサイズが指定されるコンポーネントに配分するためにこのインスタンスに残されたメモリーは、200MB（256 − 32 − 24）です。
利点
高い柔軟性と適応性のメモリー使用
自動共有メモリー管理を使用する最大の利点は、ユーザーの介在なしに、SGA コンポーネントのサイズがワークロード の必要性に応じて柔軟に調整されることです。 次の例で、このことを説明します。SGA で利用できるメモリーが 1GB のとき、手動による構成で次のように配分すると します（簡略化のため、他の SGA コンポーネントは無視します）。 SHARED_POOL_SIZE=128MG DB_CACHE_SIZE=896MB この場合、アプリケーションが 128MB を超えるメモリーを共有プールから割り当てると、利用できる共有プールがない ことを示す ORA-4031 が発生します。この状況が発生したとき、バッファ･キャッシュに空きメモリーがあっても共有プー ルでは利用できないことに注意してください。ユーザーは、手動でバッファ･キャッシュを小さくし、共有プールを大き くすることでこの問題に対処します。 一方、自動管理では、DBA は次のパラメータを設定すればよいだけです。 SGA_TARGET = 1G これにより、ORA-4031 のエラー状況を回避するために共有プールのメモリーを増やす必要が生じた場合は、アプリケー ションはバッファ･キャッシュからメモリーを取得することで簡単に実現できます。パフォーマンスの向上
自動共有メモリー管理機能を使用すると、使用可能なメモリーの最適化だけでなく、ワークロード･パフォーマンスも向 上します。手作業による構成では、共有プールのサイズ指定が適正でないため共有プールが不足し、コンパイル済みの SQL 文が共有プールから頻繁に削除されることがあります。したがって、ハード解析を頻繁に行わなければならず、パ フォーマンスが低下します。一方、自動管理を有効化すると、内部チューニング･アルゴリズムがワークロード･パフォーマンスを監視し、共有プール のサイズを大きくすれば必要な解析数が減ると判断すれば、そのサイズを大きくします。この機能が、自動共有メモリー 管理機能の最も優れた点です。リソースの追加や手動によるチューニング作業を必要としない状態でパフォーマンスが向 上します。
使いやすさ
1 つのパラメータを設定するだけで、管理者の作業が大幅に簡素化します。DBA はインスタンスが利用できる SGA メモ リーの量を指定するだけです。個々のコンポーネントサイズを計算する必要はありません。さらに、システム全体でメモ リー不足が発生しない限り、メモリー不足エラーは決して発生しません。自動共有メモリー管理の有効化
自動共有メモリー管理機能の有効化には、EM を使用するか、パラメータ SGA_TARGET を設定します。 手動による方法からの移行には、SGA パラメータ値を計算し、さらに固定 SGA と内部オーバーヘッドの算入に 16MB ほ どの少量のメモリーを加算することが最良の方法です。同時に、自動的にサイズが指定されるコンポーネント値をパラ メータ･ファイルから削除することもできます。 たとえば、次の構成を移行する場合を考えてみます。 SHARED_POOL_SIZE = 256MB • • • • • DB_CACHE_SIZE = 512MB LARGE_POOL_SIZE = 256MB LOG_BUFFER = 16MB これらのパラメータの代わりに、次のパラメータを指定できます。 SGA_TARGET = 256MB + 512MB + 256MB + 16MB + 16MB（固定 SGA オーバーヘッド）= 1056MB 自動共有メモリー管理は、動的な有効化もできます。Enterprise Manager を使用するには、「自動共有メモリー管理」画 面で「有効化」ボタンをクリックして SGA チューニングの有効化ができます。図 2: Enterprise Manager を使用した自動共有メモリー管理の有効化
EM を使用した自動共有メモリー管理機能を有効化するとき、SGA_TARGET の適正値が前述の式に従って自動的に計算 されます。さらに、自動管理の利点を最大化するため、個別コンポーネントのサイズを指定するパラメータの設定がすべ て解除されます。
コマンドライン･インタフェースを使用するには、次の手順で自動共有メモリー管理を有効化します。
SGA_TARGET を現在の SGA サイズに合わせて動的に設定します。SGA の現在のサイズは、次のクエリによって V$SGA から取得できます。
•
•
select sum(value) from v$sga;
次に、自動共有メモリー･チューニング･アルゴリズムに従って必要に応じたサイズが変更されるように、自動 チューニングされるコンポーネントのサイズをゼロに設定します。
たとえば上記のクエリで 536870912（512MB）という結果が返された場合には、次の手順で自動 SGA を有効化します。 alter system set sga_target=512M;
alter system set db_cache_size = 0; alter system set shared_pool_size = 0; alter system set large_pool_size = 0; alter system set java_pool_size = 0;
SGA パラメータの動的変更
SGA_TARGET の動的変更
SGA_TARGET パラメータは、SGA_MAX_SIZE パラメータで指定された値まで動的に増加します。また、このパラメー タ値は減少することもあります。減少する場合、メモリーを解放するために 1 つ以上の自動チューニング･コンポーネン トが選択されます。SGA_TARGET パラメータの値は、自動チューニングされる 1 つ以上のコンポーネントが最小サイズ に達するまで減少できます。 SGA_TARGET 変更時に、物理メモリーの使用量が変わるかどうかは、OS プラットフォームによって異なります。動的 共有メモリーに対応していない一部の Unix プラットフォームでは、SGA によって使用される物理メモリーが、 SGA_MAX_SIZE の値に等しくなります。このようなプラットフォームでは、SGA_TARGET の値を SGA_MAX_SIZE よ りも低い設定で実行する利点を享受できません。このため SGA_MAX_SIZE の設定はお薦めしません。Solaris や Windows などその他のプラットフォームでは、SGA によって使用される物理メモリーが SGA_TARGET パラメータと等しくなり ます。 SGA_TARGET サイズの変更時に影響を受けるのは、自動チューニング･コンポーネントのみです。手動で構成したコン ポーネントは影響を受けません。 たとえば、次のように構成された環境があるとします。 SGA_MAX_SIZE = 1024MB • • • • • • • SGA_TARGET = 512MB DB_8K_CACHE_SIZE = 128MB この例で、SGA_TARGET の値は 1024MB まで増加するか、バッファ･キャッシュ、共有プール、ラージ･プールまたは Java プールのうち 1 つ以上がその最小サイズに達するまで減少できます（正確な最小値は、システムの CPU の数など環境要 因によって異なります）。しかし、DB_8K_CACHE_SIZE の値は常に 128MB に固定されています。 また、SGA_TARGET が減少する際、自動チューニング･コンポーネントのサイズ指定で最小サイズが制限されている場 合には、それらのコンポーネントはその最小値を下回ることはありません。このことから、次のようなパラメータの組み 合わせを考えてみます。 SGA_MAX_SIZE = 1024MB SGA_TARGET = 512MB DB_CACHE_SIZE = 96MB DB_8K_CACHE_SIZE = 128MBこの例では、DB_8K_CACHE_SIZE が 128MB に永続的に固定されているだけでなく、第一バッファ･キャッシュも 96MB を下回ることはありません。このことによっても SGA_TARGET の値の減少幅がさらに制限されます。
自動管理コンポーネントのパラメータの動的変更
パラメータ SGA_TARGET が設定されていない場合、SGA_TARGET コンポーネント･パラメータのサイズを変更する規 則は、旧リリースと同じです。この理由は、SGA_TARGET がなければ自動共有メモリー管理機能が無効になるためです。 しかし、前述のとおり、自動管理が有効化されているときは、自動的にサイズが指定されるコンポーネントに対して手動 で指定したサイズ（SHARED_POOL_SIZE など）がそのコンポーネントの下限となります。関連のパラメータ値を変更す ることで、この制限を動的に変更できます。 SGA コンポーネントのサイズに現在のサイズよりも小さい下限が指定された場合には、そのコンポーネントのサイズは すぐには変わりません。将来的に、自動チューニング･アルゴリズムが変更後の最小値に制限されるのみです。 次の例を考えてみます。 SGA_TARGET = 512MB • • • SHARED_POOL_SIZE = 256MB 現在の共有プール･サイズ = 284MB ここでは、SHARED_POOL_SIZE パラメータが動的に 128MB 以下になっても、共有プールの現在のサイズは変わりませ ん。 また、自動的にサイズが指定されるコンポーネントのサイズをゼロに設定すると、そのコンポーネントのサイズにはユー ザー指定の最小値が適用されなくなります。前述のように、SGA_TARGET が設定されているとき、自動的にサイズが指 定されるコンポーネントはデフォルトでこのように動作します。 しかし、コンポーネントの現在のサイズよりも大きい値がこのパラメータに指定された場合には、コンポーネントは変更 されたサイズに応じて大きくなり、最小値の増加が適用されます。前述の例では、SHARED_POOL_SIZE の値を 300MB にした場合、共有プールは 300MB に増加します。このようなサイズ変更は、1 つ以上の自動チューニング･コンポーネン トからメモリーを転送することによって実現されます。 自動的にサイズが変更される 1 つ以上のコンポーネントの最小サイズを手動で制限すると、動的調整に利用できるメモ リーの合計量が少なくなるので、ワークロードの変化に応じたシステムでの調整機能が制限されます。したがって、例外 的なケースを除き､このオプションの使用はお薦めしません。デフォルトの自動管理動作は、システムのパフォーマンス と利用可能なリソースの使用の両方を最大化するよう設計されています。手動でサイズを変更するコンポーネントのパラメータ変更
手動でサイズを変更するパラメータも動的に変更できます。相違点は、パラメータ値によってそのコンポーネントの正確 なサイズが指定されることです。 したがって、手動コンポーネントのサイズを増やすと、自動的にサイズが指定される 1 つ以上のコンポーネントから余計 にメモリーが取り去られます。手動コンポーネントのサイズを減らすと、解放されたメモリーは自動的にサイズが指定さ れるコンポーネントに追加されます。例に例を示します。 SGA_TARGET = 512MB • • DB_8K_CACHE_SIZE = 128MB この場合、DB_8K_CACHE_SIZE を 144MB（または、16MB の倍数）に増やすと、自動的にサイズが指定されるコンポー ネントから 16MB が取り去られます。同様に、DB_8K_CACHE_SIZE を 112MB（または、16MB の倍数）に減らすと、自 動的にサイズが指定されるコンポーネントに 16MB が追加されます。
