| Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース1（11.1） E05743-02 |
|
 戻る |
 次へ |
この章では、パフォーマンス・チューニングの概要を説明します。この章には、次の項があります。
このガイドは、Oracle Databaseシステムのパフォーマンス・チューニングに関する情報を提供します。この項には次の項目があります。
|
関連項目: Oracle Enterprise Managerを使用してOracle Databaseのパフォーマンスをチューニングする方法の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。 |
このガイドのインスタンスまたはSQLのチューニングの項に進む前に、必ず第II部「パフォーマンス計画」に目を通しておいてください。オラクル社では、長年にわたる設計およびパフォーマンス経験に基づき、パフォーマンスに関する方法論を設計しました。この項では、システム・パフォーマンスを大幅に向上させる明瞭で簡単なアクティビティについて説明します。次の項目について説明しています。
このガイドの第III部「インスタンスのパフォーマンスの最適化」では、Oracleデータベース・インスタンスのチューニングおよび最適化に関連する要因について説明します。
インスタンスのチューニングを検討している場合、パフォーマンス上の問題を引き起こす可能性のあるボトルネックを回避するため、データベース・システムの初期設計には注意する必要があります。さらに、次の点も考慮する必要があります。
データベース構造体へのメモリーの割当て
データベースの様々な部分のI/O要件の判断
データベースのパフォーマンスを最適化するためのオペレーティング・システムのチューニング
データベース・インスタンスをインストールおよび構成した後、パフォーマンス関連の問題をチェックするために動作しているデータベースを監視する必要があります。
パフォーマンス・チューニングでは、システムの初期構成に対して異なる（ただし関連性がある）方法を必要とします。システムの構成では、初期システムの構成が機能的なものになるように整理された手順に従ってリソースを割り当てます。
チューニングを開始するには、最も影響のあるボトルネックを識別し、適切な変更を行ってそのボトルネックの影響を低減するかまたは排除します。チューニングは通常、システムが本番開始以前か、または稼働状態になった後で事後的に行われます。
最も効率的なチューニングの方法は、パフォーマンスの問題が生じた場合に比較に使用できるパフォーマンス・ベースラインを確立することです。データベース管理者（DBA）の多くは、自分のシステムを熟知し、ピークの使用期間を簡単に識別できます。たとえば、ピーク期間は10.00am〜12.00pmである場合、また1.30pm〜3.00pmである場合もあります。これには、深夜の12.00amから6.00amまでのバッチ・ウィンドウが含まれることがあります。
サイトでこのようなピーク時間帯を識別し、このような高負荷の時間帯のパフォーマンス・データを収集するモニタリング・ツールをインストールすることが重要です。アプリケーションがQAサイクル中の初期のトライアル段階にある時点から、データ収集を構成することが最適です。それ以外の場合は、システムが最初に稼働したときに、このデータ収集を構成する必要があります。
収集されたベースライン・データには、次の内容が含まれていることが理想的です。
アプリケーション統計（トランザクション・ボリューム、レスポンス時間）
データベース統計
オペレーティング・システム統計
ディスクI/O統計
ネットワーク統計
自動ワークロード・リポジトリでは、ベースラインは将来比較するために保持されるスナップショットの範囲により識別されます。「自動ワークロード・リポジトリの概要」を参照してください。
パフォーマンス・チューニングの一般的な誤りは、ある問題の症状を現実の問題自体であると思い違いをすることです。多くのパフォーマンス統計はこの症状を示すこと、およびこの症状を識別することが修正を実施するために十分なデータではないことを認識することが重要です。たとえば、次のような場合があります。
低速な物理I/O
一般に、この原因はディスクの構成が適切ではないことにあります。しかし、チューニングが適切ではないSQLから発行された、これらのディスク上の大量の不要な物理I/Oが原因になっている可能性もあります。
インスタンスを再構成して、ラッチの競合をチューニングできることはほとんどありません。むしろ、ラッチの競合は通常、アプリケーションの変更により解決されます。
過剰なCPU使用率
過剰なCPU使用率は通常、システム上にアイドル状態のCPUがほとんどないことを意味します。この原因として、システムのサイズ設定が不適切であること、SQL文がチューニングされていないこと、またはアプリケーション・プログラムが不十分である可能性があります。
チューニングには次の2種類があります。
プロアクティブな監視は通常、定期的にスケジュールされた間隔で行われます。この場合、システム動作とリソースの使用量が変化したかどうかを識別するために多数のパフォーマンス統計が調べられます。プロアクティブな監視は、プロアクティブなチューニングとも考えられます。
通常は、進行中の重大な問題が監視により明らかにならないかぎり、監視によりシステムの構成が変化することはありません。状況によっては、経験豊富なパフォーマンス・エンジニアが統計のみで潜在的な問題点を識別できますが、通常はパフォーマンスの低下を伴います。
明らかなパフォーマンスの低下がないときに、事前のアクションとしてシステムを試行したり微調整することは危険なアクティビティであり、不必要にパフォーマンスを低下させる可能性があります。システムを微調整することは事後チューニングと考えられ、事後チューニングの手順に従う必要があります。
監視は通常、より大規模な容量計画の調査の一環です。容量計画ではリソース使用状況を調べて、さらにアプリケーションが使用されている方法の変化、およびアプリケーションがデータベース・リソースとホスト・リソースを使用している方法の変化を調べます。
チューニングは通常、パフォーマンスの問題の修正を意味します。ただし、チューニングは、分析、設計、コーディング、生産およびメンテナンスの各段階を通じて、アプリケーションのライフサイクルの一部である必要があります。多くの場合、チューニング段階はシステムが本番に入るまで残されます。このとき、チューニングは事後対応処理になります。この場合、最も重要なボトルネックが識別され、修正されます。
チューニングの目的は通常、リソース使用量を減らしたり、操作を完了する経過時間を減らすことにあります。いずれの場合も、目標は特定のリソースの有効利用を向上することにあります。一般に、パフォーマンスの問題は特定のリソースの過剰使用によって発生します。そのリソースは、システム内のボトルネックとなります。ボトルネックと潜在的な修正を識別するには、様々な多くの段階があります。それらについては次の項で説明します。
競合の様々な形態は症状であり、次のいずれかを変更することで修正できることに注意してください。
アプリケーションまたはアプリケーションの使用方法の変更
Oracleの変更
ホスト・ハードウェア構成の変更
多くの場合、ボトルネックを解決する最も効果的な方法は、アプリケーションを変更することです。
このガイドの第IV部「SQL文の最適化」では、SQL文のチューニングおよび最適化のプロセスについて説明します。
多くのクライアント/サーバー・アプリケーションのプログラマがSQLをメッセージ言語とみなすのは、問合せが発行され、データが戻されるためです。しかし、クライアント・ツールでは非効率的なSQL文が生成される場合がよくあります。したがって、データベースSQL処理エンジンについて理解することは、最適なSQLを作成するために必要です。このことは特に、大量トランザクション処理システムについて言えます。
一般に、OLTPアプリケーションから発行されるSQL文では、一度にわずかな行しか実行されません。必要な行を索引で正確に指示できれば、最短のパスを経由してこれらの行に効率よくアクセスする正確な計画を作成できます。意思決定支援システム（DSS）環境では、表の行のほとんどにアクセスする場合が多いため、選択性は重要視されません。そのような状況では、全表スキャンが一般的であり、索引は使用しません。このマニュアルは、主として、OLTPタイプのアプリケーションを中心に説明しています。DSS環境、およびDSSとOLTPの混合環境の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。
効果的なデータの収集と解析は、パフォーマンスの問題を識別して修正するために不可欠です。Oracleでは、パフォーマンス・エンジニアがデータベースのパフォーマンスに関する情報を収集できるようにする多数のツールを提供しています。Oracleでは、データ収集の他に、パフォーマンスの監視、問題の診断およびアプリケーションのチューニングのためのツールも提供しています。
Oracleの収集および監視機能は大部分が自動的なもので、Oracleバックグラウンド・プロセスにより管理されます。自動統計収集機能と自動パフォーマンス機能を使用可能にするには、STATISTICS_LEVEL初期化パラメータをTYPICALまたはALLに設定する必要があります。収集ツールおよびチューニング・ツールからの出力の管理および表示には、Oracle Enterprise Manager、またはAPIとビューを使用します。使いやすさと様々な自動化された監視および診断ツールの利点から、Oracle Enterprise Manager Database Controlをお薦めします。
|
関連項目:
|
Oracleには、次の自動パフォーマンス・チューニング機能があります。
自動ワークロード・リポジトリ（AWR）では、問題の検出および自己チューニングを目的として、パフォーマンス統計が収集、処理および保守されます。「自動ワークロード・リポジトリの概要」を参照してください。
自動データベース診断モニター（ADDM）では、Oracleデータベースにおいて考えられるパフォーマンス上の問題について、AWRによって収集された情報が分析されます。「自動データベース診断モニターの概要」を参照してください。
SQLチューニング・アドバイザでは、SQL文を変更しないでSQL文を素早く効率的に最適化することが可能です。「SQLチューニング・アドバイザを使用した事後チューニング」を参照してください。
SQLアクセス・アドバイザでは、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログについてアドバイスが提供されます。SQLアクセス・アドバイザの詳細は、「自動SQLチューニング機能」および「SQLアクセス・アドバイザの概要」を参照してください。
End to End Application Tracingでは、特定のユーザー、サービスまたはアプリケーション・コンポーネントに関して、システム上の過剰なワークロードが識別されます。「End to End Application Tracing」を参照してください。
障害となっている問題が検出されると、サーバー生成アラートにより自動的に通知が提供されます。サーバー生成アラートを使用したデータベース操作の監視の詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Enterprise Managerからその他のアドバイザを起動できます。たとえば、メモリー・アドバイザは、インスタンスのメモリーを最適化します。通常、メモリー・アドバイザが使用されるのは、データベースの自動メモリー管理が設定されていない場合です。その他のアドバイザは、平均リカバリ時間（MTTR）の最適化、セグメントの縮小およびUNDO表領域の設定に使用されます。Oracle Enterprise Managerで使用可能なアドバイザの使用の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。
Oracle Enterprise Managerの「パフォーマンス」ページには、リアルタイム監視および診断に関するホスト、インスタンス・サービス時間およびスループット情報が表示されます。このページは、選択した間隔で自動的に、または手動でリフレッシュするように設定できます。データベースの「パフォーマンス」ページの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。
この項では、パフォーマンスの問題の判断に使用できるその他のOracleツールについて説明します。
V$ビューは、すべてのOracleパフォーマンス・チューニング・ツールで使用されるパフォーマンス情報ソースです。V$ビューは、インスタンスの起動時に初期化されたメモリー構造に基づいています。メモリー構造および構造を表すビューは、インスタンスが存続する間、Oracleにより自動的にメンテナンスされます。V$パフォーマンス・ビューを使用して問題を診断しチューニングする方法は、第10章「パフォーマンス・ビューを使用したインスタンスのチューニング」を参照してください。
|
関連項目: 動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
|
注意: パフォーマンス・データの収集には自動ワークロード・リポジトリを使用することをお薦めします。これらのツールは、パフォーマンスの分析に必要なすべてのデータを収集するように設計されています。 |
