自己管理型データベース: 自動SGAメモリー管理

Transcription

1 自己管理型データベース : 自動 SGA メモリー管理 オラクル ホワイト ペーパー 2004 年 8 月

2 自己管理型データベース : 自動 SGA メモリー管理 概要... 3 現在の課題... 3 自動共有メモリー管理の導入... 4 SGA_TARGET パラメータ... 4 SGA コンポーネントの自動管理... 4 手動でサイズを指定する SGA コンポーネント... 6 利点... 7 柔軟性が高く 適応性のあるメモリー使用... 7 パフォーマンスの向上... 8 操作性... 8 自動共有メモリー管理の有効化... 8 SGA パラメータの動的変更 SGA_TARGET の動的変更 自動的に管理されるコンポーネントのパラメータの動的変更 手動でサイズを変更するコンポーネントのパラメータ変更 自動チューニング値の永続性 結論 自己管理型データベース : 自動 SGA メモリー管理 2

3 自己管理型データベース : 自動 SGA メモリー管理 概要 Oracle Database 10g の自己管理に関する主要な機能拡張の 1 つが 自動共有 (SGA) メモリー管理です この機能は Oracle Database 10g インスタンスが使用する共有メモリーの管理を自動化できるため 管理者は共有メモリー コンポーネントの手動による構成が必要ありません 自動共有メモリー管理機能は 利用可能なメモリーの使用をさらに効率化して追加ハードウェア メモリー リソースの取得費用を削減し さらに動的で 柔軟性が高く 適応性のあるメモリー管理スキームの導入により Oracle データベース管理を著しく簡素化します このドキュメントでは 自動共有メモリー管理機能とその利点について説明します 現在の課題 Oracle の共有グローバル領域 (SGA) は 複数のメモリー コンポーネントで構成されています コンポーネントとは 特定クラスのメモリー割当て要求に応じるメモリー プールです メモリー コンポーネントには 共有プール (SQL および PL/SQL 実行へのメモリー割当てに使用 ) Java プール (Java オブジェクトおよびその他の Java 実行メモリーに使用 ) バッファ キャッシュ( ディスク ブロックのキャッシュに使用 ) などがあります 過去のリリースでは SGA コンポーネントのサイズ指定には Oracle 管理者が SHARED_POOL_SIZE DB_CACHE_SIZE LARGE_POOL_SIZE および JAVA_POOL_SIZE など多数のパラメータを手動による設定が必要でした 個々の SGA コンポーネントのサイズを手動で調整することは 困難な作業です これらのコンポーネントのサイズをワークロードに合せた最適化が簡単ではないためです Oracle9i では アドバイザ メカニズムを導入し DBA によるバッファ キャッシュおよび共有プールの最適なサイズ決定の支援で この問題が大幅に改善されました ただし アドバイザによる推奨事項の実装は 管理者が行う必要がありました 日中のオンライン ユーザーと夜間のバッチ ジョブなど 時間によってワークロードが変化する状況では さらに困難です 最も高い負荷に合せたサイズ指定ではメモリーが浪費され サイズを小さくするとメモリー不足エラー (ORA-4031) が発生します たとえば 毎夜実行される Recovery Manager のバックアップ ジョブに対応する システムを大きなラージ プールで構成すると 本来ならバッファ キャッシュや共有プールで OLTP アクティビティにより有効に使用可能なメモリーの多くの部分が 日中は未使用状態のままになります 同時に 失敗によるコストはビジネスの観点から膨大になり得るため 管理者は適切なメモリー構成が必要になります 自己管理型データベース : 自動 SGA メモリー管理 3

4 自動共有メモリー管理の導入 これらの課題を解消するため Oracle Database 10g では 自動共有メモリー管理を導入しました Oracle Database 10g で DBA は新しいパラメータ SGA_TARGET を使用して インスタンスで使用可能な SGA メモリーの合計量を指定するだけです 後は 必要に応じて利用可能なメモリーが各コンポーネントに自動的に配分されます 自動共有メモリー管理機能は データベースの高度なアルゴリズムに基づいてワークロードの需要に応じて継続的にメモリー配分を監視し 必要に応じて周期的に変更します SGA_TARGET パラメータ SGA_TARGET パラメータは SGA の合計サイズを示し メモリーを次の機能に割り当てます Oracle インスタンスに必要な固定 SGA およびその他の内部割当て ログ バッファ 共有プール Java プール バッファ キャッシュ 保持 / リサイクル バッファ キャッシュ ( 指定されている場合 ) 非標準ブロック サイズ バッファ キャッシュ ( 指定されている場合 ) ストリーム プール (Oracle Database 10g の新機能 ) 重要なことは SGA のすべてのメモリーが SGA_TARGET に含まれていることです この点が 構成済の SGA メモリー パラメータの合計に内部割当てと固定 SGA のメモリーが追加されていた旧リリースとは異なります したがって SGA_TARGET の使用で Oracle データベースによって割り当てる共有メモリー領域のサイズを正確に制御できます SGA コンポーネントの自動管理 SGA_TARGET を設定すると 一般的に構成されているコンポーネントのサイズが自動的に指定されます これらのアプリケーションの例を次に示します 1. 共有プール (SQL および PL/SQL 実行 ) 2. Java プール (Java 実行状態 ) 3. ラージ プール (Recovery Manager バックアップ バッファなど 大量の割当て ) 4. バッファ キャッシュこれらのコンポーネントのサイズは明示的な指定が必要ありません これらのコンポーネントのパラメータはデフォルトでゼロに設定されています コンポーネントは メモリーが必要になると 別のコンポーネントからのメモリー転送を内部の自動チューニング メカニズムを介して要求します この作業は ユーザーの介在なく透過的です 自己管理型データベース : 自動 SGA メモリー管理 4

5 各コンポーネントのパフォーマンスも Oracle インスタンスによって監視されます インスタンスは内部ビューと統計を使用して 自動的にサイズ指定する各コンポーネントへのメモリー配分の最適化方法を決定します このようにして ワークロードの変化に応じてメモリーが再配分され 新しいワークロードのパフォーマンスは常に最適化されます このアルゴリズムは 長期および短期の傾向を考慮して 常に最適な配分が模索されます 次の例では 曲線の屈曲部分よりも低い値に共有プールのサイズが指定されており 共有プールを大きくすれば解析時間が大幅に改善されることを共有プール アドバイザは示しています このシナリオでは 自動チューニング アルゴリズムによりメモリーをバッファ キャッシュから共有プールへ転送することで メモリー配分を最適化できます 図 1: 共有プール アドバイザ 管理者は 各コンポーネントの最小値を指定することで 自動チューニングされるコンポーネントのサイズを制御できます この作業は コンポーネントの適切な動作には一定量のメモリーが必要であることを管理者が把握している場合に便利です コンポーネントの最小値を指定するには 各コンポーネントのパラメータを設定します 次に構成例を示します SGA_TARGET = 256MB SHARED_POOL_SIZE = 32MB 自己管理型データベース : 自動 SGA メモリー管理 5

6 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 メモリー構成ページで確認できます 図 2: OEM の表示 : 自動チューニングされた SGA コンポーネントの現在のサイズ 手動でサイズを指定する SGA コンポーネント SGA コンポーネントには サイズが自動調整されないものもあります このようなコンポーネントのサイズは アプリケーションの必要性に応じて 管理者が明示的に指定する必要があります 次のコンポーネントでは サイズが自動調整されません 自己管理型データベース : 自動 SGA メモリー管理 6

7 保持 / リサイクル バッファ キャッシュ (DB_KEEP_CACHE_SIZE と DB_RECYCLE_CACHE_SIZE によって制御 ) 非標準ブロック サイズの追加バッファ キャッシュ (DB_<N>K_CACHE_SIZE, N={2,4,8,16,32} によって制御 ) ストリーム プール ( 新規パラメータ STREAMS_POOL_SIZE によって制御 ) これらのコンポーネントのサイズは 管理者が指定するパラメータ値によって決まります これらの値は Oracle Enterprise Manager または ALTER SYSTEM コマンドを介したコマンドラインで随時変更できます コンポーネントのサイズを手動で指定すると その分自動調整で使用可能なメモリー量が減少します 次の構成を例に説明します SGA_TARGET = 256MB DB_8K_CACHE_SIZE = 32MB STREAMS_POOL_SIZE = 24MB 自動的にサイズが指定されるコンポーネントの配分にこのインスタンスに残されたメモリーは 200MB( ) です 利点 柔軟性が高く 適応性のあるメモリー使用 自動 SGA メモリー管理の最大の利点は ユーザーの介在なしに SGA コンポーネントのサイズがワークロードの必要性に応じて柔軟に調整されることです このことを 次の例で説明します SGA で利用できるメモリーが 1GB のとき 手動による構成で配分します ( 簡略化のため 他の SGA コンポーネントは無視します ) SHARED_POOL_SIZE=128MB DB_CACHE_SIZE=896MB この場合 アプリケーションが 128MB を超えるメモリーを共有プールから割り当てると 利用できる共有プールがないことを示す ORA-4031 が発生します この状況が発生すると バッファ キャッシュに空きメモリーがあっても共有プールでは利用できないことに注意してください ユーザーは 手動でバッファ キャッシュを小さくし 共有プールを大きくしてこの問題に対処します 一方 自動管理では DBA の作業は次のパラメータの設定のみです SGA_TARGET = 1GM これにより ORA-4031 のエラー状況を回避するために共有プールのメモリーを増やす必要がある場合 アプリケーションはバッファ キャッシュからメモリーを取得することで簡単にそれを実現できます 自己管理型データベース : 自動 SGA メモリー管理 7

8 パフォーマンスの向上自動共有メモリー管理機能を使用すると 使用可能なメモリーの最適化だけでなく ワークロード パフォーマンスも向上します 手動の構成では 共有プールのサイズ指定が適正でないため共有プールが不足し コンパイル済の 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 自動共有メモリー管理は 動的な有効にもなります Oracle Enterprise Manager の使用には 自動共有メモリー管理 画面で 有効化 ボタンをクリックすることで SGA チューニングを有効化できます 自己管理型データベース : 自動 SGA メモリー管理 8

9 図 3: Oracle Enterprise Manager を使用した自動共有メモリー管理の有効化 OEM を使用して自動共有メモリー管理機能を有効にすると SGA_TARGET の適正値が前述の式に従って自動的に計算されます さらに 自動管理の利点を最大化するため 個別コンポーネントのサイズを指定するパラメータの設定がすべて解除されます コマンドライン インタフェースの場合には 次の手順で自動共有メモリー管理を有効化します SGA_TARGET を現在の SGA サイズに合せて動的に設定します SGA の現在のサイズは 次の問合せによって固定ビュー V$SGA から取得できます select sum(value) from v$sga; 次に 自動共有メモリー チューニング アルゴリズムに従い必要に応じてサイズを変更するため 自動チューニングされるコンポーネントのサイズをゼロに設定します たとえば前述の問合せで (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 メモリー管理 9

10 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 Operating System や Microsoft 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 メモリー管理 10

11 自動的に管理されるコンポーネントのパラメータの動的変更 パラメータ 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 メモリー管理 11

12 次に例を示します SGA_TARGET = 512MB DB_8K_CACHE_SIZE=128MB この場合 DB_8K_CACHE_SIZE を 144MB( または 16MB の倍数 ) に増やすと 自動的にサイズが指定されるコンポーネントから 16MB が削除されます 同様に DB_8K_CACHE_SIZE を 112MB( または 16MB の倍数 ) に減らすと 自動的にサイズが指定されるコンポーネントに 16MB が追加されます 自動チューニング値の永続性 自動チューニングしたコンポーネントのサイズを停止後も保持するには サーバー パラメータ ファイル (SPFILE) を使用します これにより システムは特性ワークロードを毎回始めから調べる必要がなくなり 最後に停止した場所から再開します このため 自動共有メモリー管理機能と SPFILE との併用を強くお薦めします 結論 メモリーは貴重なシステム リソースです 管理者は現在 メモリー使用の最適化に多くの時間を割いています 自動共有メモリー管理を使用すると 時間がかかる困難な作業を回避できます 柔軟性が高く適応性のあるこのソリューションは 既存のリソースの利用を最適化し それにより企業は設備投資を抑制できます 自動共有メモリー管理は Oracle Database 10g に搭載された他の機能と同様に 管理者の戦略的な役割をより有効にして 企業の収益増加を実現します 自己管理型データベース : 自動 SGA メモリー管理 12

13 自己管理型データベース : 自動 SGA メモリー管理 2004 年 8 月著書 : Tirthankar Lahiri Arvind Nithrkashyap 寄稿者 : Sushil Kumar Brian Hirano Kant Patel Poojan Kumar Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファックス : オラクル社は インターネット上での活動を強化するソフトウェアを提供します Oracle はオラクル社の登録商標です このガイドで使用されているさまざまな製品名およびサービス名には オラクル社の商標が含まれています その他のすべての製品名およびサービス名は 各社の商標です Copyright 2004 Oracle Corporation All rights reserved.