|
|
Statspack は、Oracle 社が Oracle9i データベースの配布キットと共に提供するパフォーマンス チューニング キットです。Statspack は、わずかな操作で任意の Oracle9i データベースにインストール可能で、そのデータベース インスタンスのパフォーマンスに関する詳細な分析データをすばやく収集します。この付録では、Statspack のインストール、スナップショットの収集、レポートの生成、および WLI の主なデータベースのボトルネックの特定について、簡単に説明します。
Oracle Statspack ツールは、比較的簡単な操作でインストールできます。以降では、Oracle Statspack を UNIX システムにインストールする操作を手順ごとに説明します。
$ORACLE_HOME/rdbms/admin ディレクトリに移動します。# cd $ORACLE_HOME/rdbms/admin/
spcreate.sql を起動します。# sqlplus "/ as sysdba" @spcreate.sql
SQL> exit
Oracle Statspack ツールをインストールしたら、データベースのパフォーマンスを評価するためにスナップショットを収集する必要があります。スナップショットとは、ある時点におけるすべてのデータベース統計の集まりで、Oracle データベースによって継続的に収集されます。2 つのスナップショットが収集されると、それらを比較して、その間に発生したアクティビティを特定できます。
スナップショットは、さまざまなレベルで収集できます。上位レベルほど、データベースに関するより多くの情報が収集されます。つまり、レベルが上がるたびに、その下位レベルで収集された情報が含まれていきます。
Oracle Statspack には、spreport.sql という包括的なレポート生成スクリプトが用意されています。このスクリプトを実行すると、使用できるスナップショットのリストが出力され、レポートの対象となる 2 つのスナップショットの ID と名前を指定するよう求められます。その結果は、テキスト形式のレポートで出力されます。
Oracle Statspack では、WLI で発生したデータベース パフォーマンスの主なボトルネックをすべて特定できます。このセクションでは、WLI のデータベース パフォーマンスの主なボトルネックと、これらのボトルネックを Oracle Statspack レポートで特定する方法について説明すると共に、これらを回避するための推奨事項を示します。
エンキューとは、さまざまなリソースへのアクセスを直列化するローカルのロックです。この待機イベントは、要求されたモードとは互換性のないモードで他のセッション (複数の場合あり) によって保持されているロックを待機している状態を示します。
エンキューの待機を減らすための対策は、待機の原因となっているロックのタイプによって異なります。
エンキューの待機の原因となるロックのタイプは、主に TX、TM、および ST の 3 つです。
エンキューの待機とその種類は、Statspack レポートの「Enqueue activity」セクションを参照することで特定できます。
WLI アプリケーションでエンキューの待機が発生するのは、主にインデックス付きのモノトニックなキー、および WLI_PROCESS_INSTANCE_INFO テーブルに対するデータ ブロック アクセスが原因です。これらのオブジェクトに対するエンキューの待機を減らすには、前者の場合は逆キー インデックスを使用し、後者の場合は WLI_PROCESS_INSTANCE_INFO テーブルをパーティション化します。逆キー インデックスの使用方法、およびパーティション化方法の詳細については、「WLI スキーマのチューニング」を参照してください。
ユーザ セッションが COMMIT (またはロールバック) を実行すると、セッションの REDO 情報を REDO ログ ファイルにフラッシュする必要があります。ユーザ セッションは、必要な REDO 情報をログ バッファから REDO ログ ファイルにすべて書き込むよう、ログ ライター (LGWR) に要求します。LGWR は、処理が完了すると、ユーザ セッションに通知します。この待機イベントが発生するのは、LGWR がすべての REDO に対する変更が正常にディスクに保存されたことを確認し、ユーザ セッションに返答するまで、ユーザ セッションが待機している間です。
ログ ファイルの同期化の待機は、Statspack レポートの「Top 5 Timed Events」セクションまたは「Wait Events」セクションを参照することで特定できます。
このような待機は、処理速度の速いディスクにログ ファイルを移動するか、バッチ トランザクションを実行して COMMIT の頻度を下げることで減らすことができます。
バッファ ビジー待機は、セッションがバッファ キャッシュ内のデータベース ブロックにアクセスする必要があるが、バッファが「ビジー」であるために、アクセスできないときに発生します。このような待機は、主に次の 2 つのケースで発生する可能性があります。
バッファ ビジー待機が多く発生しているセグメントは、Statspack レポートの「Top 5 Buf. Busy Waits per Segment」セクションを参照することで特定できます。
バッファ ビジー待機は、ビジー状態のインデックスに逆キー インデックスを使用する方法や、ビジー状態のテーブルをパーティション化する方法で減らすことができます。逆キー インデックスの使用方法、およびパーティション化方法の詳細については、「WLI スキーマのチューニング」を参照してください。
ログ ファイルへのパラレル書き込みの待機は、REDO レコードの REDO ログ ファイルへの書き込みの完了を待機しているときに発生します。この待機は、ログ ライター (LGWR) がレコードを REDO ログ バッファから現在のオンライン ログにコピーする通常のアクティビティの一部として発生します。
実際の待機時間は、未処理の I/O 要求がすべて完了するまでにかかる時間です。書き込み要求はパラレルに実行できますが、最後の I/O がディスクに反映されるまで、パラレル書き込みが完了したとは見なされません。このため、待機時間は、OS がすべての要求を完了するまでにかかる時間に左右されます。
ログ ファイルへのパラレル書き込みの待機は、Statspack レポートの「Top 5 Timed Events」セクションまたは「Wait Events」セクションを参照することで特定できます。
ログ ファイルへのパラレル書き込みの待機は、ログ ファイルを処理速度の速いディスクや、競合の少ない別のディスクに移動することで減らすことができます。
DB ファイルのシーケンシャル読み込みの待機は、I/O 読み込み要求の完了を待機している状態を指します。DB ファイルのシーケンシャル読み込みは、データを連続したメモリに読み込むという点で「DB ファイルの分散読み込み」とは異なっているため、このように呼ばれます。分散読み込みでは、複数のブロックを読み込み、それらを SGA 内の異なるバッファに分散します。読み込みの待機時間が長い場合は、Oracle が読み込みを実行しているセグメントを特定することで解決できる場合があります。
読み込みが多く発生しているセグメントは、Statspack レポートの「Top 5 Physical Reads per Segmen」セクションおよび「SQL ordered by Reads」セクションを参照することで特定できます。
ブロックの読み込みは不可避であるため、不要な I/O を最小限に抑える方法を考えます。シーケンシャル読み込みの I/O を減らすには、テーブルのフル スキャンを伴う SQL 要求をチューニングし、大きなテーブルにはパーティション化オプションを使用します。
DB ファイルの分散読み込みの待機は、セッションが複数ブロックの I/O の完了を待機しているときに発生します。この待機は、通常、テーブルのフル スキャンや、インデックスの高速フル スキャンの実行時に発生します。
読み込みが多く発生しているセグメントは、Statspack レポートの「Top 5 Physical Reads per Segmen」セクションおよび「SQL ordered by Reads」セクションを参照することで特定できます。
最良の方法は、より高速で選択性の高いデータ読み込み方法がある場合には、アプリケーションがオンライン上にあるアプリケーション データにテーブルのフル スキャンを繰り返し実行しないようにすることです。また、クエリをチューニングして、インデックスを使用するようオンラインの SQL を最適化します。
バッファ ヒット率は、プロセスがデータ ブロックをメモリ内で検出する頻度と、ディスクから読み込む頻度の対比を表すメトリックです。
バッファ ヒット率は、Statspack レポートの「Instance Efficiency Percentages」セクションに記載されています。
バッファ ヒット率の実際の値はそれほど重要ではなく、この値をある期間にわたって監視し、データベースに対するアクティビティの傾向が著しく変化したときに、それを検出できるかどうかのほうが重要です。ヒット率が 80% を下回った場合は、DB_CACHE_SIZE パラメータの値を増やして、データベースに割り当てるメモリを増やす必要があります。
また、SQL ステートメントの処理パフォーマンスが低い場合も、ヒット率が低くなります。この場合は、DB_CACHE_SIZE を増やしても、バッファ ヒット率は改善されない場合があります。原因となっている SQL ステートメントをチューニングして、不要な物理 I/O を避ける必要があります。
行ロックの待機は、現在他のプロセスによってロックされている行に対し、互換性のないロックを要求したときに発生します。このようなロックの待機は、通常、主キー インデックスを使用したテーブルへの大容量データの挿入が原因で発生します。
行ロックの待機が多数発生しているためにパフォーマンスが低下しているセグメントは、Statspack レポートの「Top 5 Row Lock Waits per Segment」セクションで特定できます。
このような待機は、テーブルをパーティション化するか、逆キー インデックスを使用することで回避できます。WLI でこのような待機が発生するのは、WLI_PROCESS_INSTANCE_INFO テーブル、およびこのテーブルの主キー インデックスです。逆キー インデックスの使用方法、およびパーティション化方法の詳細については、「WLI スキーマのチューニング」を参照してください。
ライブラリ キャッシュ ヒット率は、Oracle が解析済みの SQL ステートメントまたは PL/SQL ステートメントを、ライブラリ キャッシュから取得する頻度を表します。アプリケーションが SQL またはストアド プロシージャを呼び出すと、Oracle はライブラリ キャッシュを調べて、ステートメントの解析済みバージョンがすでに保存されているかどうか確認します。解析済みのステートメントがライブラリ キャッシュに保存されていれば、Oracle はそのステートメントを直ちに実行します。保存されていない場合は、Oracle はステートメントを解析し、ライブラリ キャッシュ内に共有の SQL 領域を割り当てます。ライブラリ キャッシュ ヒット率が低い場合、それだけ解析が多く実行されるため、パフォーマンスが低下し、データベース関連の処理による CPU の消費が多くなります。
ライブラリ ヒット率は、Statspack レポートの「Instance Efficiency Percentages」セクションに記載されています。
ヒット率が 80% を下回っている場合は、共有プール領域のサイズを増やすと、解決できる場合があります。これには、SHARED_POOL_SIZE パラメータの値を変更します。
|
