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