日本語PDF
  1. データベース・パフォーマンス・チューニング・ガイド
  2. データベース・パフォーマンスの基本
  3. パフォーマンス・チューニングの概要

1 パフォーマンス・チューニングの概要

この章では、パフォーマンス・チューニングの概要を説明します。この章には、次の項があります。

パフォーマンス・チューニングの概要

このガイドは、Oracle Databaseのパフォーマンス・チューニングに関する情報を提供します。この項には次の項目があります。

関連項目:

Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してデータベースのパフォーマンスをチューニングする方法を学習するには、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください

パフォーマンス計画

このドキュメントの他の部分に進む前に、「データベース・パフォーマンスの基本」を参照してください。オラクル社では、長年にわたる設計およびパフォーマンス経験に基づき、パフォーマンスに関する方法論を設計しました。このトピックでは、システム・パフォーマンスを大幅に改善できるアクティビティについて説明します。内容は次のとおりです。

インスタンスのチューニング

「データベース・パフォーマンスの診断およびチューニング」では、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の変更

  • ホスト・ハードウェア構成の変更

多くの場合、ボトルネックを解決する最も効果的な方法は、アプリケーションを変更することです。

SQLチューニング

SQLでは、問合せを発行し、データが戻されるため、多くのアプリケーション・プログラマはSQLをメッセージ言語として認識しています。しかし、クライアント・ツールでは非効率的なSQL文が生成される場合がよくあります。したがって、データベースSQL処理エンジンについて理解することは、最適なSQLを作成するために必要です。このことは特に、大量トランザクション処理システムについて言えます。

通常、オンライン・トランザクション処理(OLTP)アプリケーションにより発行されたSQL文は、比較的少数の行で一度に処理されます。索引が正確に必要な行を示す場合、正確な計画を作成して、可能な最短のパスを使用して効率的に行にアクセスできます。意思決定支援システム(DSS)環境では、表の行のほとんどにアクセスする場合が多いため、選択性は重要視されません。そのような状況では、全表スキャンが一般的であり、索引は使用しません。このマニュアルは、主として、OLTPアプリケーションを中心に説明しています。

関連項目:

問合せオプティマイザおよび実行計画

OracleデータベースでSQL文を実行すると、問合せオプティマイザは、問合せに指定されたオブジェクトの参照および条件に関連する様々な要素を考慮した後、最も効率的な実行計画を判断します。この判断は、SQL文の処理で重要なステップであり、実行時間が大きく変化します。

評価プロセスでは、問合せオプティマイザにより、システム上に収集された統計が確認され、最適なデータ・アクセス・パスおよびその他の考慮事項が判断されます。問合せオプティマイザの実行計画を、SQL文に挿入されたヒントで上書きできます。

パフォーマンス・チューニング機能およびツールの概要

効果的なデータの収集と解析は、パフォーマンスの問題を識別して修正するために不可欠です。Oracle Databaseには、パフォーマンス・エンジニアがデータベースのパフォーマンスに関する情報の収集に使用できる様々なツールがあります。データの収集に加え、パフォーマンスの監視、問題の診断およびアプリケーションのチューニングのためのツールもあります。

Oracle Databaseの収集および監視機能は、大部分が自動で動作し、Oracleバックグラウンド・プロセスによって管理されます。自動統計収集機能と自動パフォーマンス機能を有効にするには、STATISTICS_LEVEL初期化パラメータをTYPICALまたはALLに設定する必要があります。収集ツールおよびチューニング・ツールの出力は、Oracle Enterprise Manager Cloud Control (Cloud Control)、またはAPIとビューを使用して管理および表示できます。使いやすく、様々な自動化された監視および診断ツールの利点があることから、Cloud Controlをお薦めします。

関連項目:

自動パフォーマンス・チューニング機能

Oracle Databaseの自動パフォーマンス・チューニング機能には、次のものがあります。

  • 自動ワークロード・リポジトリ(AWR)では、問題の検出および自己チューニングを目的として、パフォーマンス統計が収集、処理および保守されます。「自動ワークロード・リポジトリ」を参照してください。

  • 自動データベース診断モニター(ADDM)では、Oracleデータベースにおいて考えられるパフォーマンス上の問題について、AWRによって収集された情報が分析されます。「自動データベース診断モニターの概要」を参照してください。

  • SQLチューニング・アドバイザでは、SQL文を変更しないでSQL文を素早く効率的に最適化することが可能です。Oracle Database SQLチューニング・ガイドを参照してください。

  • SQLアクセス・アドバイザでは、マテリアライズド・ビュー、索引およびマテリアライズド・ビュー・ログについてアドバイスが提供されます。Oracle Database SQLチューニング・ガイドを参照してください。

  • End to End Application Tracingでは、特定のユーザー、サービスまたはアプリケーション・コンポーネントに関して、システム上の過剰なワークロードが識別されます。Oracle Database SQLチューニング・ガイドを参照してください。

  • 障害となっている問題が検出されると、サーバー生成アラートにより自動的に通知が提供されます。サーバー生成アラートを使用したデータベース操作の監視方法を学習するには、『Oracle Database管理者ガイド』を参照してください。

  • Oracle Enterprise Manager Cloud Control (Cloud Control)から、インスタンスのメモリーを最適化するためのメモリー・アドバイザなど、その他のアドバイザを起動できます。通常、メモリー・アドバイザが使用されるのは、データベースの自動メモリー管理が設定されていない場合です。その他のアドバイザは、平均リカバリ時間(MTTR)の最適化、セグメントの縮小およびUNDO表領域の設定に使用されます。Cloud Controlで使用可能なアドバイザについて学習するには、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

  • Cloud Controlの「データベース・パフォーマンス」ページには、リアルタイム監視および診断に関するホスト、インスタンス・サービス時間およびスループット情報が表示されます。このページは、選択した間隔で自動的に、または手動でリフレッシュするように設定できます。データベースの「パフォーマンス」ページについて学習するには、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

その他のOracle Databaseツール

この項では、パフォーマンス問題の調査に使用できるその他のOracle Databaseツールについて説明します。

V$パフォーマンス・ビュー

V$ビューは、すべてのOracle Databaseパフォーマンス・チューニング・ツールで使用されるパフォーマンスの情報ソースです。V$ビューは、インスタンスの起動時に初期化されたメモリー構造に基づいています。メモリー構造およびそれらを表すビューは、インスタンスの存続期間中、Oracle Databaseにより自動的に管理されます。

ノート:

パフォーマンス・データの収集には自動ワークロード・リポジトリを使用することをお薦めします。これらのツールは、パフォーマンスの分析に必要なすべてのデータを収集するように設計されています。

関連項目: