日本語PDF

13 データベース・バッファ・キャッシュのチューニング

この章では、データベース・バッファ・キャッシュのチューニング方法を説明します。自動メモリー管理を使用してシステムのデータベース・メモリーを管理している場合は、この章で説明されている、手動でのメモリー・キャッシュのチューニングを行う必要ありません。

この章のトピックは、次のとおりです:

• データベース・バッファ・キャッシュについて

• データベース・バッファ・キャッシュの構成

• 複数バッファ・プールの構成

• REDOログ・バッファの構成

• データベース・キャッシュ・モードの構成

データベース・バッファ・キャッシュについて

様々なタイプの操作について、Oracle Databaseではバッファ・キャッシュを使用してディスクから読み取られたデータ・ブロックを格納します。ソートやパラレル読取りなどの特定の操作の場合には、Oracle Databaseではバッファ・キャッシュはバイパスされます。

データベース・バッファ・キャッシュを効果的に使用するには、不要なリソース使用を回避するようにアプリケーションのSQL文をチューニングします。この目的を達成するには、頻繁に実行されるSQL文と、多数のバッファ読取りを実行するSQL文が適切にチューニングされていることを検証します。

パラレル問合せを使用する場合は、直接プログラム・グローバル領域(PGA)に読み込むのではなく、データベース・バッファ・キャッシュを使用するようにデータベースを構成することを検討します。この構成は、システムのメモリー容量が大きい場合に適しています。

関連項目:

• SQL文のチューニングの詳細は、Oracle Database SQLチューニング・ガイドを参照してください

• パラレル実行の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください

データベース・バッファ・キャッシュの構成

新規にデータベース・インスタンスを構成する場合は、バッファ・キャッシュの適切なサイズがわかっていません。通常、データベース管理者はキャッシュ・サイズの最初の見積りを行い、次にインスタンス上で代表的なワークロードを実行し、関連する統計を調べて、キャッシュが過小構成か過大構成かを確認します。

この項では、データベース・バッファ・キャッシュの構成方法を説明します。自動共有メモリー管理を使用して共有グローバル領域(SGA)を構成する場合は、この章で説明されているように、手動でのデータベース・バッファ・キャッシュのチューニングを行う必要ありません。

この項では、次の項目について説明します。

• V$DB_CACHE_ADVICEビューの使用

• バッファ・キャッシュ・ヒット率の計算

• バッファ・キャッシュ・ヒット率の解釈

• データベース・バッファ・キャッシュに割り当てられたメモリーの増加

• データベース・バッファ・キャッシュに割り当てられたメモリーの削減

V$DB_CACHE_ADVICEビューの使用

V$DB_CACHE_ADVICEビューは、潜在的なバッファ・キャッシュ・サイズ範囲のシミュレーションによるミス率を示します。このビューは、潜在的な各キャッシュ・サイズの物理読取り数を予測する情報を提供して、キャッシュのサイズ設定を支援します。このデータには物理読取り係数も含まれています。これは、バッファ・キャッシュが所定の値にサイズ変更された場合、現行の物理読取り回数がその分のみ変化すると予測される係数です。

ただし、物理読取りはファイル・システム・キャッシュからの読取りで完了するため、物理読取りが必ずしもOracle Databaseのディスク読取りを意味するわけではありません。このため、キャッシュ内でのブロックの検出成功とキャッシュのサイズ間の関係は、必ずしも滑らかな分布を示しません。バッファ・プールをサイズ設定するときは、キャッシュ・ヒット率の向上に貢献しない(または、ほとんど貢献しない)追加バッファは使用しないでください。

次の図に、物理I/O率とバッファ・キャッシュ・サイズの関係を示します。

図13-1 物理I/O率とバッファ・キャッシュ・サイズ

「図13-1 物理I/O率とバッファ・キャッシュ・サイズ」の説明

前述の図に示されている例を調べると、次のことがわかります。

• バッファの数が増加すると、物理I/O率が減少します。

• ポイントAとBおよびポイントBとCとの間の物理I/Oの減少は、グラフの点線で示されるように滑らかではありません。

• ポイントAからポイントBへバッファを増やす場合の利点は、ポイントBからポイントCへバッファを増やす場合よりかなり大きくなります。

• バッファの数が増えるに従い、バッファを増やすメリットが低減します。

このアドバイザ・ビューの使用には、多少のオーバーヘッドが伴います。アドバイザを有効にすると、追加の記録が必要なため、CPUの使用量はわずかに増加します。ブックキーピングに関連するCPUおよびメモリーのオーバーヘッドの両方を削減するために、Oracle Databaseでは、サンプリングを行ってキャッシュ・アドバイザ統計を収集します。サンプリングは、開始時のバッファの数が少ないバッファ・プールでは使用しません。

V$DB_CACHE_ADVICEビューを使用するには:

1. DB_CACHE_ADVICE初期化パラメータの値をONに設定します。

   これにより、アドバイザ・ビューが有効になります。DB_CACHE_ADVICEパラメータは動的であるため、特定のワークロードのアドバイザ・データを収集できるように、アドバイザを動的に有効にしたり、無効にできます。

2. データベース・インスタンスで代表的なワークロードを実行します。

   V$DB_CACHE_ADVICEビューを問い合せる前にワークロードを安定化できるようにします。

