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