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