10gリリース2（10.2）
B19207-02
 目次 |
 索引 |
| Oracle Database パフォーマンス・チューニング・ガイド 10gリリース2（10.2） B19207-02 |
|
データベースの初期構成後は、インスタンスのチューニングがパフォーマンスのボトルネックを解消するために重要になります。この章では、Oracleパフォーマンス・メソッドに基づいたチューニング・プロセスを説明します。
この章には次の項があります。
次に、インスタンスのチューニング用のOracleパフォーマンス・メソッドの主な手順を示します。
パフォーマンス問題の範囲についてユーザーから候補フィードバックを取得します。
行う変更および変更を実装した場合に予測される結果を提示します。次に、変更を実装してアプリケーション・パフォーマンスを測定します。
この章の後半では、Oracleの動的パフォーマンス・ビューを使用したインスタンスのチューニングについて説明します。ただし、拡張機能リストによる統計の収集、監視およびチューニングには、自動ワークロード・リポジトリおよびAutomatic Database Diagnostic Monitorを使用することをお薦めします。「自動ワークロード・リポジトリの概要」および「Automatic Database Diagnostic Monitor」を参照してください。
ソリューションの実装を試みる前に、チューニング調査の目的と問題の性質をよく理解しておくことが不可欠です。これについて理解していないと、事実上、効果的な変更は実装できません。この段階で収集されたデータを使用して、次に行うこと、および調査する事象を簡単に決定できます。
次のデータを収集します。
許容できるパフォーマンスの測定尺度は何ですか?1時間、または1秒間当たり何件のトランザクションで、応答時間が必要なパフォーマンス・レベルを満たしますか?
スローダウンで何が影響を受けますか?たとえば、インスタンス全体は低速ですか?それは、特定のアプリケーション、プログラム、特定の操作またはシングル・ユーザーですか?
その問題はピーク時間のみ明白ですか?パフォーマンスはその日の経過に伴って低下しますか?スローダウンは徐々に（月または週の単位で）発生しましたか、または突然発生しましたか?
これは、問題の範囲の識別に役立ち、問題の修復のために実装された変更により実際に改善されたかどうかを判断するときの比較結果の測定基準としての役割を果たします。一貫して再生可能な応答時間またはジョブ実行時間の測定値を検索します。プログラムの動作が正常だったときよりタイミングがどのくらい悪化していますか?
パフォーマンスが許容可能になった後に変化した内容を識別します。これにより、潜在的な原因を素早くつきとめることができます。たとえば、オペレーティング・システムのソフトウェア、ハードウェア、アプリケーション・ソフトウェアまたはOracleリリースがアップグレードされましたか?さらに多くのデータがシステムにロードされたか、データ・ボリュームまたはユーザー人口が増加しましたか?
このフェーズの終わりまでに、症状についてよく理解しておく必要があります。症状をプログラムまたはプログラム・セットにローカルなものとして識別できる場合、その問題はインスタンス全体のパフォーマンスの問題とは異なる方法で処理されます。
データベース・サーバーに対する負荷とデータベース・インスタンスを調べてください。オペレーティング・システム、I/Oサブシステムおよびネットワーク統計を検討してください。これらの領域を調べると、調査する価値のあるものは何かが容易にわかります。多層のシステムでは、アプリケーション・サーバーの中間層ホストも調べてください。
ホスト・ハードウェアを調べると、システム内のボトルネックがよくわかります。このため、相互参照と以降の診断に役立つOracleパフォーマンス・データを判断できます。
調べるデータには、次のものがあります。
アイドル状態のCPUが大量にある場合、I/O、アプリケーションまたはデータベースのボトルネックが存在する可能性があります。ただし、wait I/Oはアイドル状態のCPUとみなす必要があります。
CPU使用率が高い場合は、CPUが効果的に使用されているかどうかを判断してください。CPU使用率の大部分は、CPU使用率の高い少数のプログラムによるものですか、または均等に分散されたワークロードでCPUが消費されていますか?
CPUが使用頻度の高い少量のプログラムで使用されている場合は、プログラムを調べて原因を判断してください。一部のプロセスのみが1つのCPUの能力全体を使用しているかどうかを確認してください。プロセスによっては、この情報はCPUまたはプロセスによりワークロードがバインドされていることを示している場合があり、プロセス・アクティビティを分割またはパラレル化することで解決できます。
プログラムがOracleのプログラムではない場合は、それらのプログラムがそのような量のCPUを必要としているかどうかを識別してください。必要としている場合は、プログラムの実行をピーク以外の時間に遅らせることができるかどうかを判断します。また、これらのCPU集中型プロセスを識別すると、I/O、ネットワークおよびページングなど、リソースを使用している特定のアクティビティと、それがOracleワークロードにどのように関連付けられるかを絞り込むことができます。
少量のOracleプロセスがほとんどのCPUリソースを使用する場合は、SQL_TRACEとTKPROFを使用してSQL文またはPL/SQL文を識別し、特定の問合せまたはPL/SQLのプログラム・ユニットをチューニングできるかどうかを確認します。たとえば、CPUを多く使用するようなキャッシュ内の多数のデータ読込み（論理読込み）に関連したSELECT文があった場合、その文のSQLの最適化によりCPUの集中的な使用を回避できます。
Oracle CPU統計は、複数のV$ビューで使用できます。
V$SYSSTATは、すべてのセッションにおけるOracleのCPU使用率を示します。CPU used by this session統計は、すべてのセッションで使用されているCPUの集計を示します。parse time cpu統計は、解析に使用された総CPUタイムを示します。
V$SESSTATは、各セッションにおけるOracleのCPU使用率を示します。このビューを使用して、特にどのセッションがCPUの大部分を使用しているかを判断します。
V$RSRC_CONSUMER_GROUPは、各コンシューマ・グループのCPU使用率の統計を示します。
CPUタイムと実時間が異なることを認識することが重要です。8つのCPUを使用する場合、実時間の所定の時間に、8分のCPUタイムが利用できます。WindowsおよびUNIXでは、これはユーザー時間またはシステム時間（Windowsでは特権モード）となります。したがって、システム上のすべてのプロセス（スレッド）で使用される平均CPUタイムは、1分の実時間間隔当たり1分を超える可能性があります。
ある時点でのOracleが使用したシステムの時間の長さはわかります。したがって、8分が使用可能でOracleがそのうちの4分を使用している場合は、総CPUタイムの50%がOracleによって使用されていることがわかります。ユーザーのプロセスがその時間を消費していない場合は、他のプロセスが消費しています。CPUタイムを使用しているプロセスを識別し、原因を解明し、それらのプロセスのチューニングを試行してください。第20章「アプリケーション・トレース・ツールの使用方法」を参照してください。
CPU使用率が多数のOracleサーバー・プロセスに均一に分散している場合は、V$SYS_TIME_MODELビューを調べると、最長時間が消費されているプロセスを正確に把握できます。 表10-1「待機イベントおよび潜在的な原因」を参照してください。
過度にアクティブなI/Oシステムは、2より大きいディスク・キューの長さ、すなわち、20〜30ミリ秒を超えるディスク・サービス時間でわかります。I/Oシステムが過度にアクティブである場合、さらに多くのディスク間にI/Oを分散させることで利益を得られる潜在的なホット・スポットの有無をチェックします。また、これらのリソースを使用して、プログラムのリソース要件を少なくして負荷を減らせるかどうかも識別します。
オペレーティング・システムの監視ツールを使用して、システム全体で実行されているプロセスを判別し、すべてのファイルに対するディスク・アクセスを監視してください。データファイルとREDOログ・ファイルを保持しているディスクは、Oracleに関連しないファイルも保持している可能性があります。データベース・ファイルを含むディスクに対する過度のアクセスを減らしてください。Oracle以外のファイルへのアクセスは、V$ビューを介してではなく、オペレーティング・システムの機能を介してのみ監視できます。
多数のUNIXシステム上のsar -d（またはiostat）やWindowsシステム上の管理パフォーマンス監視ツールなどのユーティリティは、システム全体のI/O統計を調べます。
V$SYSTEM_EVENTのOracle待機イベント・データをチェックして、トップの待機イベントがI/O関連かどうかを確認します。I/O関連イベントには、db file sequential read、db file scattered read、db file single write、db file parallel writeおよびlog file parallel writeが含まれます。これらはいずれも、データファイルおよびログ・ファイルに対して実行されたI/Oに対応するイベントです。これらの待機イベントのうちのいずれかが高い平均時間に該当する場合は、I/Oの競合を調べる必要があります。
自動ワークロード・リポジトリ・レポート内のI/OセクションでホストI/Oシステム・データを相互参照し、ホット・データファイルおよび表領域を識別します。さらに、オペレーティング・システムから報告されたI/O時間と、Oracleから報告された時間とを比較して、それらに一貫性があるかどうかを確認します。
I/Oの問題によって、I/Oに関連しない待機イベントが明らかになる場合もあります。たとえば、バッファ・キャッシュ内で空きバッファを検出できない場合や、ディスクへのログ書込みが完了するまでの待機時間が長い場合も、I/O問題の症状を示す場合があります。I/Oシステムを再構成する必要があるかどうかを調べる前に、I/Oシステム上の負荷を減らせるかどうかを判断します。Oracle I/O負荷を減らすには、V$SQLAREAビューを問い合せるか、または自動ワークロード・リポジトリ・レポートの'SQL ordered by Reads'セクションを確認して、多数の物理読取りを実行するSQL文を調べます。これらの文を調べて、I/Oの回数を減らすようにこれらのSQL文をチューニングする方法を調べます。
SQL文で発生したOracleに関連するI/Oの問題がある場合は、それをチューニングしてください。Oracleサーバーが使用可能なI/Oリソースを使用していない場合、I/Oをすべて使用しているプロセスを識別します。プロセスがI/Oをすべて使用している理由を判断し、次にこのプロセスをチューニングします。
|
関連項目:
|
オペレーティング・システムのユーティリティを使用して、ネットワーク・ラウンドトリップのping時間と衝突数を調べます。ネットワークで応答時間の大幅な遅延が発生している場合は、考えられる原因を調べてください。
ネットワーク負荷を減らすには、大きいデータ転送をピーク時間外へスケジュールするか、リモート・ホストに対して要求当たり1回ずつ（またはそれ以上）アクセスせずに、要求をバッチ処理するようにアプリケーションをコーディングします。
問題の診断の一貫性が保たれるようにするには、Oracle統計を調べてオペレーティング・システムの統計と相互参照してください。ただし、目標がOracleインスタンスをチューニングすることにあれば、修正アクションを実装する前にOracle統計を調べてOracleの観点からリソース・ボトルネックを識別します。 「Oracle統計の解釈」を参照してください。
チューニング中に使用する一般的なOracleデータ・ソースを次に示します。
Oracleでは、初期化パラメータSTATISTICS_LEVELを提供し、データベース内で主要統計収集またはアドバイザをすべて制御します。このパラメータでは、データベースに統計収集レベルを設定します。
STATISTICS_LEVELの設定に応じて、次のように一定のアドバイザ機能または統計が収集されます。
BASIC: アドバイザ機能も統計も収集されません。監視機能および多数の自動機能が使用禁止になります。重要なOracle機能が使用禁止になるため、この設定は使用しないことをお薦めします。
TYPICAL: これはデフォルト値であり、すべての主要統計が収集され、データベース全体のパフォーマンスが最高になります。ほとんどの環境では、この設定で十分です。
ALL: TYPICAL設定を使用して収集されるすべてのアドバイザ機能と統計に加えて、オペレーティング・システム時間統計および行ソース実行統計が含まれます。
関連項目:
STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
STATISTICS_LEVEL、DB_CACHE_ADVICE、TIMED_STATISTICSまたはTIMED_OS_STATISTICS初期化パラメータを設定する場合の考慮事項は、「統計の解釈」を参照してください。
このビューには、STATISTICS_LEVELで制御される統計またはアドバイザ機能のステータスがリストされます。
待機イベントは、処理を継続する前にイベントが完了するまで待機する必要があることを示すために、サーバー・プロセスまたはスレッドによって増やされる統計です。待機イベント・データは、ラッチの競合、バッファの競合、I/Oの競合などのパフォーマンスに影響を与えると思われる様々な問題の症状を表します。ただし、これらの問題は実際の原因でなく、問題の症状にすぎないことに注意してください。
待機イベントは、クラス別にグループ化されています。待機イベント・クラスには、Administrative、Application、Cluster、Commit、Concurrency、Configuration、Idle、Network、Other、Scheduler、System I/OおよびUser I/Oがあります。
サーバー・プロセスは、次の症状に対して待機します。
待機イベント統計には、イベントを待機した回数や、イベントが完了するまでの待機時間があります。TIMED_STATISTICS初期化パラメータをtrueに設定すると、各リソースを待機した時間も表示されます。
ユーザー応答時間をできるだけ少なくするには、イベントが完了するまでサーバー・プロセスが待機する時間を減らします。すべての待機イベントが同じ待機時間を持っているとはかぎりません。したがって、発生回数の多い待機イベントより、最大の合計時間を持つイベントを調べる方が重要です。通常は、少なくともパフォーマンスの監視中にTIMED_STATISTICS動的パラメータをtrueに設定することが最善です。STATISTICS_LEVELの設定の詳細は、「統計収集のレベルの設定」を参照してください。
待機イベント統計について、これらの動的パフォーマンス・ビューを問い合せることができます。
V$ACTIVE_SESSION_HISTORY V$ACTIVE_SESSION_HISTORYビューには、1秒ごとにサンプリングされたアクティブなデータベース・セッションのアクティビティが表示されます。 「Active Session History（ASH）」を参照してください。
V$SESS_TIME_MODELおよびV$SYS_TIME_MODELV$SESS_TIME_MODELおよびV$SYS_TIME_MODELビューには、データベース・コールの所要時間合計であるDB timeなど、時間モデル統計が含まれます。
V$SESSION_WAITV$SESSION_WAITビューには、アクティブ・セッションが待機中のリソースまたはイベントが表示されます。
V$SESSION V$SESSIONビューには、V$SESSION_WAITビューに含まれているのと同じ待機統計が含まれています。該当する場合、このビューには、セッションが現在待機中のオブジェクトの詳細情報（オブジェクト番号、ブロック番号、ファイル番号および行番号）と現在の待機の原因となったブロックしているセッションも含まれます。
V$SESSION_EVENTV$SESSION_EVENTビューは、セッションが開始した後に待機したすべてのイベントのサマリーを示します。
V$SESSION_WAIT_CLASSV$SESSION_WAIT_CLASSビューは、待機数および各セッションの待機イベントの各クラスで消費される時間を示します。
V$SESSION_WAIT_HISTORYV$SESSION_WAIT_HISTORYビューは、各アクティブ・セッションの最後の10個の待機イベントを示します。
V$SYSTEM_EVENTV$SYSTEM_EVENTビューは、インスタンス起動後のインスタンスの、全イベント待機のサマリーを示します。
V$EVENT_HISTOGRAMV$EVENT_HISTOGRAMビューには、待機数、最大待機時間およびイベントごとの合計待機時間を示すヒストグラムが表示されます。
V$FILE_HISTOGRAMV$FILE_HISTOGRAMビューには、ファイルごとに1ブロック読取り中の待機回数を示すヒストグラムが表示されます。
V$SYSTEM_WAIT_CLASSV$SYSTEM_WAIT_CLASSビューは、待機数に対するインスタンス全体の総時間および待機イベントの各クラスで消費される時間を示します。
V$TEMP_HISTOGRAM V$TEMP_HISTOGRAMビューには、テンポラリ・ファイルごとに1ブロック読取り中の待機回数を示すヒストグラムが表示されます。
パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・データを調査します。最大時間がリストされるイベントは、多くの場合、パフォーマンス・ボトルネックを顕著に示しています。たとえば、V$SYSTEM_EVENTを参照することで、多くのbuffer busy waitsが発生していると気づくことがあります。おそらく、多数のプロセスが同じブロックに挿入しようとするときに、各プロセスが他のプロセスの挿入を待機してからでないと挿入できないことが原因です。問題となっているオブジェクトに自動セグメント領域管理またはパーティション化を使用することで解決する可能性があります。V$SESSION_WAIT、V$SESSION_EVENTおよびV$SYSTEM_EVENTの各ビューの差異の説明は、「待機イベント統計」を参照してください。
システム統計は通常、パフォーマンスの問題の原因をさらに示すものを見つけるために、待機イベント・データとともに使用されます。
たとえば、最大の待機イベント（待機時間の点で）がbuffer busy waitsイベントであることをV$SYSTEM_EVENTが示している場合、V$WAITSTATビューで使用できる特定のバッファ待機統計を調べて、どのブロック・タイプが最大の待機カウントと最大の待機時間を持っているかを識別します。
ブロック・タイプを識別した後、問題の発生中にV$SESSIONをリアルタイムで調べるか、問題の発生後にV$ACTIVE_SESSION_HISTORYおよびDBA_HIST_ACTIVE_SESS_HISTORYを調べ、表示されたオブジェクト番号を使用して競合されたオブジェクトも識別します。このデータの組合せは、適切な修正アクションを示しています。
統計は、多数のV$ビューで使用できます。次の内容を含む共通ビューもあります。
このビューには、1秒ごとにサンプリングされたアクティブなデータベース・セッションのアクティビティが表示されます。 「Active Session History（ASH）」を参照してください。
これには、ロールバック、論理および物理I/O、解析データなど、Oracleの様々な部分の統計全体が含まれています。バッファ・キャッシュ・ヒット率などの比率を計算するには、V$SYSSTATからのデータを使用します。
これには、ファイル当たりのI/O回数や平均読込み時間など、ファイルごとの詳細なファイルI/O統計が含まれています。
これには、詳細なロールバック・セグメントおよびUNDOセグメント統計が含まれています。
これには、エンキューが要求された回数やエンキューを待機した回数、待機時間など、各エンキューの詳細なエンキュー統計が含まれています。
これには、各ラッチが要求された回数やラッチを待機した回数など、各ラッチの詳細なラッチ使用統計が含まれています。
個別のセグメントに関連するパフォーマンス問題に焦点をあてるのに役立つ、セグメント・レベルの統計を収集できます。セグメント・レベルの統計を収集して表示することは、インスタンスで競合度の高い表あるいは索引を効果的に識別するための優れた方法です。
パフォーマンスの問題を識別するために待機イベントおよびシステム統計を表示した後で、セグメント・レベルの統計を使用して問題の原因となっている特定の表または索引を検索できます。バッファ・ビジー待機が、大半の待機時間の原因になっていることをV$SYSTEM_EVENTが示している例を考えます。buffer busy waitsの原因になっているトップ・セグメントをV$SEGMENT_STATISTICSから選択できます。これにより、それらのセグメントの問題の解決に集中できます。
セグメント・レベルの統計は、次の動的ビューを使用して問い合せます。
V$SEGSTAT_NAME このビューには収集するセグメント統計と、各種統計（たとえばサンプル統計など）のプロパティがリストされます。
V$SEGSTAT これは非常に効率的で、リアルタイム監視が可能なビューであり、統計値、統計名およびその他の基本情報が表示されます。
V$SEGMENT_STATISTICS ユーザーが扱いやすい統計値のビューです。V$SEGSTATのすべての列の他、ここにはセグメント所有者や表領域名に関する情報があります。統計の理解は容易になりますが、コストがより高くなります。チューニングを実施した後、多くの場合、問題を軽減できると思われる2つまたは3つの変更を識別できます。どの変更が最高の利益を提供するかを識別するには、一度に1回の変更を実装することをお薦めします。変更の効果は、問題定義段階でみられたベースライン・データ測定と対照して測定する必要があります。
一般に、パフォーマンスの問題を持つ大半のサイトでは、一度に重複した変更を実装するので、どの変更が利益を実現したかを識別できません。これはすぐに問題になることはありませんが、どの変更が最も効果をあげ、どのような作業を優先する必要があるかを知ることは不可能なので、今後同様の問題が発生した場合に大きな障害になります。
個別に変更を実装できない場合は、異なる変更の効果の測定を試みてください。たとえば、変更された問合せのパフォーマンスを向上するために新しい索引を作成する効果とは別に、REDOの生成を最適化するために初期化変更を行う効果を測定します。SQLがチューニングされ、オペレーティング・システムのディスク・レイアウトが変更され、初期化パラメータも同時に変更されている場合は、オペレーティング・システムをアップグレードすることの利益は測定できません。
パフォーマンス・チューニングは反復的なプロセスです。インスタンス・ワイドのパフォーマンスの問題を解決する万全策が見つかることはほとんどありません。ほとんどの場合、あるボトルネックを解決しても別の（ときにはさらに悪い）問題が発生するため、優れたパフォーマンスにはパフォーマンス・チューニング段階を反復する必要があります。
いつチューニングを停止するかを知ることも重要です。パフォーマンスの最も優れた測定は、統計が理想的な値にどの程度近いかではなく、ユーザーの理解力です。
インスタンスにパフォーマンスの問題があった時を示す統計を収集します。比較のためのベースライン・データをすでに収集してある場合は、問題のワークロードを最も代表するベースラインからのデータと、現行のデータを比較できます。
2つのレポートを比較する場合、それらのレポートが、システムを比較できるようなワークロードか確認してください。
待機イベントは通常、最初に検査するデータです。ただし、ベースライン・レポートがある場合は、負荷が変化したかどうかをチェックします。ベースラインがあるかどうかにかかわらず、リソースの使用率が高いかどうかを確認すると便利です。
検査する負荷に関連する統計には、redo size、session logical reads、db block changes、physical reads、physical read total bytes、physical writes、physical write total bytes、parse count（total）、parse count（hard）およびuser callsが含まれます。このデータは、V$SYSSTATから問合せが行われます。秒ごとおよびトランザクションごとに、このデータを正規化することが最も有効です。また、physical write total bytesおよびphysical write total bytesの合計を使用して、1秒当たりのI/Oの総負荷（MB）を調べるのにも便利です。結合した値には、Oracleバックグラウンド・プロセスと同様Recovery Managerバックアップおよびリカバリによって、バッファ・キャッシュ、REDOログ、アーカイブ・ログに使用されたI/Oが含まれます。
自動ワークロード・リポジトリ・レポートの「ロード・プロファイル」の項を参照してください。データは、トランザクションおよび秒ごとに正規化されています。
秒ごとの負荷プロファイル統計は、スループットの変化（すなわち、インスタンスの作業実行量が毎秒ごとに増えているかどうか）を示します。トランザクションごとの統計は、アプリケーション特性の変化をベースライン・レポートからの対応する統計と比較することで識別します。
アクティビティ率が非常に高いかどうかを識別するには、秒ごとに正規化した統計を調べます。包括的に高い値を推薦することが難しいのは、しきい値が各サイトで異なり、アプリケーション特性、CPUの個数と速度、オペレーティング・システム、I/OシステムおよびOracleリリースで異なるからです。
次に、いくつかの一般化された例を示します（許容値は各サイトで異なります）。
V$SYSSTATに表示される統計のDB timeに比べて大きいかどうかを調べます。大きい場合は、自動ワークロード・リポジトリ・レポートのSQL ordered by Parse Callsセクションを調べます。
Oracleが何かの待機を処理する場合は必ず、定義済待機イベント・セットの1つを使用し、待機を記録します。これらの待機イベントは、待機クラス別にグループ化されます。Idle待機クラスには、実行する作業がなく、さらに作業が実行されるのを待っている場合にプロセスが待機するイベントすべてがグループ化されます。アイドル状態でないイベントはリソースあるいはアクションが完了するまでの非生産的な待機時間を示します。
待機イベント・データを使用する最も効率的な方法は、待機時間別にイベントを順序付けすることです。この方法は、TIMED_STATISTICSがtrueに設定されているときのみ可能です。設定しない場合は、待機イベントを待機数別にランク付けします。これは、一般的に問題を最もよく表す順序付けではありません。
|
関連項目:
|
どこで時間が消費されているかが判明してから、次の手順を実行してください。
V$SYSTEM_EVENTのデータ収集を調べます。対象のイベントは、待機時間別にランク付けする必要があります。待機時間の最も大きいパーセンテージを持つ待機イベントを識別します。待機時間のパーセンテージを決定するには、アイドル・イベント（Null event、SQL*Net message from client、SQL*Net message to clientおよびSQL*Net more data to clientなど）を除くすべての待機イベントの合計待機時間を追加します。各イベントの待機時間をすべてのイベントの総待機時間で除算し、5つの最も重要なイベントの相対的なパーセンテージを計算します。
|
関連項目:
|
別の方法として、自動ワークロード・リポジトリ・レポートの先頭の「トップ5待機イベント」の項を参照してください。この項では、待機イベント（アイドル・イベントを除く）を自動的に順序付けし、相対的なパーセンテージを計算します。
Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Call Time -------------------------------------- ------------ ----------- --------- CPU time 559 88.80 log file parallel write 2,181 28 4.42 SQL*Net more data from client 516,611 27 4.24 db file parallel write 13,383 13 2.04 db file sequential read 563 2 .27
状況によっては、同程度のパーセンテージを持つイベントがいくつか存在する場合があります。このため、すべてのイベントが同じタイプのリソース要求（たとえば、すべてがI/O関連イベント）に関連している場合に、追加の証拠を提供できます。
Avg Total Wait wait Waits Event Waits Timeouts Time (s) (ms) /txn --------------------------- --------- --------- ---------- ------ --------- log file parallel write 2,181 0 28 13 41.2 SQL*Net more data from clie 516,611 0 27 0 9,747.4 db file parallel write 13,383 0 13 1 252.5
V$SYSSTATやオペレーティング・システム統計などにある、負荷のプロファイル関連のデータが含まれています。他のデータとのクロスチェックを行って、展開中の理論を肯定または否定します。
表10-1に、待機イベントと考えられる原因との関連付けの他、次に検討するのに最も有益と思われるOracleデータの概要を示します。
また、Oracle Metalinkでbuffer busy waits（34405.1）およびfree buffer waits（62172.1）に関する次の通知も確認する必要があります。
これらの通知および関連通知にアクセスするには、次のURLで「busy buffer waits」と「free buffer waits」を検索する方法もあります。
http://metalink.oracle.com
|
関連項目:
|
対応する待機イベントを持たないパフォーマンスの問題を示すことのできる統計は多数あります。
V$SYSSTAT統計のredo log space requestsは、サーバー・プロセスがREDOログ・バッファ内の領域を待機するのではなく、オンラインREDOログ内の領域を待機する必要があった回数を示します。この統計と待機イベントの大きい値は、LGWRではなく、チェックポイント、DBWR、アーカイバ・アクティビティをチューニングする必要があることの標識として使用する必要があります。ログ・バッファのサイズを増やしても効果がありません。
システムは、一貫したビューを維持するために、ブロックの変更内容のロールバックに長時間を費やすことがあります。次の状況を考慮してください。
V$SYSSTAT統計を比較して、変化が発生しているかどうかを判断します。
次のV$SYSSTAT統計の比率は、1に近い値であることが必要です。
ratio = transaction tables consistent reads - undo records applied / transaction tables consistent read rollbacks
解決策は、自動UNDO管理を使用することをお薦めします。
WAITS数をV$ROLLSTAT内のGETS数と比較する方法。GETSに対するWAITSの比率は小さい値である必要があります。
V$WAITSTATを調べて、CLASS 'undo header'のバッファに対して多数のWAITSがあるかどうかを確認する方法。
解決策は、自動UNDO管理を使用することをお薦めします。
V$SYSSTAT内のtable fetch continued row統計数をチェックして、移行行または連鎖行を検出できます。少数の連鎖行（1%以下）は、システム・パフォーマンスに影響を与える可能性はほとんどありません。ただし、連鎖行のパーセンテージが大きいと、パフォーマンスに影響を与える可能性があります。
ブロック・サイズより大きい行の連鎖は避けられません。そのようなデータについては、ブロック・サイズのより大きい表領域の使用を考慮してください。
ただし、小さい行の場合は、適切な領域パラメータとアプリケーション設計を使用することで連鎖を回避できます。たとえば、キー値が入力され、かつその他のほとんどの列がNULLである行を、実際のデータで更新しないでください。その行のサイズが大きくなります。その場合は初めからデータが入力された行を挿入します。
UPDATE文が行のデータ量を増やし、行がそのデータ・ブロックに収まらなくなった場合、Oracleは行全体を保持するのに十分な空き領域を持つ別のブロックを見つけようとします。そのようなブロックが利用可能であれば、Oracleは新しいブロックへ行全体を移動します。これを行の移行と呼びます。行が大きすぎて利用可能なブロックに収まらない場合、Oracleはその行を複数の断片に分割し、各断片を別々のブロックに格納します。これを行の連鎖と呼びます。行は挿入時にも連鎖される可能性があります。
移行と連鎖は、特に次の場合のパフォーマンスに影響があります。
サンプルの出力表CHAINED_ROWSの定義が、配布媒体上の使用可能なSQLスクリプトに収録されています。このスクリプトの一般的な名前はUTLCHN1.SQLですが、正確な名前と位置は使用しているプラットフォームによって異なります。出力表は、CHAINED_ROWS表と同じ列名、データ型およびサイズである必要があります。
移行行を回避するには、PCTFREEを増やします。ブロック内に使用可能な空き領域を多く残しておくと、行の拡張に対処できます。削除割合が高い表と索引を再編成すなわち再作成することもできます。頻繁に行が削除される表の場合は、データブロックに部分的に空き領域が生じることがあります。行を挿入し後から拡張する場合、行の削除されたブロックにその行が挿入されることがありますが、拡張の余地はありません。表を再編成すると主な空き領域を完全に空のブロックにできます。
アプリケーションの解析が長くなるほど、競合の可能性が高くなり、システムの待機時間が長くなります。parse time CPU（CPU解析時間）がCPUタイムの大半を占める場合、SQL文の実行ではなく解析に時間が消費されています。この場合には、アプリケーションはリテラルSQLを使用しているためにSQLを共有できないか、または共有プールの構成が適切でないことがあります。
Oracleによる解析に費やす時間の範囲を識別するために、多数の統計が利用できます。V$SYSSTATから解析関連の統計の問合せを行います。 たとえば、次のようにします。
SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ( 'parse time cpu', 'parse time elapsed', 'parse count (hard)', 'CPU used by this session' );
解析が問題となるかどうかの判断を助けるために計算される、様々な比率があります。
この比率は、解析に費やされる時間のうちのどのくらいが、ラッチなどのリソースに対する待機ではなく、解析操作自体によるものかを示します。比率1は良好であり、経過時間が競合率の高いリソースを待機するために費やされなかったことを示します。
この比率は、Oracleサーバー・プロセスで使用されるCPU全体のうちのどのくらいが解析関係の操作で費やされたかを示します。0（ゼロ）に近い値ほど良好であり、CPUの大部分が解析に費やされないことを示します。
V$SESSION、V$SESSION_WAIT、V$SESSION_EVENTおよびV$SYSTEM_EVENTの各ビューは、どのようなリソースを待機したかに関する情報を表示し、構成パラメータTIMED_STATISTICSがtrueに設定されている場合は、各リソースを待機した時間に関する情報も表示されます。
|
関連項目:
|
パフォーマンス・チューニングを実行するときに、待機イベントと関連するタイミング・データを調査します。最大時間がリストされるイベントは、多くの場合、パフォーマンス・ボトルネックを顕著に示しています。
次の各ビューには、同じデータの関連する（ただし、異なる）ビューが含まれています。
V$SESSIONは、各現行セッションのセッション情報をリストします。このビューには、現在待機されているイベントか、各セッションで最後に待機されたイベントがリストされます。また、このビューには、セッションのブロックの情報も含まれます。
V$SESSION_WAITは、現在の状態ビューです。このビューには、現在待機されているイベントか、各セッションで最後に待機されたイベントがリストされます。
V$SESSION_EVENTは、各セッションで待機されるイベントの累積履歴をリストします。セッションが終了した後、そのセッションに対する待機イベント統計はこのビューから削除されます。
V$SYSTEM_EVENTは、インスタンスの起動以降にインスタンス全体（すなわち、ロールアップされた、すべてのセッション待機イベント・データ）により待機されるイベントと回数をリストします。
V$SESSION_WAITは現在の状態ビューであるため、V$SESSION_EVENTまたはV$SYSTEM_EVENTよりも細かい単位の情報も含まれています。このビューには、P1、P2およびP3の3つのパラメータ列で現行イベントの追加識別データが含まれています。
たとえば、V$SESSION_EVENTはセッション124（SID=124）がdb file scattered readで多く待機していたことを示すことはできますが、どのファイルとブロック番号かは示しません。ただし、V$SESSION_WAITはP1内のファイル番号、P2内に読み込まれたブロック番号およびP3内に読み込まれたブロック数を示します（P1とP2により待機イベントがどのセグメントに対して発生するかを判断できます）。
この章では、V$SESSION_WAITの使用例を中心に説明します。ただし、時間間隔のパフォーマンス・データの収集と、パフォーマンスおよび容量分析のためにこのデータを保存することをお薦めします。この形式のロールアップ・データの問合せは、自動ワークロード・リポジトリによりV$SYSTEM_EVENTビューから行います。「自動ワークロード・リポジトリの概要」を参照してください。
最も一般的に発生するイベントについては、この章で、大/小文字を区別するアルファベット順にリストして説明します。調べる対象の他のイベント関連データも含まれています。各イベント名に使用する大/小文字区別は、V$SYSTEM_EVENTビューでの表示と同一です。
次のイベントは、データベース・プロセスがデータベース・リンクまたはクライアント・プロセスからの確認を待機していることを示します。
これらの待機がシステム上で、または応答時間の問題に対処しているユーザーに対して、待機時間の大部分を占めている場合、ネットワークまたは中間層がボトルネックになる可能性があります。
クライアント関連のイベントは、SQL*Net message from clientイベントで説明したとおりに診断する必要があります。dblink関連のイベントは、SQL*Net message from dblinkイベントで説明したとおりに診断する必要があります。
これはアイドル・イベントですが、このイベントを診断に使用できるときに何が問題でないかを説明することが重要です。このイベントは、サーバー・プロセスがクライアント・プロセスからの処理を待機していることを示します。ただし、このイベントが、長い応答時間を経験しているユーザーの待機時間の大半を生成している状況がいくつかあります。その原因は、ネットワーク・ボトルネックまたはクライアント・プロセスでのリソース・ボトルネックのいずれかである可能性があります。
ネットワーク・ボトルネックは、アプリケーションによってサーバーとクライアントとの間で多量の通信が発生し、ネットワークの待機時間（ラウンドトリップの時間）が長い場合に発生する可能性があります。症状には次のものがあります。
ネットワーク・ボトルネックを軽減するには、次のことを試行します。
VSATリンクとは反対の地上回線）を探索します。
クライアント・プロセスがリソースの大半を使用している場合、データベース内で実行できることはありません。症状には次のものがあります。
場合によっては、クライアント・プロセスで使用されるCPUの量により、待機しているユーザーのトラッキングのための待機時間がわかります。この場合のクライアントという用語は、n層アーキテクチャにおける、データベース・プロセス（中間層、デスクトップ・クライアント）以外の任意のプロセスを指します。
このイベントは、セッションがリモート・ノードにメッセージを送り、データベース・リンクからの応答を待機している状態であることを意味します。この時間は、次の理由で増える可能性があります。
詳細は、「SQL*Net message from client」を参照してください。
リモート・ノードで実行されているSQLを確認することが有益です。リモート・データベースにログインし、データベース・リンクで作成されたセッションを検索し、そのセッションで実行されるSQL文を調べます。
セッションとリモート・ノード間の各メッセージにより、遅延時間が長くなり、処理オーバーヘッドが増加します。交換されるメッセージの数を減らすには、配列フェッチと配列挿入を使用します。
サーバー・プロセスは、クライアントにさらに多くのデータまたはメッセージを送信します。クライアントに対する以前の操作も送信されました。
この待機は、複数のプロセスが同時にアクセスしようとしているバッファ・キャッシュ内に、いくつかのバッファがあることを示しています。バッファのクラスごとに、待機統計についてV$WAITSTATを問い合せます。buffer busy waitsを持つ共通のバッファ・クラスとして、data block、segment header、undo headerおよびundo blockなどがあります。
次のV$SESSION_WAITパラメータ列をチェックします。
考えられる原因を判別するには、最初にV$SESSIONを問い合せて、セッションがbuffer busy waitsを待機しているときのROW_WAIT_OBJ#の値を識別します。 たとえば、次のようにします。
SELECT row_wait_obj# FROM V$SESSION WHERE EVENT = 'buffer busy waits';
競合対象のオブジェクトとオブジェクト型を識別するには、V$SESSIONから戻されるROW_WAIT_OBJ#の値を使用してDBA_OBJECTSを問い合せます。 たとえば、次のようにします。
SELECT owner, object_name, subobject_name, object_type FROM DBA_OBJECTS WHERE data_object_id = &row_wait_obj;
必要な処置は、競合対象のクラスと実際のセグメントにより異なります。
競合がセグメント・ヘッダー上にある場合、これは最も起こりうる空きリストの競合です。
ローカルに管理されている表領域で自動セグメント領域管理を行えば、PCTUSED、FREELISTSおよびFREELIST GROUPSの各パラメータを指定する必要はありません。可能であれば、手動領域管理から自動セグメント領域管理（ASSM）に切り替えます。
自動セグメント領域管理を使用できない（たとえば、表領域でディクショナリ領域管理を使用している）場合は、次の情報が関係します。
空きリストは、通常セグメントの様々なエクステント内に存在するブロックを含む空きデータ・ブロックのリストです。空きリストは、空き領域がPCTFREEに達していないブロック、または使用済領域がPCTUSEDを下回っているブロックで構成されます。FREELISTSパラメータでプロセスの空きリスト数を指定します。FREELISTSのデフォルト値は1です。最大値はデータ・ブロック・サイズによって決まります。
そのセグメントの空きリストに対する現在の設定を見つけるには、次を実行します。
SELECT SEGMENT_NAME, FREELISTS FROM DBA_SEGMENTS WHERE SEGMENT_NAME = segment name AND SEGMENT_TYPE = segment type;
空きリスト、または空きリスト数の増分を設定します。さらに空きリストを追加しても問題が軽減されない場合は、空きリスト・グループを使用します（このようにすると、単一のインスタンス内でも違いが出る可能性があります）。Oracle Real Application Clustersを使用する場合は、インスタンスごとに独自の空きリスト・グループを持っていることを確認します。
表または索引（セグメント・ヘッダーではない）に対する競合がある場合、次のようにします。
ロールバック・セグメント・ヘッダーに対する競合の場合
ロールバック・セグメント・ブロックに対する競合の場合
このイベントは、ユーザー・プロセスがSGA内のバッファ・キャッシュにバッファを読み取り、物理I/Oコールが戻るまで待機することを意味します。db file scattered readは、データを複数の不連続メモリー位置に読み取るために散布読取りを発行します。散布読取りは通常、マルチブロック読取りです。全体スキャンの他、（索引の）高速全スキャンでも行うことができます。
db file scattered read待機イベントは、全体スキャンが発生していることを識別します。バッファ・キャッシュへの全体スキャンを実行すると、読み取られたブロックは物理的に相互に接近していないメモリー位置に読み取られます。そのような読取りが散布読取りコールと呼ばれるのは、ブロックがメモリー全体に分散されているからです。対応する待機イベントが「db file scattered read（DBファイル散布読取り）」と呼ばれるのは、このためです。バッファ・キャッシュへの全体スキャンのためのマルチブロック（最大でDB_FILE_MULTIBLOCK_READ_COUNTブロック）読取りは、db file scattered readに対する待機として現れます。
次のV$SESSION_WAITパラメータ列をチェックします。
健全なシステムでは、物理読込み待機がアイドル待機後の最大待機である必要があります。ただし、小さい索引付きアクセスを行う必要のある運用（OLTP）システム上に、ダイレクト読込み待機（パラレル問合せを持つ全表スキャンを意味する）またはdb file scattered read待機があるかどうかも確認してください。
システム上の過剰なI/O負荷を示す他の要素として、次のものがあります。
過剰なI/O待機を処理する方法はいくつかあります。有効性の順に示すと、これらの方法は次のとおりです。
DBMS_STATSパッケージを使用したシステム統計の収集。これにより、問合せオプティマイザでは、全体スキャンを使用する、可能なアクセス・パスのコストを正確に計算できます。
最初に行うことは、I/Oを削減するためのチャンスを見つけることです。これらのイベントを待機するセッションを実行してSQL文の調査を開始し、V$SQLAREAから多数の物理I/Oを実行する文を調べます。過剰なI/Oを実行し、実行計画にマイナスの影響を与える可能性のある要因として、次のものがあります。
DB_FILE_MULTIBLOCK_READ_COUNT初期化パラメータの設定値が全体スキャンには大きすぎること
I/Oを削減する他、ディスク間のファイルのI/O分散も調べます。I/Oはディスク間に均等に分散されていますか、あるいは、いくつかのディスク上にホット・スポットがありますか?データベースのI/Oリクエストを満たすだけの十分な個数のディスクがありますか?
データベースによるI/O操作（読込みと書込み）の総数を調べ、それと使用したディスク数を比較します。必ず、LGWRプロセスとARCHプロセスのI/Oアクティビティを含めてください。
次の問合せを使用して、ある時点でどのセッションがI/Oを待機しているかを判断します。
SELECT SQL_ADDRESS, SQL_HASH_VALUE FROM V$SESSION WHERE EVENT LIKE 'db file%read';
考えられる原因を判別するには、最初にV$SESSIONを問い合せて、セッションがdb file scattered readを待機しているときのROW_WAIT_OBJ#の値を識別します。 たとえば、次のようにします。
SELECT row_wait_obj# FROM V$SESSION WHERE EVENT = 'db file scattered read';
競合対象のオブジェクトとオブジェクト型を識別するには、V$SESSIONから戻されるROW_WAIT_OBJ#の値を使用してDBA_OBJECTSを問い合せます。 たとえば、次のようにします。
SELECT owner, object_name, subobject_name, object_type FROM DBA_OBJECTS WHERE data_object_id = &row_wait_obj;
このイベントは、ユーザー・プロセスがSGA内のバッファ・キャッシュにバッファを読み取り、物理I/Oコールが戻るまで待機することを意味します。順次読取りは、単一ブロック読取りです。
単一ブロックI/Oは通常、索引を使用した結果です。エクステント境界のため、すなわち、バッファがすでにバッファ・キャッシュ内に存在するために全表スキャン・コールが単一ブロック・コールに切り捨てられることはほとんどありません。これらの待機は、'db file sequential read'としても表示されます。
次のV$SESSION_WAITパラメータ列をチェックします。
健全なシステムでは、物理読込み待機がアイドル待機後の最大待機である必要があります。ただし、パラレル問合せを持つ、全表スキャンに近いスキャンの必要な大きいデータ・ウェアハウス上に、db file sequential readsがあるかどうかも確認してください。
図10-1は、次の待機イベント間の違いを示したものです。
db file sequential read（1つのSGAバッファに読み込まれる単一ブロック）
db file scattered read（多数の不連続SGAバッファに読み込まれるマルチブロック）
direct read（PGAへの単一またはマルチブロック読込み、SGAのバイパス）
あるセッションがバッファをディスクからPGAに直接読み込む（SGA内のバッファ・キャッシュとは反対）場合、このイベント上で待機します。I/Oサブシステムが非同期I/Oをサポートしない場合、各待機は物理読込み要求に対応します。
I/Oサブシステムが非同期I/Oをサポートする場合、このプロセスでは読込み要求の発行を、PGAにすでに存在するブロックの処理に重複させることができます。プロセスがディスクからまだ読み込まれていないPGA内のブロックにアクセスしようとする場合、待機コールを発行し、このイベントの統計を更新します。したがって、待機数は必ずしも読込み要求数と同じではありません（db file scattered readおよびdb file sequential readとは異なります）。
次のV$SESSION_WAITパラメータ列をチェックします。
これは次の状況で発生します。
file_idは、読込みがTEMP表領域内のオブジェクトに対するものか、パラレル・スレーブによる全表スキャンに対するものかを示します。これは、大きいデータ・ウェアハウス・サイトに対する最大待機です。ただし、ワークロードがDSSワークロードではない場合は、これが発生している理由を調べます。
待機が発生しているセッションで、現在実行されているSQL文を調べて、ソートの原因を確認します。ソートを生成するSQL文を検索するために、V$TEMPSEG_USAGEを問い合せます。また、ソートのサイズを決定するセッションに関するV$SESSTATからの統計を問い合せます。SQL文をチューニングしてソートを削減できるかどうかを確認します。WORKAREA_SIZE_POLICYがMANUALである場合、システム（ソートが大きすぎない場合）または個々のプロセスのSORT_AREA_SIZEを大きくすることを検討します。WORKAREA_SIZE_POLICYがAUTOである場合、PGA_AGGREGATE_TARGETを大きくするかどうかを調べます。「PGAメモリー管理」を参照してください。
高い並列度で表を定義すると、全表スキャンをパラレル・スレーブで検索するようにオプティマイザを偏らせることができます。ダイレクト・パス読取りを使用して読み取るオブジェクトをチェックします。全表スキャンがワークロードの有効な部分である場合は、I/Oサブシステムが並列度に対して適切に構成されているかどうかを確認します。ディスクのストライプ化または自動ストレージ管理（ASM）を使用していない場合は、ディスクのストライプ化を使用することを考慮してください。
ハッシュ結合を呼び出す問合せ計画の場合、過剰なI/OはHASH_AREA_SIZEが小さすぎることから発生する可能性があります。WORKAREA_SIZE_POLICYがMANUALである場合、システムまたは個々のプロセスのHASH_AREA_SIZEを大きくすることを検討してください。WORKAREA_SIZE_POLICYがAUTOである場合、PGA_AGGREGATE_TARGETを大きくするかどうかを調べます。
プロセスがバッファをPGAから直接書き込む（バッファ・キャッシュからバッファを書き込むDBWRとは反対）場合、プロセスは書込みコールが完了するまでこのイベント上で待機します。ダイレクト・パス書込みを実行できる操作には、ソートがディスクに移動するとき、パラレルDML操作時、ダイレクト・パスINSERT、パラレル作成表の選択時、およびいくつかのLOB操作があります。
ダイレクト・パス読込みと同様に、I/Oサブシステムが非同期書込みをサポートする場合、待機数は発行された書込みコール数と同じではありません。セッションがPGA内のすべてのバッファを処理し、I/Oリクエストが完了するまで作業を継続できない場合、セッションは待機します。
次のV$SESSION_WAITパラメータ列をチェックします。
これは次の状況で発生します。
大規模なソートについては、「ディスクでのソート」を参照してください。
パラレルDMLについては、ディスク間のI/O分散をチェックし、I/Oサブシステムが並列度の大きさに対して適切に構成されているかどうかを確認してください。
エンキューは、データベース・リソースへのアクセスを調整するロックです。このイベントは、セッションが別のセッションで保持されているロックを待機していることを示します。
エンキュー名は待機イベント名の一部としてenq: enqueue_type - related_details形式で含まれています。次の関連TXタイプなど、同じエンキュー・タイプを異なる目的で保持できる場合があります。
enq: TX - allocate ITL entry
enq: TX - contention
enq: TX - index contention
enq: TX - row lock contention
V$EVENT_NAMEビューには、すべてのenq:待機イベントのリストが表示されます。
次のV$SESSION_WAITパラメータ列で追加情報を確認できます。
ロックを保持するセッションを見つけるには、V$LOCKの問合せを行います。イベント・エンキューを待機するすべてのセッションでは、REQUEST <> 0を持つV$LOCK内に行があります。次の2つの問合せのうちの1つを使用して、ロックを保持しているセッションとロックを待機しているセッションを検索します。
エンキュー待機がある場合は、次の文を使用することによりこれらを確認できます。
SELECT * FROM V$LOCK WHERE request > 0;
待機中のロックのホルダーおよびウェイタのみを表示するには、次の文を使用します。
SELECT DECODE(request,0,'Holder: ','Waiter: ') || sid sess, id1, id2, lmode, request, type FROM V$LOCK WHERE (id1, id2, type) IN (SELECT id1, id2, type FROM V$LOCK WHERE request > 0) ORDER BY id1, request;
適切な処置は、エンキューのタイプにより異なります。
競合されたエンキューがSTエンキューである場合、問題は動的な領域割当てにある可能性が最も高いと言えます。セグメントにそれ以上空き領域がない場合、Oracleはセグメントにエクステントを動的に割り当てます。このエンキューは、ディクショナリ管理表領域にのみ使用します。
このリソースに対する競合を解決するには、次のようにします。
TEMPFILESを使用するかどうかを確認します。使用しない場合は、TEMPFILESを使用するように切り替えます。
SEGMENT_NAMEについてDBA_SEGMENTSビューのEXTENTS列を監視します。領域使用情報の表示の詳細は、『Oracle Database管理者ガイド』を参照してください。
ALTER TABLE ALLOCATE EXTENT SQL文でエクステントを割り当てる方法などです。
HWエンキューは、セグメントの最高水位標を超える領域の割当てをシリアライズする場合に使用します。
V$SESSION_WAIT.P2 / V$LOCK.ID1は表領域番号です。
V$SESSION_WAIT.P3 / V$LOCK.ID2は、領域が割り当てられるオブジェクトのセグメント・ヘッダーの相対DBAです。
これがオブジェクトの競合点である場合、エクステントの手動割当てにより問題が解決されます。
TMロック上の待機の最も一般的な理由は、制約される列が索引付けされない場合の外部キー制約に関係している傾向があります。この問題を回避するには、外部キー列を索引付けします。
これらのロックは、トランザクションがその最初の変更を開始するときに排他的に取得され、トランザクションがCOMMITまたはROLLBACKを行うまで保持されます。
enq: TX - row lock contentionに対応します。解決方法は、ロックをすでに保持している最初のセッションにCOMMITまたはROLLBACKを実行させることです。
enq: TX - allocate ITL entryに対応します。解決方法は、表のINITRANSまたはMAXTRANSを変更する（ALTER文を使用するか、それより高い値で表を再作成する）ことによって使用可能なITLの個数を増やすことです。
UNIQUE索引内の潜在的な重複のためにセッションが待機している場合にも発生します。2つのセッションが同じキー値を挿入しようとする場合、第2のセッションはORA-0001が発生したかどうかを確認するまで、待機する必要があります。このタイプのエンキュー待機は、待機イベントenq: TX - row lock contentionに対応します。解決方法は、ロックをすでに保持している最初のセッションにCOMMITまたはROLLBACKを実行させることです。
COMMITまたはROLLBACKを待機します。このタイプのTXエンキュー待機は、待機イベントenq: TX - row lock contentionに対応します。
PREPAREDトランザクションを待機している場合にも発生する可能性があります。
enq: TX - index contentionに対応します。このイベントは、「その他」の待機クラスに属し、通常はシステムで発生しないようにしてください。このイベントは、latch freeなど、「その他」の待機クラスのその他すべてのイベントの集計であり、V$SESSION_EVENTおよびV$SERVICE_EVENTビューでのみ使用されます。これらのビューでは、「その他」待機クラスのイベントは、セッションごとにはメンテナンスされません。かわりに、この1つのイベントにロール・アップされ、「その他」待機クラスのイベント統計をメンテナンスするためのメモリーを削減します。
この待機イベントは、サーバー・プロセスが空きバッファを検索できず、使用済バッファを書き出すことによって空きバッファを作成するためにデータベース・ライターを転送したことを示します。使用済バッファは、内容が変更されたバッファです。使用済バッファは、DBWRがブロックをディスクに書き込み終えると、再利用するために解放されます。
DBWRは、次の状況では使用済バッファの書込みを継続できない場合があります。
このイベントが頻繁に発生する場合は、DBWRに対するセッション待機を調べて、DBWRを遅らせる原因があるかどうかを確認してください。
セッションが書込みを待機している場合は、書込みを遅らせている原因を解明し、修正してください。次の点をチェックします。
I/Oが低速である場合は、次のようにしてください。
キャッシュが小さすぎるためにDBWRが非常にアクティブである可能性があります。バッファ・キャッシュ・ヒット率が低いかどうかを確認して、これが考えられる原因であるかどうかを調べます。また、V$DB_CACHE_ADVICEビューを使用して、それより大きいキャッシュ・サイズが有利かどうかを判断します。「バッファ・キャッシュのサイズ設定」を参照してください。
キャッシュ・サイズが適切であり、I/Oがすでに均等に分散されている場合は、非同期I/Oを使用するか、複数のデータベース・ライターを使用して、DBWRの動作を修正できます。
複数のデータベース・ライター・プロセスを構成したり、I/Oスレーブを使用するのは、トランザクション・レートが高い場合や、バッファ・キャッシュ・サイズが大きすぎて単一のDBWnプロセスが負荷に耐えられない場合に役立ちます。
DB_WRITER_PROCESSES初期化パラメータを使用すると、複数のデータベース・ライター・プロセス（DBW0からDBW9までと、DBWaからDBWj）を構成できます。複数のDBWRプロセスを構成すると、書き込まれるバッファの識別に必要な作業が分散され、また、これらのプロセス間にI/O負荷もが分散されます。複数のデータベース・ライター・プロセスは、複数のCPUを持つシステム（CPU 8つにつき最低1つのデータベース・ライター）や、複数のプロセッサ・グループを持つシステム（最低でプロセス・グループと同数のデータベース・ライター）にお薦めします。
CPUの数またはプロセッサ・グループの数に基づいて、Oracleは、適切なDB_WRITER_PROCESSESのデフォルト設定を選択するか、ユーザー定義の設定を調整します。
複数のDBWRプロセスを使用することが実用的ではない場合、Oracleには複数のスレーブ・プロセス間にI/O負荷を分散できる機能があります。DBWRプロセスは、ブロックを書き出すためにバッファ・キャッシュLRUリストをスキャンする唯一のプロセスです。ただし、これらのブロックのI/OはI/Oスレーブで実行されます。I/Oスレーブの個数は、DBWR_IO_SLAVESパラメータで決定されます。
DBWR_IO_SLAVESは、（CPUが1つの場合など）複数のDB_WRITER_PROCESSESを使用できない場合を想定しています。I/Oスレーブは、非同期I/Oが使用できないときにも役立ちます。書き込まれるキャッシュ内のブロックの識別を継続するためにDBWRを解放することによって、複数のI/Oスレーブが非ブロッキング要求をシミュレートするからです。一般的に、非同期I/Oがある場合、オペレーティング・システム・レベルの非同期I/Oをお薦めします。
DBWRのI/Oスレーブは、初回のI/Oリクエストが実行されるときに、データベースが開いた直後に割り当てられます。DBWRは、I/Oの実行とは別に、DBWR関連のすべての作業の実行を継続します。I/Oスレーブは単に、DBWRのためにI/Oを実行します。バッチの書込みはI/Oスレーブ間でパラレル化されます。
複数のDBWRプロセスを構成すると、単一のDBWRプロセスが、必要なワークロードに耐えられないときのパフォーマンスに有益です。ただし、複数のDBWRプロセスを構成する前に、非同期I/Oが使用でき、システム上に構成されるかどうかを確認します。システムが非同期I/Oをサポートしても現在使用されていない場合は、複数のDBWRプロセスを構成すると問題が軽減されるかどうかを確認するために非同期I/Oを使用可能にします。システムが非同期I/Oをサポートしない場合、または非同期I/Oがすでに構成され、DBWRボトルネックが依然として存在する場合は、複数のDBWRプロセスを構成します。
複数のDBWRを使用すると、バッファの収集と書込みがパラレル化されます。そのため、複数のDBWnプロセスは同じ数のI/Oスレーブを使用する1つのDBWRプロセスよりもスループットを向上します。このため、複数のDBWRプロセスを優先して、I/Oスレーブは使用されなくなりました。I/Oスレーブは、複数のDBWRプロセスを構成できない場合のみ使用してください。
ラッチは、メモリー構造を保護するためにOracleで使用される下位レベルの内部ロックです。ラッチ解放イベントは、サーバー・プロセスがラッチを取得しようとしたときに更新され、ラッチは最初の試行で使用できなくなります。
通常は大きな競合を生成する一般的なラッチ用に、専用のラッチ関連待機イベントがあります。これらのイベントの場合は、latch: library cacheまたはlatch: cache buffers chainsのように、ラッチ名が待機イベント名に含まれます。このため、ラッチに関連するほとんどの競合の原因が特定のタイプのラッチであるかどうかをすばやく確認できます。他のすべてのラッチの待機は、汎用のlatch free待機イベントにグループ化されています。
このイベントは、ラッチ待機がシステム上の待機時間全体の重要な部分である場合か、または問題が発生している個々のユーザーに対してのみかを考慮してください。
次のV$SESSION_WAITパラメータ列をチェックします。
SELECT EVENT, SUM(P3) SLEEPS, SUM(SECONDS_IN_WAIT) SECONDS_IN_WAIT FROM V$SESSION_WAIT WHERE EVENT LIKE 'latch%' GROUP BY EVENT;
前述の問合せには、インスタンスまたは長期的なインスタンスのチューニングよりも、セッションのチューニングまたは短期的なインスタンスのチューニングに関して多くの情報が示されるという問題があります。
次の問合せは長期的なインスタンス・チューニングの詳細情報を提供し、ラッチの待機がデータベース全体の時間に占める割合が大きいかどうかを示します。
SELECT EVENT, TIME_WAITED_MICRO, ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME FROM V$SYSTEM_EVENT, (SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S WHERE EVENT LIKE 'latch%' ORDER BY PCT_DB_TIME ASC;
ラッチ待機固有でない、より汎用的な問合せは次のようになります。
SELECT EVENT, WAIT_CLASS, TIME_WAITED_MICRO,ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME FROM V$SYSTEM_EVENT E, V$EVENT_NAME N, (SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S WHERE E.EVENT_ID = N.EVENT_ID AND N.WAIT_CLASS NOT IN ('Idle', 'System I/O') ORDER BY PCT_DB_TIME ASC;
共有プールまたはライブラリ・キャッシュ・ラッチの競合の主な原因は解析です。不要な解析および不要な解析の様々なタイプの識別に使用できる手法は多数あります。
この方法では、リテラルがバインド変数と置換された場合に共有できる類似したSQL文を識別します。その概念は次のいずれかです。
SELECT SQL_TEXT FROM V$SQLSTATS WHERE EXECUTIONS < 4 ORDER BY SQL_TEXT;
SELECT SUBSTR(SQL_TEXT, 1, 60), COUNT(*) FROM V$SQLSTATS WHERE EXECUTIONS < 4 GROUP BY SUBSTR(SQL_TEXT, 1, 60) HAVING COUNT(*) > 1;
SELECT SQL_TEXT FROM V$SQLSTATS WHERE PLAN_HASH_VALUE IN (SELECT PLAN_HASH_VALUE FROM V$SQLSTATS GROUP BY PLAN_HASH_VALUE HAVING COUNT(*) > 4) ORDER BY PLAN_HASH_VALUE;
V$SQLSTATSビューをチェックします。次の問合せを入力してください。
SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLSTATS ORDER BY PARSE_CALLS;
PARSE_CALLSの値が指定の文のEXECUTIONS値に近い場合は、その文の再解析を継続できます。解析コールが多い文をチューニングします。
不要な解析コールが発生しているセッションを識別して、不要なコールを識別します。特定のバッチ・プログラムやある種のアプリケーションがほとんどの再解析を行っている場合があります。これを行うには、次の問合せを実行します。
SELECT pa.SID, pa.VALUE "Hard Parses", ex.VALUE "Execute Count" FROM V$SESSTAT pa, V$SESSTAT ex WHERE pa.SID = ex.SID AND pa.STATISTIC#=(SELECT STATISTIC# FROM V$STATNAME WHERE NAME = 'parse count (hard)') AND ex.STATISTIC#=(SELECT STATISTIC# FROM V$STATNAME WHERE NAME = 'execute count') AND pa.VALUE > 0;
結果として、すべてのセッションおよびリストとセッションで実行された解析の量が得られます。セッション識別子（SID）ごとに、V$SESSIONで、再解析の原因となっているプログラムの名前を検索します。
出力は、次のようなものです。
SID Hard Parses Execute Count ------ ----------- ------------- 7 1 20 8 3 12690 6 26 325 11 84 1619
cache buffers lru chainラッチは、キャッシュ内のバッファのリストを保護します。リストからバッファの追加、移動または削除を行う場合、ラッチを取得する必要があります。
対称型マルチプロセッサ（SMP）システムでは、Oracleによって、LRUラッチの数がシステムのCPU数の2分の1に等しい値になるように自動的に設定されます。非SMPシステムでは、LRUラッチは1つあれば十分です。
LRUラッチの競合は、多数のCPUを備えたSMPシステムでのパフォーマンスを低下させることがあります。LRUラッチの競合は、V$LATCH、V$SESSION_EVENTおよびV$SYSTEM_EVENTに問い合せることによって検出できます。競合を回避するには、アプリケーションのチューニング、DSSジョブのバッファ・キャッシュのバイパスまたはアプリケーションの再設計を検討してください。
cache buffers chainsのラッチは、バッファ・キャッシュでバッファ・リストを保護する場合に使用します。これらのラッチは、バッファの検索、追加、およびバッファ・キャッシュからバッファを削除する場合に使用します。このラッチの競合は、競合度の高い（ホットな）ブロックが存在することを意味します。
頻繁にアクセスされるバッファ連鎖を識別し、競合するブロックを識別するには、V$LATCH_CHILDRENビューを使用してcache buffers chainsのラッチのラッチ統計を調べます。他の子ラッチと比較して、多くのGETS、MISSESおよびSLEEPSを持つ特定のcache buffers chainsの子ラッチがある場合、これは子ラッチで競合します。
このラッチには、ADDR列で識別されるメモリー・アドレスがあります。このラッチで保護されているブロックを識別するには、X$BH表と結合されたADDR列の値を使用します。たとえば、頻繁に競合するラッチのアドレス（V$LATCH_CHILDREN.ADDR）を指定すると、ファイル番号とブロック番号の問合せが作成されます。
SELECT OBJ data_object_id, FILE#, DBABLK,CLASS, STATE, TCH FROM X$BH WHERE HLADDR = 'address of latch' ORDER BY TCH;
X$BH.TCHは、バッファのタッチ・カウントです。X$BH.TCHの値が高い場合は、ホット・ブロックであることを示します。
各ラッチで保護されるブロックは多数あります。これらのバッファのうちの1つは、ホット・ブロックであると考えられます。TCH値の高いブロックは、潜在的なホット・ブロックです。この問合せを複数回実行し、出力に一貫して表示されるブロックを識別します。ホット・ブロックを識別した後は、ファイル番号とブロック番号を使用してDBA_EXTENTSの問合せを行い、セグメントを識別します。
ホット・ブロックの識別後に、次の問合せを使用してそのホット・ブロックが属するセグメントを識別できます。
SELECT OBJECT_NAME, SUBOBJECT_NAME FROM DBA_OBJECTS WHERE DATA_OBJECT_ID = &obj;
この問合せで&objは、X$BHへの前述の問合せにおけるOBJ列の値です。
row cache objectsラッチは、データ・ディクショナリを保護します。
このイベントには、ログ・バッファからREDOログ・ファイルへのREDOレコードの書込みが含まれます。
このイベントでは、ライブラリ・キャッシュの同時実行性を管理します。オブジェクトが確保されると、ヒープがメモリーへロードされます。クライアントがオブジェクトを修正または調査する場合、クライアントはロック後にPINを取得する必要があります。
このイベントは、ライブラリ・キャッシュのクライアント間の同時実行性を制御します。オブジェクト処理のロックが取得され、次のいずれかが可能になります。
また、このロックはライブラリ・キャッシュにオブジェクトを配置するためにも取得されます。
このイベントは、サーバー・プロセスがログ・バッファ内の空き領域を待機しているときに発生します。これは、LGWRがREDOを書き出すよりも、すべてのREDOが生成される方が速いためです。
REDOログ・バッファ・サイズを修正します。ログ・バッファのサイズがすでに適切なものである場合、オンラインREDOログが存在するディスクがI/O競合を受けないようにします。log buffer space待機イベントは、REDOログが存在するディスク上のディスクI/O競合を示しているか、小さすぎるログ・バッファを示している可能性があります。REDOログを含むディスクのI/Oプロファイルをチェックして、I/Oシステムがボトルネックであるかどうかを調べます。I/Oシステムが問題ではない場合、REDOログ・バッファが小さすぎる可能性があります。このイベントが問題にならなくなるまで、REDOログ・バッファのサイズを大きくします。
一般に発生する待機イベントは、次の2つです。
いずれのイベントでも、LGWRは次のオンラインREDOログに切り替えることはできず、すべてのコミット要求はこのイベントを待機します。
log file switch（archiving needed）イベントの場合、アーカイバがタイムリにログをアーカイブできない理由を調べます。次の理由が考えられます。
ボトルネックの性質により、I/Oを再分散したり、アーカイブ先に領域を追加して問題を軽減することが必要な場合があります。log file switch（checkpoint incomplete）イベントの場合、次を実行してください。
ユーザー・セッションがコミットする（またはロールバックする）場合、LGWRでセッションのREDO情報をREDOログ・ファイルにフラッシュする必要があります。COMMITまたはROLLBACKを実行するサーバー・プロセスは、REDOログへの書込みが完了するまで、このイベントで待機します。
このイベントの待機がシステム上での長時間の待機か、応答時間の問題が発生しているユーザーまたはシステム上のユーザーによる長時間の待機を構成している場合は、平均待機時間を調べます。
平均待機時間は短いが、待機数が多い場合、アプリケーションはCOMMITをバッチ処理するのではなく、すべてのINSERT後にコミットできます。アプリケーションは、行ごとではなく50行後にコミットして待機を減らすことができます。
平均待機時間が多い場合は、LGWRに対するセッション待機を調べ、何を実行および待機するために多くの時間を費やしているかを調べます。待機が低速のI/Oによるものである場合は、次のことを試行してください。
COMMITをバッチ処理することで、ログ・ファイルの同期が少なくてすみます。
このイベントは、バックグラウンド・プロセスのうちの1つから応答を待機する場合に使用します。
これらのイベントはIdle待機クラスに属し、作業がないためにサーバー・プロセスが待機中であることを示します。これは通常、ボトルネックが存在する場合にボトルネックがデータベース・リソースに対するものではないことを意味します。チューニングの際、アイドル・イベントの大部分を無視することが必要なのは、アイドル・イベントがパフォーマンス・ボトルネックの性質を示さないためです。アイドル・イベントの中には、ボトルネックでないものを示す際に役立つものがあります。このタイプのイベントの例として、最も一般的に発生するアイドル待機イベントであるSQL Net message from clientがあります。表10-3に、このアイドル・イベントと他のアイドル・イベント（およびそれらのカテゴリ）のリストを示します。
|
 Copyright © 2000, 2008, Oracle Corporation. All Rights Reserved. |
|