| Oracle® Databaseパフォーマンス・チューニング・ガイド 11gリリース2 (11.2) B56312-06 |
|
 前 |
 次 |
この章では、Oracle Databaseのパフォーマンス改善方法について説明します。この章の内容は次のとおりです。
Oracleのパフォーマンス方法論は、Oracleデータベースのパフォーマンス問題の識別に役立ちます。これには、ボトルネックの識別とその修正が含まれます。システムの変更は、ボトルネックの存在を確認した後にのみ行うことをお薦めします。
パフォーマンスの改善は、本質的に反復的なプロセスです。このため、最初のボトルネックを取り除いても、別のボトルネックが明らかになる可能性があり、パフォーマンスがすぐには改善されないことがあります。また、シリアライズ・ポイントが効率の悪い共有メカニズムに移動したことによって、パフォーマンスが低下する場合もあります。経験を重ね、ボトルネックの除去方法に厳密に従うことにより、アプリケーションをデバッグしてスケーラブルにすることができます。
パフォーマンスの問題は、通常、スループットの不足または許容範囲を超えたユーザー/ジョブ・レスポンス時間(あるいはその両方)が原因で発生します。問題は、アプリケーション・モジュール間でローカルに発生する場合も、システム全体にわたる場合もあります。
データベース統計やオペレーティング・システム統計を調べる前に、システムで最も重要なコンポーネントからのフィードバックを取得することが重要です。つまり、システムのユーザーと、アプリケーション・コストを最終的に負担する人々からのフィードバックです。ユーザーからの典型的なフィードバックには、次のような報告が含まれます。
オンライン・パフォーマンスがあまりに低いため、部下が業務を遂行できない。
請求作業にかかる時間が長すぎる。
Webトラフィックが多くなると、レスポンス時間が許容できないほど遅くなり、このままでは顧客を失ってしまう。
現在、1日に5000件の取引を行っているが、システムが限界を超えている。来月は全ユーザーにロールアウトする予定で、取引数は4倍になる見込みである。
このような率直なフィードバックがあると、パフォーマンスの改善作業を成功させる重要な要因を容易に設定できます。パフォーマンスの目標およびパフォーマンス・エンジニアにとっての最終基準を決定することで、パフォーマンス・プロセスの管理がすべてのレベルで簡潔になり円滑に運びます。このような重要な成功要因は、システム統計ではなく現実的なビジネス目標の観点から定義した方が効果的です。
前述した典型的なユーザー・フィードバックに対する実際のビジネス目標を、次にいくつか示します。
請求作業は、3時間で1,000,000件を処理する必要がある。
Webサイトのピーク時に、1回のページ・リフレッシュのレスポンス時間は5秒以内である必要がある。
システムでは、8時間で25,000件の取引を処理可能にする。
最終的な満足度は、システム・パフォーマンスに関するユーザーの認識で判断されます。パフォーマンス・エンジニアの役割は、パフォーマンスを低下させるボトルネックを取り除くことです。ボトルネックの原因としては、限られた共有リソースの非効率的な使用、またはシリアライズの原因となる共有リソースの不適切な使用が考えられます。すべての共有リソースにはかぎりがあるため、パフォーマンス・エンジニアの目標は、共有リソースを効率的に活用して、ビジネス処理件数を最大にすることです。高いレベルでは、データベース・サーバー全体を共有リソースとみなすことができます。逆に、低いレベルでは、1台のCPUやディスクを共有リソースとみなすことができます。
Oracleのパフォーマンス改善方法は、パフォーマンス目標を達成するまで、または目標の達成が不可能と判断されるまで適用できます。これは非常に反復的なプロセスです。必然的に、データベースのパフォーマンスにほとんど影響のない調査も発生します。重大なボトルネックを正確かつ迅速に特定するスキルを開発するには、時間と経験が必要です。ただし、利用できるデータや統計を軽視すると、たとえ経験が豊かな技術者でもその経験が裏目に出ることがあります。このような技術者は、根拠のない思い込みと慣習でデータベースをチューニングしようとします。これは、データベースのチューニング方法としては非常に危険でコストもかかり、成功するとは考えられません。
自動データベース診断モニター(ADDM)は、パフォーマンス改善方法の各部を実装し、統計を分析して、重大なパフォーマンスの問題の自動診断を提供します。ADDMを使用すると、システム・パフォーマンスの改善に伴う所要時間を大幅に短縮できます。ADDMの詳細は、第6章「自動パフォーマンス診断」を参照してください。
システムは多様かつ複雑であるため、パフォーマンス分析における絶対的な規則は不可能です。本質的に、Oracleのパフォーマンス改善方法は、作業の方法を定義するものであり、確定した一連の法則を定義するものではありません。ボトルネックの検出における唯一の法則は、法則がないということです。優れたパフォーマンス・エンジニアは、提供されたデータを利用し、様々な角度から検討してパフォーマンスの問題を判断します。
次に示す初期標準チェックを実行します。
ユーザーから率直なフィードバックを取得します。パフォーマンス・プロジェクトの適用範囲、最終的なパフォーマンス目標、今後のパフォーマンス目標を決定します。このプロセスは、今後の容量計画にとっての鍵です。
パフォーマンスがよいときと悪いときの両方で、オペレーティング・システム、データベースおよびアプリケーションの統計をフルセットでシステムから取得します。すべての統計を取得できない場合は、可能な範囲で取得します。使用できる統計がないのは、犯罪捜査で証拠がないのと同じです。証拠がないと、捜査が困難になり時間もかかります。
ユーザー・パフォーマンスに関係のあるすべてのコンピュータのオペレーティング・システムが健全であることをチェックします。オペレーティング・システムの健全性をチェックすることにより、フルに使用されているハードウェアやオペレーティング・システムのリソースを探します。過剰使用のリソースを症状としてリストし、後で分析します。さらに、すべてのハードウェアでエラーや診断症状がないことをチェックします。
Oracle Databaseで最もよく見られる誤りの上位10項目をチェックし、それらが問題であるかどうかを判断します。問題となる可能性がある場合は、症状としてリストし、後で分析します。これらの項目をリストに含めるのは、問題となる可能性が高いためです。ADDMでは、これらの上位10項目のうち9項目が自動的に検出されレポートされます。第6章「自動パフォーマンス診断」および「Oracleシステムにおける誤りの上位10項目」を参照してください。
症状を手がかりにして、システムで発生している状況の概念モデルを作成し、パフォーマンスの問題の原因を把握します。「パフォーマンスを概念的にモデル化する際の意思決定プロセスの例」を参照してください。
一連の修正処理とシステムに対して予想される動作を提示し、アプリケーションに対して最も有効な処理から順に適用します。ADDMにより、各推奨事項と予測されるメリットが生成されます。パフォーマンス改善作業の原則は、変更は一度に1つのみとし、変更前後の差異を測定することです。ただし、システム停止時間に制約があり、この方法を忠実に実行できないことがあります。一度に複数の変更を適用する場合は、それぞれの変更を切り離して、それぞれの変更の効果を個別に検証できるようにします。
変更により期待された効果があることを検証し、ユーザーがパフォーマンスの改善を認識したかどうかを確認します。ユーザーが認識しない場合は、さらにボトルネックを探し、アプリケーションをより正確に把握できるまで、概念モデルの微調整を続けます。
パフォーマンス目標が達成されるまで、または他の制約によって達成が不可能になるまで、前述の最後の3つの手順を繰り返します。
この方法によって、最大のボトルネックが特定され、パフォーマンスの改善に対する客観的アプローチが使用されます。重要なことは、アプリケーションの効率を高め、リソース不足とボトルネックを取り除くことにより、パフォーマンスを大幅に改善することです。このプロセスでは、インスタンスのチューニングにより最低限のパフォーマンスの向上(10%未満)が期待でき、アプリケーションの効率の悪さを切り離すことで大幅なパフォーマンスの向上(100%以上)が期待できます。
概念的なモデル化は、ほとんど決定論的なプロセスです。しかし、パフォーマンス・チューニングの経験を積むと、実際に規則が存在しないことの良さに気がつきます。統計を解析して最適な意思決定を行うには、柔軟で機敏なアプローチが必要になります。
迅速かつ簡単なパフォーマンス・チューニングへのアプローチには、ADDMを使用します。ADDMを使用すると、Oracleシステムが自動的に監視され、パフォーマンスの問題が発生した場合は解決のための推奨事項が提供されます。たとえば、データベース管理者がユーザーからシステム・パフォーマンスが低下したという苦情を受け取ったとします。データベース管理者は、ただ最新のADDMレポートを調べ、問題を解決するにはどの推奨事項を実装すればよいかを確認します。Oracleデータベースの監視と診断に役立つ機能の詳細は、第6章「自動パフォーマンス診断」を参照してください。
次の手順は、パフォーマンス・エンジニアが自動診断機能を使用せずにボトルネックを調べる方法を示しています。これらの手順は、あくまでも手動プロセスのガイドラインです。パフォーマンス・エンジニアは、経験を積みながら、それを関連する手順に追加していきます。この分析では、オペレーティング・システム統計とデータベース統計が収集されていることが前提です。
負荷がまったくないか少ないコンピュータで、シングル・ユーザーに対するレスポンス時間またはバッチ実行時間は許容できる範囲ですか。
許容範囲外の場合は、アプリケーションのコードまたは設計が最適でないと考えられます。また、これは、システム・リソースを共有するマルチ・ユーザーの状況では、まったく受け入れられません。このような場合は、アプリケーションの内部統計を取得し、SQLトレースとSQL計画の情報を取得します。開発者とともに、データ、索引およびトランザクションのSQL設計に関する問題を調査し、バッチ処理およびバックグラウンド処理の遅延の可能性について調査します。
CPUがすべて使用されていますか。
カーネル使用率が40%を超えた場合は、ネットワーク転送、ページング、スワッピングまたはプロセス・スラッシングについてオペレーティング・システムを調べます。引き続き、ユーザー領域でのCPU使用率をチェックし、CPUを消費するデータベース以外のジョブ(バックアップ、ファイル変換、印刷キューなど)がシステム上で発生して、共有CPUリソース量を制限していないかどうかを確認します。データベースがCPUのほとんどを使用していることを確認した後、CPU使用率が上位のSQLを調べます。これらの文が、今後の分析の基礎になります。SQLおよびSQLを送信するトランザクションが、最適に実行されているかどうかをチェックします。Oracle Databaseでは、V$SQLおよびV$SQLSTATSにCPU統計が示されます。
|
関連項目: V$SQLおよびV$SQLSTATSの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
アプリケーションが最適で、SQLが効率的に実行されている場合は、一部の作業をピーク時以外に再スケジュールするか、大型のコンピュータの使用を検討してください。
この段階で、CPUリソースが完全には使用されていないのに、システム・パフォーマンスがまだ不十分ですか。
不十分な場合は、サーバー内にシリアライズされた、スケーラブルでない動作があります。サーバーからWAIT_EVENTS統計を取得し、最大のシリアライズ・ポイントを確認します。シリアライズ・ポイントがない場合、問題はデータベースの外にある可能性が高く、これを重点的に調査する必要があります。WAIT_EVENTSをなくすには、アプリケーションSQLを修正し、データベース・パラメータをチューニングします。このプロセスは非常に反復的で、WAIT_EVENTSを系統的にドリルダウンして、シリアライズ・ポイントを取り除く技術を必要とします。
この項では、Oracleデータベースで最もよく見受けられる誤りをリストします。Oracleのパフォーマンス改善方法に従うことで、これらの誤りはすべて回避できます。これらの誤りをシステム内で見つけた場合は、アプリケーション内でパフォーマンス改善の効果のある箇所を再設計します。Oracleデータベースの診断とチューニングに役立つ機能の詳細は、「自動パフォーマンス・チューニング機能」を参照してください。待機イベント・データにより、パフォーマンスに影響を与えるような問題の症状が明らかになりますが、その詳細は、第10章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。
不適切な接続管理
アプリケーションで、データベースとの対話ごとに接続と切断が行われることがあります。この問題は、アプリケーション・サーバー内のステートレス・ミドルウェアで多く発生します。この問題がパフォーマンスに与える影響の大きさは2桁以上違い、まったくスケーラブルではありません。
カーソルと共有プールの不適切な使用
カーソルを使用しないと、解析が繰り返し行われることになります。バインド変数を使用しないと、すべてのSQL文のハード解析が行われます。この問題がパフォーマンスに与える影響は甚だしく、まったくスケーラブルではありません。カーソルをオープンするバインド変数とともにカーソルを使用し、繰り返し実行します。動的SQLを生成するアプリケーションは疑ってみます。
不適切なSQL
不適切なSQLとは、アプリケーション要件よりも多くのリソースを使用するSQLです。たとえば、意思決定支援システム(DSS)による問合せが24時間以上実行されている場合や、オンライン・アプリケーションからの問合せに1分以上かかる場合などがあります。大量のシステム・リソースを消費するSQLを検査し、改善の可能性を調査します。ADDMは、高負荷のSQLを識別します。SQLチューニング・アドバイザにより、改善のための推奨事項が提供される可能性があります。第6章「自動パフォーマンス診断」および第17章「自動SQLチューニング」を参照してください。
標準でない初期化パラメータの使用
このようなパラメータは、不適切なアドバイスや不正確な前提に基づいて実装されていることがあります。ほとんどのデータベースでは、基本パラメータ・セットのみを使用して、許容できるパフォーマンスを提供します。特に、ラッチに対するSPIN_COUNTに関連するパラメータとマニュアルに記載されていないオプティマイザ機能は、多くの問題の原因となり、このためにかなりの調査が必要になることがあります。
また、初期化パラメータ・ファイルに設定したオプティマイザ用パラメータが、実証済の最適実行計画をオーバーライドしてしまう可能性があります。このため、スキーマ、スキーマ情報およびオプティマイザの設定は、グループとして管理して一貫性のあるパフォーマンスを維持します。
|
関連項目:
|
誤ったデータベースI/Oの取得
多くのサイトが、使用可能ディスク上にデータベースを適切にレイアウトしていません。また、ディスクをI/O帯域幅ではなくディスク領域によって構成し、ディスク数を誤って指定しているサイトもあります。第8章「I/O構成および設計」を参照してください。
オンラインREDOログの設定問題
多くのサイトが、非常に少ないオンラインREDOログ・ファイルおよび小さいファイルを使用して運用されています。REDOログ・ファイルのサイズが小さいと、システム・チェックポイントがバッファ・キャッシュとI/Oシステムに高い負荷をかけ続けることになります。REDOログ・ファイルの数が少なすぎると、アーカイブが間に合ないので、データベースはアーカイバが追い付くまで待機します。パフォーマンスの観点からのREDOログ・ファイルのサイズ設定の詳細は、第4章「パフォーマンスを考慮したデータベースの構成」を参照してください。
空きリスト、空きリスト・グループ、トランザクション・スロット(INITRANS)またはロールバック・セグメントの不足による、バッファ・キャッシュ内でのデータ・ブロックのシリアライズ
この問題は、INSERT操作が多いアプリケーション、ブロック・サイズを8KB以上に上げたアプリケーション、またはアクティブ・ユーザーの数が多くロールバック・セグメントの数がほとんどないアプリケーションで特によく見受けられます。自動セグメント領域管理(ASSM)と自動UNDO管理を使用して、この問題を解決します。
時間のかかる全表スキャン
大量の全表スキャンまたは対話型のオンライン操作での全表スキャンで時間がかかる場合は、トランザクション設計が不適切であるか、索引が欠落しているか、SQL最適化が不十分です。時間のかかる表スキャンは、本質的にI/O集中型で、スケーラブルではありません。
大量の再帰的(SYS)SQL
SYSによって実行される大量の再帰的SQLは、エクステント割当てなどの領域管理操作が発生していることを示します。これはスケーラブルではなく、ユーザーのレスポンス時間に影響を与えます。ローカル管理表領域を使用して、エクステント割当てによる再帰的SQLを減らしてください。別のユーザーIDで実行される再帰的SQLは、SQLおよびPL/SQLである可能性が高く、問題ではありません。
デプロイメントおよび移行時のエラー
アプリケーションが必要以上にリソースを使用する場合、その原因の多くは、表を所有するスキーマが開発環境または古い実装から正しく移行されていないことにあります。この例としては、索引の欠落や不正確な統計があります。このようなエラーは、不適切な実行計画や、ユーザー対話パフォーマンスの低下につながります。パフォーマンスがわかっているアプリケーションを移行するときは、DBMS_STATSパッケージを使用してスキーマ統計をエクスポートし、プラン・スタビリティを維持します。
ADDMでは、この種のエラーが直接検出されることはありませんが、それによる高負荷SQLは明らかになります。
この項では、パフォーマンスに関する緊急事態に対処する方法について説明します。アプリケーションのパフォーマンスを確立および改善する方法論がすでに存在すると推定されます。しかし、緊急時には、システム・コンポーネントの変化によって、信頼性の高い予測可能なシステムが予測不可能でユーザー・リクエストを満たせないシステムに変化します。
このような場合、パフォーマンス・エンジニアは、何が変化したかをすばやく判断し、適切な処理を行って、通常のサービスをできるだけ早く再開する必要があります。多くの場合、緊急の処理が必要であり、パフォーマンス改善方法を厳密に実行することは現実的ではありません。
パフォーマンス・エンジニアは、パフォーマンスの問題にただちに対処した後、十分なデバッグ情報を収集して、その問題をより明らかに把握するか、それができない場合は、少なくとも同じ問題が再発しないようにする必要があります。
緊急のパフォーマンスの問題をデバッグする方法は、このマニュアルの前の章で説明したパフォーマンス改善方法と同じです。ただし、急を要するという問題の性質上、様々な段階で簡便法が使用されます。デバッグ・プロセスの進行中に見つかった事実を詳細にメモし記録しておくことが、後で行う分析と修正作業の正当化には不可欠です。これは、医師が患者の容態を克明に記録して、将来の参照資料として役立てるのと同じです。
パフォーマンスの緊急の問題に対処する方法は、次のとおりです。
パフォーマンスの問題を調査し、問題の症状を収集します。このプロセスには、次の作業が含まれます。
システムのパフォーマンスが低下した状況について、ユーザー・フィードバックを収集します。問題がスループットかレスポンス時間かを調べます。
「パフォーマンスが正常だった時点から何が変化しましたか」という質問をユーザーにします。この質問に対する答が、問題の手がかりになることがあります。ただし、状況が悪化する中で先入観のない答を得るのは難しいことがあります。問題の前と後で取得された参照データ(収集済の統計やログ・ファイル)を見つけるようにします。
自動チューニング機能を使用して問題を診断および監視します。Oracleシステムの診断とチューニングに役立つ機能の詳細は、「自動パフォーマンス・チューニング機能」を参照してください。また、Oracle Enterprise Managerのパフォーマンス機能を使用すると、上位のSQLおよびセッションを識別できます。
アプリケーション・システムの全コンポーネントのハードウェア使用が健全であることをチェックします。CPU使用率が最も高いコンポーネントをチェックし、システムの全コンポーネントについて、ディスクとメモリーの使用およびネットワーク・パフォーマンスをチェックします。このプロセスによって、問題の原因となっている層をすばやく特定できます。問題がアプリケーション内で発生している場合は、分析の重点をアプリケーションのデバッグへ移します。それ以外の場合は、データベース・サーバーの分析に進みます。
データベース・サーバーがCPU上で制約を受けているかどうか、待機イベントで待機し続けているのかを判断します。データベース・サーバーがCPU上で制約を受けている場合は、次の点を調べます。
オペレーティング・システム・レベルで大量のCPUおよびデータベースを消費しているセッション(V$SESS_TIME_MODELでデータベースのCPU使用率を調べます。)
データベース・レベルで多数のバッファ読取りを実行しているセッションまたは文(V$SESSTATおよびV$SQLSTATSを調べます。)
最適ではないSQLの実行の原因となった実行計画の変更(特定が困難な場合もあります。)
初期化パラメータの誤設定
コードの変更または全コンポーネントのアップグレードによるアルゴリズムの問題
データベース・セッションがイベントを待機している場合は、V$SESSION_WAITにリストされている待機イベントに従って、シリアライズの原因を判断します。V$ACTIVE_SESSION_HISTORYビューには、サンプリングされたセッション・アクティビティの履歴が含まれており、問題が終了してシステムが通常の操作に戻った後も診断に使用できます。ライブラリ・キャッシュに大量の競合がある場合は、データベースにログオンしたりSQLを送信するのが不可能なことがあります。このような場合は、履歴データを使用して、そのラッチで競合が突然発生した原因を判断します。ほとんどがI/O待機の場合は、V$ACTIVE_SESSION_HISTORYを調べて、すべての入出力を実行するセッションで実行中のSQLを判断します。待機イベントの詳細は、第10章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。
緊急時の処理を適用して、システムを安定化します。これには、アプリケーションの一部をオフラインにする処理や、システムに適用できるワークロードを制限する処理が含まれます。また、システムの再起動や処理中のジョブの停止も含まれることがあります。これらの処理は、当然、サービス・レベルに影響を与えることになります。
システムが安定していることを確認します。システムを変更したり制限した場合は、システムが安定したことを確認し、データベースに関する参照統計情報を収集します。次に、このマニュアルの前の章で説明した厳密なパフォーマンス改善方法に従って、すべての機能とユーザーをシステムに戻します。このプロセスを完了するには、アプリケーションの大幅な再設計が必要になることがあります。