3. V$DB_CACHE_ADVICEビューを問い合せます。

次の例に、様々なキャッシュ・サイズについてデフォルト・バッファ・プールに対するI/O要件の予測を戻すこのビューの問合せを示します。

COLUMN size_for_estimate          FORMAT 999,999,999,999 heading 'Cache Size (MB)'
COLUMN buffers_for_estimate       FORMAT 999,999,999 heading 'Buffers'
COLUMN estd_physical_read_factor  FORMAT 999.90 heading 'Estd Phys|Read Factor'
COLUMN estd_physical_reads        FORMAT 999,999,999 heading 'Estd Phys| Reads'

SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor,
       estd_physical_reads
FROM   V$DB_CACHE_ADVICE
WHERE  name = 'DEFAULT'
  AND  block_size = (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size')
  AND  advice_status = 'ON';

この問合せの出力例を次に示します。

                                Estd Phys    Estd Phys
 Cache Size (MB)      Buffers Read Factor        Reads
---------------- ------------ ----------- ------------
              30        3,802       18.70  192,317,943      10% of Current Size 
              60        7,604       12.83  131,949,536
              91       11,406        7.38   75,865,861
             121       15,208        4.97   51,111,658
             152       19,010        3.64   37,460,786
             182       22,812        2.50   25,668,196
             212       26,614        1.74   17,850,847
             243       30,416        1.33   13,720,149
             273       34,218        1.13   11,583,180
             304       38,020        1.00   10,282,475      Current Size 
             334       41,822         .93    9,515,878
             364       45,624         .87    8,909,026
             395       49,426         .83    8,495,039
             424       53,228         .79    8,116,496
             456       57,030         .76    7,824,764
             486       60,832         .74    7,563,180
             517       64,634         .71    7,311,729
             547       68,436         .69    7,104,280
             577       72,238         .67    6,895,122
             608       76,040         .66    6,739,731      200% of Current Size 

この例の出力は、キャッシュが現行サイズの304MBではなく212MBである場合、物理読取りの予測数が1.74倍、つまり74%増加することを示しています。そのため、キャッシュ・サイズを212MBに減少させることは望ましくありません。

ただし、キャッシュ・サイズを334MBに増やすと、読取り数は0.93倍、つまり7%減少することになります。システム上でさらに30MBのメモリーを使用可能で、SGA_MAX_SIZEパラメータの値から増分が可能な場合は、デフォルトのバッファ・キャッシュ・プール・サイズを334MBに増やすことをお薦めします。

バッファ・キャッシュ・ヒット率の計算

バッファ・キャッシュ・ヒット率では、ディスク・アクセスを行わずにバッファ・キャッシュ内で要求されたブロックが検出された頻度を計算します。この率は、V$SYSSTATパフォーマンス・ビューから選択したデータを使用して計算されます。バッファ・キャッシュ・ヒット率を使用して、V$DB_CACHE_ADVICEビューで予測されたように物理I/Oを検証します。

表13-1に、バッファ・キャッシュ・ヒット率の計算に使用したV$SYSSTATビューの統計を示します。

表13-1 バッファ・キャッシュ・ヒット率を計算するための統計

統計	説明
consistent gets from cache	バッファ・キャッシュからのブロックに対して読取り一貫性が要求された回数。
db block gets from cache	バッファ・キャッシュからCURRENTブロックが要求された回数。
physical reads cache	ディスクからバッファ・キャッシュへ読み取られたデータ・ブロックの合計数。

例13-1に、このビューの問合せを示します。

例13-1 V$SYSSTATビューの問合せ

SELECT name, value
FROM V$SYSSTAT
WHERE name IN ('db block gets from cache', 'consistent gets from cache', 
'physical reads cache');

この例では、特定期間の値は選択せず、V$SYSSTATビューから直接選択した値を使用して問合せを単純化しています。アプリケーションの実行中のある期間にわたるこれらの統計の差分を計算し、それらの差分の値を使用してバッファ・キャッシュ・ヒット率を判断することをお薦めします。ある期間の統計を収集する方法の詳細は、「自動パフォーマンス診断」を参照してください。

この問合せの出力の値を使用し、次の計算式でバッファ・キャッシュ・ヒット率を計算します。

1 - (('physical reads cache') / ('consistent gets from cache' + 
'db block gets from cache'))

関連項目:

V$SYSSTATビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

バッファ・キャッシュ・ヒット率の解釈

バッファ・キャッシュ・サイズの増減を決定する前に、バッファ・キャッシュ・ヒット率を調べる必要があります。

キャッシュ・ヒット率が低いことは、バッファ・キャッシュのサイズを大きくすることがパフォーマンスに有益であることを必ずしも意味しません。また、キャッシュ・ヒット率の高いことが、ワークロードに対してバッファ・キャッシュが適切にサイズ設定されていることを示しているとはかぎりません。

バッファ・キャッシュ・ヒット率を解釈する場合は、次の点を考慮する必要があります。

• 1つのパスで処理を実行するか、SQL文を最適化して、頻繁にアクセスされるデータを繰り返しスキャンしないようにします。

  同じ大きな表や索引を繰り返しスキャンすると、キャッシュ・ヒット率を低下させる可能性があります。バッファ読取り数が多く、頻繁に実行されるSQL文を調べて、実行計画が最適なものであるか確認します。

• 頻繁にアクセスされるデータをクライアント・プログラムまたは中間層にキャッシュして、同じデータを再問合せしないようにします。

• OLTPアプリケーションを実行する大容量データベースでは、ほとんどの行は1回しか(または一度も)アクセスされません。このため、使用後にブロックをメモリーに保持していても意味がありません。

• バッファ・キャッシュ・サイズを連続して増加しないでください。

  バッファ・キャッシュ・サイズを連続して増加しても、データベースが全表スキャンやバッファ・キャッシュを使用しない操作を実行している場合は効果がありません。

• 大規模な全表スキャンが行われている場合は、ヒット率が低くなることを考慮してください。

  長い全表スキャン中にアクセスされたデータベース・ブロックは、最低使用頻度(LRU)リストの最後に配置され、リストの先頭には配置されません。そのため、これらのブロックは、索引参照または小規模な表スキャンを実行するときに読み取られるブロックよりも早く除去されます。

  ノート:

  小規模表のスキャンは、一定のサイズのしきい値を使用して、表に対して実行されるスキャンです。小規模表とは、最大でバッファ・キャッシュの2%か20のいずれか大きい方と定義されます。

データベース・バッファ・キャッシュに割り当てられたメモリーの増加

キャッシュ・ヒット率が低く、全表スキャンを実行しないようにアプリケーションがチューニングされている場合は、バッファ・キャッシュのサイズを増やすことを検討してください。可能な場合は、インスタンスを停止せずに、バッファ・プールを動的にサイズ変更してこの変更を行います。

データベース・バッファ・キャッシュのサイズを大きくするには:

1. DB_CACHE_ADVICE初期化パラメータの値をONに設定します。

2. バッファ・キャッシュ統計の安定化を可能にします。

3. 「V$DB_CACHE_ADVICEビューの使用」の説明を参照し、V$DB_CACHE_ADVICEビュー内のアドバイザ・データを調べて、実行する物理I/Oの量を大幅に減少させるために必要な次の増分を決定します。

4. システムにページングさせずに、バッファ・キャッシュに必要なメモリーを追加で割り当てることができる場合は、このメモリーを割り当てます。

5. バッファ・キャッシュに割り当てられたメモリーの量を増やすには、DB_CACHE_SIZE初期化パラメータの値を増やします。

   DB_CACHE_SIZEパラメータは、データベースの標準ブロック・サイズのデフォルト・キャッシュのサイズを指定します。データベースの標準ブロック・サイズ以外のブロック・サイズを持つ表領域(トランスポータブル表領域など)を作成して使用するには、使用するブロック・サイズごとに個別のキャッシュを構成します。DB_nK_CACHE_SIZEパラメータを使用して、必要な標準以外のブロック・サイズを構成します(nは2、4、8、16または32のいずれかで、標準ブロック・サイズではありません)。

ノート:

• キャッシュ・サイズを選択するプロセスは、キャッシュがデフォルトの標準ブロック・サイズ・キャッシュ、KEEPまたはRECYCLEキャッシュ、標準以外のブロック・サイズ・キャッシュのいずれかにかかわらず同様です。

• キャッシュを大幅に(20%以上)サイズ変更すると、古いキャッシュ・アドバイザ値は破棄されて、新しいサイズに設定されます。大幅にサイズ変更しない場合は、古いキャッシュ・アドバイザ値は既存の値を補間することで新しいサイズに調整されます。

関連項目:

DB_nK_CACHE_SIZEパラメータの詳細は、次を参照してください。

• 『Oracle Database管理者ガイド』

• Oracle Databaseリファレンス

データベース・バッファ・キャッシュに割り当てられたメモリーの削減

キャッシュ・ヒット率が高い場合は、バッファ・キャッシュが十分大きく、最も頻繁にアクセスされるデータを格納できる可能性が高いです。このような場合に、別のメモリー構造にメモリーが必要なときは、バッファ・キャッシュのサイズを小さくすることを検討してください。

データベース・バッファ・キャッシュのサイズを小さくするには:

1. 「V$DB_CACHE_ADVICEビューの使用」の説明を参照し、V$DB_CACHE_ADVICEビュー内のアドバイザ・データを調べて、バッファ・キャッシュのサイズを小さくした場合に、物理I/Oの量が大幅に減少するかどうかを判断します。

2. バッファ・キャッシュに割り当てられたメモリーの量を減らすには、DB_CACHE_SIZE初期化パラメータの値を減らします。

複数バッファ・プールの構成

一般に、ほとんどのシステムでは1つのデフォルト・バッファ・プールが適切です。ただし、アプリケーションのバッファ・プールについて詳しい知識を持つデータベース管理者であれば、複数バッファ・プールを構成することが有益な場合もあります。

非定型アクセス・パターンを持つセグメントの場合、それらのセグメントからのブロックを2つの個別のバッファ・プールであるKEEPプールとRECYCLEプールに格納することを検討してください。セグメントのアクセス・パターンは、常にアクセスされるか(ホットとも呼ばれる)、ほとんどアクセスされない(1日に1回のみバッチ・ジョブでアクセスされる大きなセグメントなど)というように、非定型である可能性があります。

複数バッファ・プールを使用すると、こうした不規則性に対応できます。KEEPプールを使用してバッファ・キャッシュ内の頻繁にアクセスされるセグメントを保持し、RECYCLEプールを使用してオブジェクトがバッファ・キャッシュ内の領域を不必要に占有するのを防ぐことができます。オブジェクトがバッファ・キャッシュに関連付けられると、そのオブジェクトのすべてのブロックがそのキャッシュに配置されます。Oracle Databaseには、特定のバッファ・プールに割り当てられていないオブジェクトのために、DEFAULTバッファ・プールがあります。デフォルト・バッファ・プールのサイズは、DB_CACHE_SIZE初期化パラメータによって決まります。各バッファ・プールでは、同じLRU置換ポリシーが使用されます。たとえば、KEEPプールのサイズが十分ではなく、プールに割り当てられたすべてのセグメントを格納できない場合、最も古いブロックがキャッシュから除去されます。

オブジェクトを適切なバッファ・プールに割り当てると、次の操作を実行できます。

• I/Oの低減または排除

• 個別のキャッシュに対するオブジェクトの隔離または制限

この項では、複数バッファ・プールの構成方法を説明しており、内容は次のとおりです。

• 複数バッファ・プールを使用する際の考慮事項

• 複数バッファ・プールの使用方法

• 個別のバッファ・プールへのV$DB_CACHE_ADVICEビューの使用

• 個別のバッファ・プールへのバッファ・プール・ヒット率の計算

• バッファ・キャッシュ使用パターンの調査

• KEEPプールの構成

• RECYCLEプールの構成

複数バッファ・プールを使用する際の考慮事項

複数バッファ・プールを使用する際は、次の考慮事項を確認してください。

• 大きいセグメントへのランダム・アクセス

• Oracle Real Application Clustersのインスタンス

大きいセグメントへのランダム・アクセス

(バッファ・キャッシュのサイズと比較して)非常に大きいセグメントに大きい索引レンジ・スキャンまたは非有界索引レンジ・スキャンでアクセスすると、LRU除外方法では問題が発生する可能性があります。非順次物理読取りのかなりの割合(10%を超える割合)を1つのセグメントが占有する場合、そのセグメントは大規模であると考えられます。大規模セグメントに対するランダム読取りは、他のセグメントのデータを含むバッファがキャッシュから除去される原因となります。大規模セグメントは、バッファ・キャッシュの大きな割合を消費しますが、キャッシングによる利益はありません。

非常に頻繁にアクセスされるセグメントは、バッファが頻繁にアクセスされるのでバッファ・キャッシュから除去されないため、大規模セグメントの読取りの影響を受けません。ただし、その問題は、大規模セグメントの読取りによるバッファの除外を免れるほど頻繁にはアクセスされないウォーム・セグメントに影響を与えます。この問題を解決するオプションは、次の3つです。

• アクセスされたオブジェクトが索引である場合は、索引に選択性があるかどうかを特定します。選択性がない場合は、さらに選択性のある索引を使用するようにSQL文をチューニングします。

• SQL文をチューニングすると、大きいセグメントが個別のRECYCLEキャッシュに移動されるので、その他のセグメントに影響を与えません。RECYCLEキャッシュはDEFAULTバッファ・プールよりも小さくし、迅速にバッファを再利用する必要があります。

• または、大規模セグメントでは使用されない別のKEEPキャッシュに小さなウォーム・セグメントを移動することも検討してください。キャッシュでのミスが最小限になるように、KEEPキャッシュをサイズ設定します。特定の問合せによってアクセスされるセグメントをKEEPキャッシュに格納し、除去されないようにすることで、その問合せのレスポンス時間をより予測可能にすることができます。

Oracle Real Application Clustersのインスタンス

Oracle Real Application Clusters (Oracle RAC)環境では、各データベース・インスタンスに複数バッファ・プールを作成することを検討してください。データベースの各インスタンスに同じセットのバッファ・プールを定義する必要はありません。インスタンスごとにバッファ・プールのサイズを変えることも、バッファを定義しないこともできます。それぞれのアプリケーション要件に従って、各インスタンスをチューニングします。

複数バッファ・プールの使用方法

オブジェクトのデフォルト・バッファ・プールを定義するには、STORAGE句のBUFFER_POOLキーワードを使用します。この句は、次のSQL文に有効です。

• CREATE TABLE

• CREATE CLUSTER

• CREATE INDEX

• ALTER TABLE

• ALTER CLUSTER

• ALTER INDEX

バッファ・プールを定義すると、そのオブジェクトに対して読み取られたブロックは、すべてそのプールに配置されます。バッファ・プールがパーティション表または索引に対して定義されている場合、オブジェクトの各パーティションは、特定のバッファ・プールで上書きされないかぎり、表または索引定義からバッファ・プールを継承します。

オブジェクトのバッファ・プールがALTER文を使用して変更された場合、変更されたセグメントのブロックを現在格納しているすべてのバッファは、ALTER文を発行する前にあったバッファ・プールに残ります。新たにロードされたブロック、および除去されてリロードされたブロックは、新しいバッファ・プールに配置されます。

関連項目:

STORAGE句でのBUFFER_POOLの指定の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

個別のバッファ・プールへのV$DB_CACHE_ADVICEビューの使用

デフォルト・バッファ・プールと同様、V$DB_CACHE_ADVICEビューを、その他のプールのキャッシュ・サイズ設定の参考に使用できます。初期キャッシュ・サイズを見積り、代表的なワークロードを実行したら、使用するプールのV$DB_CACHE_ADVICEビューを問い合せます。

V$DB_CACHE_ADVICEビューの使用方法の詳細は、「V$DB_CACHE_ADVICEビューの使用」を参照してください。

例13-2に、KEEPプールのデータを問い合せるこのビューの問合せを示します。

例13-2 KEEPプールのV$DB_CACHE_ADVICEビューの問合せ

SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, 
       estd_physical_reads
  FROM V$DB_CACHE_ADVICE
 WHERE name = 'KEEP'
   AND block_size = (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size')
   AND advice_status = 'ON';

個別のバッファ・プールへのバッファ・プール・ヒット率の計算

V$SYSSTATビューのデータは、すべてのバッファ・プールに対する論理読取りと物理読取りを1つの統計セットとして表します。バッファ・プールのヒット率を個々に確認するには、V$BUFFER_POOL_STATISTICSビューを問い合せます。このビューは、プールごとの論理読取りと論理書込みの回数に関する統計を維持します。

関連項目:

• ヒット率の詳細は、「バッファ・キャッシュ・ヒット率の計算」を参照してください

• V$BUFFER_POOL_STATISTICSビューの詳細は、『Oracle Databaseリファレンス』を参照してください

次の問合せでは、V$BUFFER_POOL_STATISTICSビューを使用してヒット率を計算しています。

例13-3 V$BUFFER_POOL_STATISTICSビューの問合せ

SELECT name, physical_reads, db_block_gets, consistent_gets,
       1 - (physical_reads / (db_block_gets + consistent_gets)) "Hit Ratio"
  FROM V$BUFFER_POOL_STATISTICS;

バッファ・キャッシュ使用パターンの調査

V$BHビューは、SGA内に現在存在するすべてのブロックのデータ・オブジェクトIDを示します。プールに多数のバッファがあるセグメントを特定するには、このビューを使用してバッファ・キャッシュ使用パターンを調査します。次の各項で説明するように、すべてのセグメントまたは特定のセグメントのバッファ・キャッシュ使用パターンを調査できます。

• すべてのセグメントのバッファ・キャッシュ使用パターンの調査

• 特定セグメントのバッファ・キャッシュ使用パターンの調査

すべてのセグメントのバッファ・キャッシュ使用パターンの調査

プールに多数のバッファがあるセグメントを特定する方法の1つは、ある時点でバッファ・キャッシュに存在するすべてのセグメントのブロック数を問い合せることです。バッファ・キャッシュ・サイズによっては、このカウントに多数のソート領域を必要とする可能性があります。

例13-4に、すべてのセグメントのブロック数を数える問合せを示します。

例13-4 すべてのセグメントのブロック数の問合せ

COLUMN object_name FORMAT A40
COLUMN number_of_blocks FORMAT 999,999,999,999

SELECT o.object_name, COUNT(*) number_of_blocks
  FROM DBA_OBJECTS o, V$BH bh
 WHERE o.data_object_id = bh.OBJD
   AND o.owner != 'SYS'
 GROUP BY o.object_Name
 ORDER BY COUNT(*);

この問合せの出力例を次に示します。

OBJECT_NAME                              NUMBER_OF_BLOCKS
---------------------------------------- ----------------
OA_PREF_UNIQ_KEY                                        1
SYS_C002651                                             1
..
DS_PERSON                                              78
OM_EXT_HEADER                                         701
OM_SHELL                                            1,765
OM_HEADER                                           5,826
OM_INSTANCE                                        12,644

特定セグメントのバッファ・キャッシュ使用パターンの調査

プールに多数のバッファがあるセグメントを特定する別の方法は、ある時点で個々のオブジェクトにより使用されているバッファ・キャッシュの割合を計算することです。

個々のオブジェクトにより使用されているバッファ・キャッシュの割合を計算するには:

1. DBA_OBJECTSビューを問い合せ、セグメントのOracle Database内部オブジェクト数を検出します。

   SELECT data_object_id, object_type
   FROM DBA_OBJECTS 
   WHERE object_name = UPPER('segment_name'); 
   

   2つのオブジェクトが同じ名前を持つことがあるため(異なる型のオブジェクトの場合)、OBJECT_TYPE列を使用して目的のオブジェクトを識別します。

2. SEGMENT_NAMEに対するバッファ・キャッシュ内のバッファ数を検出します。

   SELECT COUNT(*) buffers
   FROM V$BH
   WHERE objd = data_object_id_value;
   

   data_object_id_valueについては、前のステップのDATA_OBJECT_IDの値を使用します。

3. データベース・インスタンスのバッファ数を検出します。

   SELECT name, block_size, SUM(buffers)
   FROM V$BUFFER_POOL
   GROUP BY name, block_size
   HAVING SUM(buffers) > 0;
   

4. バッファの総数に対するバッファの比率を計算し、現在SEGMENT_NAMEで使用されているキャッシュの割合を取得します。

   % cache used by segment_name = [buffers(Step2)/total buffers(Step3)]
   

ノート:

この方法は、1つのセグメントに対してのみ有効です。パーティション・オブジェクトについては、パーティションごとに問合せを実行します。

KEEPプールの構成

KEEPバッファ・プールの目的は、メモリー内にオブジェクトを保存して、I/O操作を避けることにあります。各オブジェクトをメモリー内に保持するとトレードオフが発生します。頻繁にアクセスされるブロックをキャッシュに保持しておくとより有益です。よりアクティブな他のブロックのためのスペースが減ることになりるため、頻繁に使用しないブロックはキャッシュに保持しないようにしてください。

アプリケーションに頻繁に参照されるセグメントがある場合は、KEEPバッファ・プールにそれらのセグメントのブロックを格納することを検討してください。KEEPプールに保持される一般的なセグメントは、サイズが小さく、頻繁に使用される参照表です。どの表が候補であるかを判別するには、「バッファ・キャッシュ使用パターンの調査」で説明されているように、V$BHビューを問い合せて、候補となる表のブロック数を確認します。

KEEPプールを構成するには:

1. KEEPバッファ・プールのおおよそのサイズを計算します。

   KEEPバッファ・プールのサイズは、バッファ・キャッシュに保持するオブジェクトによって異なります。サイズを見積るには、このプールに割り当てられたすべてのオブジェクトで使用されるブロックを追加します。

   セグメントに関する統計を収集した場合、DBA_TABLES.BLOCKSとDBA_TABLES.EMPTY_BLOCKSを問い合せて使用されるブロック数を判断します。

2. 違う時間にシステム・パフォーマンスの2つのスナップショットを取得します。

   「個々のバッファ・プールへのV$DB_CACHE_ADVICEビューの使用」で説明されているように、V$DB_CACHE_ADVICEビューを使用して、各スナップショットのKEEPプールからデータを問い合せます。

3. 物理読取り(physical reads)、ブロック取得(block gets)および一貫性読取り( consistent gets)について、古い値から新しい値を引いて、これらの結果を使用してヒット率を計算します。

   100%のバッファ・プール・ヒット率が最適とはかぎりません。KEEPバッファ・プールのサイズを減らしても、十分に高いヒット率が維持されることがよくあります。KEEPバッファ・プールから除去されたブロックは、別のバッファ・プールに割り当ててください。

4. DB_KEEP_CACHE_SIZEパラメータの値を必要なサイズに設定して、KEEPバッファ・プールにメモリーを割り当てます。

   KEEPプールのメモリーは、デフォルト・プールのサブセットではありません。

ノート:

オブジェクトのサイズが大きくなった場合に、KEEPバッファ・プールに入りきらなくなることがあります。この場合、キャッシュからブロックが失われ始めます。

RECYCLEプールの構成

メモリーに残さないセグメントに属するブロック用のRECYCLEバッファ・プールを構成できます。RECYCLEプールの目的は、ほとんどスキャンされないか頻繁に参照されないセグメントを保持することです。アプリケーションが非常に大規模なラージ・オブジェクトのブロックにランダムにアクセスする場合、バッファ・プールに格納されているブロックが除去される前に再利用されることはほとんどありません。これは(使用可能物理メモリーの量の制約により)バッファ・プールのサイズに関係なくあてはまります。したがって、そのオブジェクトのブロックをキャッシュする必要はありません。これらのキャッシュ・バッファは、他のオブジェクトに割り当てることができます。

あまり早くメモリーからブロックを破棄しないでください。バッファ・プールが小さすぎると、トランザクションまたはSQL文が実行を完了する前に、ブロックがキャッシュから除外されてしまう可能性があります。たとえば、アプリケーションが表から値を選択し、その値を使用してデータを処理し、レコードを更新する場合があります。SELECT文の後でブロックがキャッシュから削除された場合は、更新を実行するために再度ディスクから読み取る必要があります。ブロックは、ユーザー・トランザクションの所要時間中は保存される必要があります。

RECYCLEプールを構成するには:

• DB_RECYCLE_CACHE_SIZEパラメータの値を必要なサイズに設定して、RECYCLEバッファ・プールにメモリーを割り当てます。

  RECYCLEプールのメモリーは、デフォルト・プールのサブセットではありません。

REDOログ・バッファの構成

バッファ・キャッシュ内のデータ・ブロックに変更を行うサーバー・プロセスでは、REDOデータをログ・バッファに生成します。ログ・ライター・プロセス(LGWR)は、次のいずれかの条件に当てはまる場合に、REDOログ・バッファからオンラインREDOログにエントリをコピーする書込みを開始します。

• REDOログ・バッファの少なくとも1/3が満たされる

• LGWRが、COMMITまたはROLLBACKを実行するサーバー・プロセスによって通知される

• データベース・ライター・プロセス(DBWR)がLGWRに実行するよう通知する

LGWRがREDOログ・ファイルまたはディスクにREDOログ・バッファからREDOエントリを書き込むとき、ユーザー・プロセスは、次の図に説明されているように、ディスクに書き込まれたメモリー内のエントリ上に新しいエントリをコピーできます。

図13-2 REDOログ・バッファ

「図13-2 Redoログ・バッファ」の説明

LGWRは、REDOログ・バッファに新しいエントリ用の領域が残るよう、頻繁にアクセスされる場合でも、できるだけ迅速な書込みを試行します。REDOログ・バッファが大きいほど、新しいエントリ用の領域が確保される可能性が高く、LGWRも効率的にREDOレコードを処理できます。大規模な更新が行われるシステムでは、REDOログ・バッファが小さすぎると、LGWRがREDOを継続的にディスクにフラッシュするため、2/3が空のままになります。

高速のプロセッサと比較的低速のディスクを持つシステムでは、REDOログ・ライターによってREDOログ・バッファの一部がディスクに移動される時間に、プロセッサがREDOログ・バッファの残りにデータを挿入していることがあります。この状況では、大きいREDOログ・バッファは低速のディスクの影響を一時的に隠すことがあります。または、次のいずれかを改善することを検討してください。

• チェックポイント機能またはアーカイブ・プロセス

• LGWRのパフォーマンス(すべてのオンライン・ログを高速のRAWデバイスに移動)

REDOログ・バッファのパフォーマンスを改善するには、次のことを確認してください。

• LGWRがREDOログ・エントリを効率的に書き込めるようにする、バッチ・ジョブに対する一括コミット操作

• 大量のデータをロードするときのNOLOGGING操作の使用

この項では、REDOログ・バッファの構成方法を説明しており、内容は次のとおりです。

• REDOログ・バッファのサイズ設定

• REDOログ・バッファ統計の使用

REDOログ・バッファのサイズ設定

REDOログ・バッファのデフォルト・サイズは、次のようにして計算されます。

MAX(0.5M, (128K * number of cpus))

大量のデータの挿入、変更または削除を行うアプリケーションでは、デフォルトのREDOログ・バッファのサイズ変更が必要になる場合があります。REDOログ・バッファのサイズは、最低8MBに設定することをお薦めします。フラッシュバック機能を使用し、SGAが4GB以上のデータベースでは、最低64MBに設定してください。Oracle Data Guardの非同期REDO転送で使用していて、REDO生成速度が高い場合は、最低256MBに設定します。

REDOログ・バッファのサイズが小さすぎるかどうかを判断するには、「REDOログ・バッファ統計の使用」で説明されているように、REDOログ・バッファ統計を監視します。また、log buffer space待機イベントがデータベース・インスタンスの待機時間における重要な要因であるかどうかもチェックできます。そうでない場合は、ログ・バッファ・サイズが適切にサイズ設定されていると考えられます。

REDOログ・バッファをサイズ設定するには:

• LOG_BUFFER初期化パラメータの値を必要なサイズに設定して、REDOログ・バッファのサイズを設定します。

  このパラメータの値はバイト単位で表されます。

  ノート:

  REDOログ・バッファのサイズは、インスタンスの起動後には変更できません。

REDOログ・バッファ統計の使用

REDO BUFFER ALLOCATION RETRIES統計は、ユーザー・プロセスがREDOログ・バッファ内の領域の使用を待機した回数を反映します。この統計は、V$SYSSTATパフォーマンス・ビューを使用して問い合せることができます。

アプリケーションの実行中、一定期間にわたってredo buffer allocation retries統計を監視する必要があります。この統計の値は、ある時間間隔に対してゼロに近い値である必要があります。この値が継続的に増加する場合は、REDOログ・バッファの領域が使用可能になるまで、ユーザー・プロセスが待機する必要があったことを意味します。この待機は、REDOログ・バッファが小さすぎること、あるいはチェックポイント機能が原因となっていることがあります。この場合は、次のいずれかの方法を検討してください。

• 「REDOログ・バッファのサイズ設定」で説明されているように、REDOログ・バッファのサイズを大きくする

• チェックポイント機能またはアーカイブ・プロセスを改善する。

例13-5に、この統計のV$SYSSTATビューの問合せを示します。

例13-5 V$SYSSTATビューの問合せ

SELECT name, value
  FROM V$SYSSTAT
 WHERE name = 'redo buffer allocation retries';

データベース・キャッシュ・モードの構成

Oracle Database 12cリリース1 (12.1.0.2)から、2つのデータベース・キャッシュ・モードが存在します。旧バージョンのOracle Databaseで使用されるデフォルト・データベース・キャッシュ・モードと、このリリースの新機能である強制全データベース・キャッシュ・モードです。デフォルト・キャッシュ・モードでは、ユーザーが大きな表を問い合せたときにOracle Databaseは基礎データを常にキャッシュするわけではありません。強制全データベース・キャッシュ・モードでは、バッファ・キャッシュが全データベースをキャッシュできるくらい十分大きいとOracle Databaseで想定され、問合せでアクセスされたすべてのブロックのキャッシュが試行されます。

この項では、次の項目について説明します。

• デフォルト・データベース・キャッシュ・モード

• 強制全データベース・キャッシュ・モード

• 強制全データベース・キャッシュ・モードの使用時の判断

• データベース・キャッシュ・モードの検証

ノート:

強制全データベース・キャッシュ・モードは、Oracle Database 12cリリース1 (12.1.0.2)以上で使用可能です。

デフォルト・データベース・キャッシュ・モード

デフォルトでは、全表スキャンの実行時にOracle Databaseではデフォルト・データベース・キャッシュ・モードが使用されます。デフォルト・キャッシュ・モードでは、ユーザーが大きな表を問い合せたときにOracle Databaseは基礎データを常にキャッシュするわけではありません。この操作によってより有用なデータがバッファ・キャッシュから削除される可能性があるためです。

全データベースをキャッシュするのに十分な領域がバッファ・キャッシュにあり、その操作が有効であるとOracle Databaseインスタンスによって判断された場合、インスタンスでは全データベースがバッファ・キャッシュに自動的にキャッシュされます。

全データベースをキャッシュするのに十分な領域がバッファ・キャッシュにないとOracle Databaseインスタンスによって判断された場合は、次のようになります。

• 小さい表は、表サイズがバッファ・キャッシュ・サイズの2%未満である場合のみメモリー内にロードされます。

• 中程度の表は、Oracle Databaseによって最後の表スキャンとバッファ・キャッシュの経過タイムスタンプ間の間隔が分析されます。最後の表スキャンで再利用された表のサイズが、残りのバッファ・キャッシュのサイズよりも大きい場合は、表がキャッシュされます。

• 大きい表は、KEEPバッファ・プールの表を明示的に宣言しないかぎり、通常はメモリー内にロードされません。

ノート:

デフォルト・キャッシュ・モードでは、Oracle DatabaseインスタンスはNOCACHE LOBをバッファ・キャッシュにキャッシュしません。

関連項目:

デフォルト・データベース・キャッシュ・モードの詳細は、『Oracle Database概要』を参照してください

強制全データベース・キャッシュ・モード

メモリーがデータベースに追加されるに従い、バッファ・キャッシュ・サイズも継続的に拡大する可能性があります。バッファ・キャッシュのサイズが非常に大きくなったため、全データベースがメモリーに合致するようなケースもあります。全データベースをメモリー内にキャッシュする機能は、全表スキャンの実行時やLOBのアクセス時にデータベース・パフォーマンスを劇的に改善します。

強制全データベース・キャッシュ・モードでは、データベースのサイズがデータベース・バッファ・キャッシュのサイズより小さい場合、Oracle Databaseが全データベースをメモリー内にキャッシュします。NOCACHE LOBおよびSecureFilesを使用するLOBなどのすべてのデータ・ファイルが、アクセスされているときにバッファ・キャッシュ内にロードされます。

関連項目:

• Oracle Database概要

• 『Oracle Database管理者ガイド』

強制全データベース・キャッシュ・モードの使用時の判断

特にI/Oスループットまたはレスポンス時間で制限されたワークロードにおいて、表スキャンおよびLOBデータ・アクセスのデータベース・パフォーマンスを改善するため、データベース・バッファ・キャッシュのサイズがデータベースのサイズを上回る場合は常に、強制全データベース・キャッシュ・モードの使用を検討します。

強制全データベース・キャッシュ・モードの使用は、次のような状況で検討します。

• 論理データベースのサイズ(または実際の使用済領域)が、Oracle RAC環境内の各データベース・インスタンスの個別バッファ・キャッシュより小さい場合。これはOracle RACデータベース以外にも同様に適用可能です。

• 論理データベースのサイズが、Oracle RAC環境内の(インスタンス・アクセスによって)有効にパーティション化されたワークロードに対する全データベース・インスタンスの合計バッファ・キャッシュ・サイズの80%より小さい場合。

• データベースがSGA_TARGETまたはMEMORY_TARGETを使用する場合。

• NOCACHE LOBをキャッシュする必要がある場合。強制全データベース・キャッシュが使用されないかぎり、NOCACHE LOBがキャッシュされることはありません。

最初の3つの状況では、システム・パフォーマンスを定期的に監視して、パフォーマンスの数値が予想どおりかを検証する必要があります。

あるOracle RACデータベース・インスタンスが強制全データベース・キャッシュ・モードを使用すると、Oracle RAC環境内のその他すべてのデータベース・インスタンスも強制全データベース・キャッシュ・モードを使用します。

マルチテナント環境では、強制全データベース・キャッシュ・モードはコンテナ・データベース(CDB)全体に適用され、そのすべてのプラガブル・データベース(PDB)も含まれます。

データベース・キャッシュ・モードの検証

デフォルトでは、Oracle Databaseではデフォルト・データベース・キャッシュ・モードが実行されます。

強制全データベース・キャッシュ・モードが有効かどうかを検証するには:

• V$DATABASEビューを次のように問い合せます。

  SELECT FORCE_FULL_DB_CACHING FROM V$DATABASE;

  問合せでYESの値が返される場合は、強制全データベース・キャッシュ・モードがデータベース上で有効です。問合せでNOの値が返される場合は、強制全データベース・キャッシュ・モードは無効で、データベースはデフォルト・データベース・キャッシュ・モードの状態です。

  ノート:

  強制全データベース・キャッシュ・モードを有効にするには、次のALTER DATABASEコマンドを使用します。

  ALTER DATABASE FORCE FULL DATABASE CACHING;

関連項目:

• 強制全データベース・キャッシュ・モードの有効化および無効化の詳細は、『Oracle Database管理者ガイド』を参照してください

• V$DATABASEビューの詳細は、『Oracle Databaseリファレンス』を参照してください