11g リリース1（11.1）
E05744-02
 目次 |
 索引 |
| Oracle Database 2日でパフォーマンス・チューニング・ガイド 11g リリース1（11.1） E05744-02 |
|
パフォーマンスの改善は反復プロセスです。1つ目のボトルネック（リソースの競合が最も激しいポイント）を解消してもすぐにパフォーマンスの向上につながらず、他のボトルネックがシステムに対してさらに大きな影響を与えていることが発見される場合があります。このため、Oracleのパフォーマンス・メソッドは反復的です。システムを変更してパフォーマンスを改善するには、その最初の手順としてパフォーマンスの問題を正確に診断する必要があります。
一般的に、パフォーマンスの問題はスループットの不足、ユーザーやジョブのレスポンス時間の異常の原因になります。問題の原因は特定のアプリケーションのモジュールである場合も、システム全体である場合もあります。データベースまたはオペレーティング・システムの統計を確認する前に、問題が発生しているシステムおよびアプリケーションのユーザーからフィードバックを収集することが不可欠です。ユーザーからのフィードバックは、パフォーマンス目標の決定に役立ちます。また、パフォーマンスの改善はシステムの統計よりも実際のビジネス目標の方が測定基準として優れています。
Oracleパフォーマンス・メソッドは、パフォーマンスの目標が達成されるか達成不可能と判断されるまで適用できます。このプロセスは反復的であるため、システムのパフォーマンスへの影響をほとんど解消できるまで調査されます。重大なボトルネックをタイムリに正確に特定するには、時間と経験が必要です。自動データベース診断モニター（ADDM）ではOracleパフォーマンス・メソッドおよび分析統計が実装され、パフォーマンス上で重大な問題が自動で診断されます。このマニュアルの説明に従ってADDMを使用すると、パフォーマンスの向上に必要とされる時間が大幅に短縮されます。
この章ではOracle Databaseパフォーマンス・メソッドを説明しています。内容は次のとおりです。
データベース統計ではデータベースの負荷のタイプ、およびデータベースで使用する内部および外部リソースに関する情報が提供されます。ADDMを使用したデータベースでパフォーマンスの問題を正確に診断するには、統計が使用可能である必要があります。
Oracle Databaseはシステム、セッションおよび個別のSQL文の累積統計のタイプを生成します。Oracle Databaseはセグメントおよびサービスについての累積統計の追跡もします。自動ワークロード・リポジトリ（AWR）では、データベースの問題検出および自己チューニングのために、パフォーマンス統計の収集、処理および保持によりデータベースの統計採取が自動的に行われます。
デフォルトでは、AWRスナップショットで統計採取プロセスを1時間ごとに繰り返します。このスナップショットは、パフォーマンスの比較に使用される特定の時間でのデータのセットです。スナップショットで取得したデルタ値は、時間ごとの各統計に対する変更を示します。AWRで採取した統計はメモリーから問い合せます。採取したデータは、レポートおよびビューで表示できます。
AWRを使用したデータベース統計の収集はデフォルトで有効になっており、STATISTICS_LEVEL初期化パラメータにより制御されています。STATISTICS_LEVELパラメータはTYPICALまたはALLに設定されており、AWRによる統計の収集が可能です。デフォルトの設定はTYPICALです。STATISTICS_LEVELパラメータをBASICに設定すると、AWRを含む多くのOracle Databaseの機能が無効化されるため、お薦めしません。STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
CONTROL_MANAGEMENT_PACK_ACCESS初期化パラメータをDIAGNOSTIC+TUNING（デフォルト）またはDIAGNOSTICに設定し、自動データベース診断監視を有効にする必要があります。CONTROL_MANAGEMENT_PACK_ACCESSをNONEに設定すると、ADDMを含む多くのOracle Databaseの機能が無効化されるため、お薦めしません。CONTROL_MANAGEMENT_PACK_ACCESS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
AWRで収集および処理されるデータベース統計には、次のものがあります。
時間モデル統計はデータベース内での操作タイプによる経過時間を測定します。最も重要な時間モデル統計はデータベース時間（DB時間）です。データベース時間はデータベースのコール内で経過した合計時間を表し、またインスタンスのワークロードの合計の指標にもなります。図2-1で説明されているように、データベース時間はアプリケーションのユーザー・レスポンス時間全体の一部を構成します。
セッションとは、ユーザー・プロセスを介したOracle Databaseインスタンスへのユーザーの特定の接続のことです。データベース時間はCPU時間と、アイドル状態の待機イベントを待機していないすべてのユーザー・セッション（アイドル状態ではないユーザー・セッション）の待機時間を集計することによって算出されます。たとえば、ユーザー・セッションには、書店のWebサイトで実行されるオンライン・トランザクション（図2-2に示すアクションで構成される）などがあります。
ユーザーは特定の作者の書籍の検索を実行します。このアクションでは、アプリケーションにより、作者別の書籍のデータベースに対して問合せが実行されます。
ユーザーは、戻された作者別の書籍のリストを参照し、ユーザー・レビューおよび在庫状況などの詳細にアクセスします。このアクションでは、アプリケーションにより追加のデータベース問合せが実行されます。
書籍の詳細を参照した後、ユーザーは書籍の1つをショッピング・カートに追加することを決定します。このアクションでは、アプリケーションによりデータベースが呼び出され、ショッピング・カートが更新されます。
以前に商品を購入したときに書店のWebサイトに保存されていた、住所および支払い情報をユーザーが確認し、取引を完了します。このアクションでは、アプリケーションにより様々なデータベース操作が行われ、ユーザー情報の取得、新しい注文の追加、在庫情報の更新、および電子メールの認証が実行されます。
これらの各先行アクションでは、ユーザーは図2-2の下矢印で示されているとおりにデータベースに対し要求を行います。データベースが要求を処理するためにかかるCPU時間およびデータベースの待機にかかる待機時間はDB時間と呼ばれます（色付きの部分）。要求が完了すると、上矢印で示されているとおりに、結果がユーザーに戻されます。上矢印および下矢印の間の領域は要求を処理するための合計ユーザー・レスポンス時間を表し、図2-1で示されるようにDB時間以外のその他のコンポーネントが含まれます。
データベースのチューニングの目的は、データベースでユーザーがアクションの実行に使用する時間を減らすこと、またはデータベース時間を減らすことです。チューニングすることにより、アプリケーションでのユーザーのトランザクションの全体のレスポンス時間が向上します。
セッションがあるイベントの完了を待機してから処理を続行する必要があったことを示すため、待機イベントはセッションによって増分されます。ユーザー要求を処理している間にセッションが待機する必要がある場合、データベースは事前定義された待機イベントのセットの1つを使用して、その待機を記録します。次に、このイベントは、「ユーザーI/O」および「ネットワーク」などの待機クラスに分類されます。待機イベント・データにより、ラッチ、バッファ、I/Oの競合など、パフォーマンスへ悪影響を与える可能性のある症状が明らかになります。
データベースの多数の累積統計はシステムおよびセッション・レベルで使用可能です。これらの統計の一部はAWRで収集されます。
アクティブ・セッション履歴（ASH）統計はデータベースのセッション・アクティビティのサンプルです。データベースは毎秒サンプリングされ、システム・グローバル領域（SGA）の循環バッファに格納されます。データベースに接続してCPUを使用しているセッションまたはアイドル待機クラスに属していないイベントを待っているセッションは、アクティブ・セッションと認識されます。アクティブ・セッションのみ取得すると、管理可能なデータのセットが示されます。データのサイズは、システムで実行可能なセッション数ではなく、実行中の作業に直接関連します。
「時間モデル統計」で説明したDB時間の例を使用すると、書店のWebサイトで行ったオンライン・トランザクションからセッション・アクティビティのサンプルが収集されます。これは、図2-3の横矢印の下の縦線で示されています。
細い縦線は、ASH統計に取得されない非アクティブ・セッション・アクティビティのサンプルを表しています。太い縦線は次の時点で取得されたアクティブ・セッションのサンプルを表しています。
表2-1に、サンプリングされるセッションID（SID）、モジュール、SQL ID、セッション状態、および待機イベントの例とともに、アクティブ・セッションに対して収集されたASH統計を示します。
経過時間およびCPU時間などのリソースの大部分を消費するSQL文は、システムにとって非常に大きな負荷となります。
Oracleのパフォーマンス・メソッドを使用したパフォーマンス・チューニングは、データベースのボトルネックの識別と解消、および効率的なSQL文の開発によって行われます。データベースのチューニングは、事前および事後の2つのフェーズで構成されます。
事前チューニングのフェーズで、ADDM分析および検出結果の確認、リアルタイムでのデータベースのパフォーマンスの監視、およびアラートへの対応などのチューニング・タスクを、データベースのメンテナンス・ルーチンの一部として日常的に実行する必要があります。
短期的に発生するパフォーマンスの問題、または時間の経過によるデータベースのパフォーマンスの低下などの問題がユーザーから報告された場合は、事後チューニングのフェーズで対応する必要があります。
SQLチューニングは、高負荷SQL文の効率を識別、チューニングおよび向上させる反復プロセスです。
Oracleパフォーマンス・メソッドの適用には、次の操作が含まれます。
データベースのパフォーマンスを改善するために、これらの原則を繰り返して適用する必要があります。
この項ではデータベースのチューニング前に行う必要のある手順をリストして説明します。
パフォーマンス・プロジェクトの有効範囲、最終的なパフォーマンスの目標、および将来のパフォーマンス目標を決定します。このプロセスは今後の容量計画にとって重要です。
ハードウェアまたはオペレーティング・システム・リソースが完全に使用されていることを確認します。発生する可能性のある問題として超過したリソースをリストし、後で分析します。さらに、すべてのハードウェアが正常に機能していることを確認します。
STATISTICS_LEVEL初期化パラメータがTYPICAL（デフォルト）またはALLに設定されていることを確認します。
CONTROL_MANAGEMENT_PACK_ACCESS初期化パラメータをDIAGNOSTIC+TUNING（デフォルト）またはDIAGNOSTICに設定し、ADDMを有効にします。この項ではデータベースのプロパティの定期的なチューニングに必要な手順をリストして説明します。これらのチューニングの手順は事前の手順で、Oracle Databaseの日常的なメンテナンスの一部として実行する必要があります。
ADDMは、「Oracle Databaseで検出されるパフォーマンスにおける一般的な問題」のほとんどが含まれるデータベースに関するパフォーマンスの問題を自動的に検出し、報告します。結果はADDMの検出結果としてOracle Enterprise Manager（Enterprise Manager）のデータベースのホームページに表示されます。これらの結果を確認することにより、注意が必要なパフォーマンスの問題を迅速に識別することが可能となります。
ADDMは各ADDMの検出結果に含まれるパフォーマンスの問題の影響を小さくする推奨事項のリストを自動的に提供します。推奨事項の実装により、推奨された変更が適用されデータベースのパフォーマンスが改善されます。
Enterprise Managerの「パフォーマンス」ページでは、リアルタイムのパフォーマンスの問題を識別し、対応できます。適切なページにドリルダウンすると、次のADDM分析の実行を待つことなく、リアルタイムでデータベースのパフォーマンスの問題を識別および解決できます。
Enterprise Managerのデータベースのホームページでは、システムによって生成されたパフォーマンス関連のアラートが表示されます。通常、これらのアラートでパフォーマンスの問題が明らかになり、問題を解決することでデータベースのパフォーマンスが向上します。
この項では、ユーザー・フィードバックに基づいたデータベースのチューニングに必要な手順をリストして説明します。このチューニングの手順は事後と考えられます。ユーザーによりパフォーマンスの問題がレポートされたときに、この手順を定期的に実行します。
次のADDM分析の前に現在のデータベースを分析する場合、またはシステムを定期的に監視しないときに過去のデータベースのパフォーマンスを分析する場合、このタスクは有効です。
アクティブ・セッション履歴（ASH）レポートでは、短期間でADDM分析に表示されないデータベースの一時的なパフォーマンスの問題を分析できます。
自動ワークロード・リポジトリ（AWR）期間の比較レポートで、2つの期間のデータベースのパフォーマンスを比較でき、特定の期間から他の期間にかけて発生するパフォーマンスの低下を解決します。
この項では高負荷SQL文の識別、チューニングおよび最適化に必要な手順をリストして説明します。
ADDMの検出結果および上位SQLセクションを使用して、最大の競合の原因となる高負荷SQL文を識別します。
SQLチューニング・アドバイザを使用して高負荷SQL文の効率を向上できます。
マテリアライズド・ビュー、マテリアライズド・ビュー・ログ、およびSQLアクセス・アドバイザを使用した特定のワークロードに対する索引の該当セットを作成して、データ・アクセス・パスのパフォーマンスを最適化できます。
SQLパフォーマンス・アナライザを使用して、任意のSQLワークロードで、SQLチューニング・アクティビティまたはその他のシステム変更のパフォーマンスの影響を分析できます。
この項ではOracleデータベース内で検出された共通のパフォーマンスの問題をリストして説明します。Oracleパフォーマンス・メソッドに従うと、これらの問題を回避できます。問題がある場合は、「Oracleパフォーマンス・メソッドの使用」で説明されているように、Oracleパフォーマンス・メソッドの手順を繰り返すか、またはこれらの問題に対処する項を参照してください。
CPUの限界のためにアプリケーションのパフォーマンスが低下していますか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、CPUがボトルネックとなって発生するパフォーマンスの問題は、ADDMにより診断されます。また、「CPU使用率の監視」で説明されているように、Enterprise Managerの「パフォーマンス」ページを使用してCPUのボトルネックを識別できます。
システム・グローバル領域（SGA）、プログラム・グローバル領域（PGA）、バッファ・キャッシュなどのOracleのメモリー構造は適切なサイズですか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、メモリー構造のサイズが小さいことにより発生するパフォーマンスの問題は、ADDMにより診断されます。また、「メモリー使用率の監視」で説明されているように、Enterprise Managerの「パフォーマンス」ページを使用してメモリー使用率の問題を識別できます。
I/Oサブシステムは正常に動作していますか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、I/Oの能力の問題によるパフォーマンスの問題はADDMにより診断されます。また、「ディスクI/O使用率の監視」で説明されているように、Oracle Enterprise Managerの「パフォーマンス」ページを使用してディスクI/Oの問題を識別できます。
アプリケーションが非効率的にOracle Databaseを使用していますか。データベースへの新規接続を何度も行ったり、SQL解析を過度に行ったり、少量のデータで過度の競合が発生（アプリケーション・レベルのブロック競合とも呼ばれます）したりすると、アプリケーションのパフォーマンスが大幅に低下します。第3章「データベースのパフォーマンスの自動監視」で説明されているように、アプリケーションによるOracle Databaseの使用が非効率的なために発生したパフォーマンスの問題は、ADDMにより診断されます。また、「ユーザー・アクティビティの監視」で説明されているように、Enterprise Managerの「パフォーマンス」ページを使用して、SQL、セッション、サービス、モジュールおよびアクションなどの様々なディメンションでトップ・アクティビティを監視できます。
同時アクティビティが多数発生し、データベースのパフォーマンスが低下していますか。同時アクティビティが多数発生すると、ロックまたはバッファ・キャッシュの待機の形で明示される共有リソースの競合が起こります。第3章「データベースのパフォーマンスの自動監視」で説明されているように、同時実行によるパフォーマンスの問題はADDMにより診断されます。また、「上位セッションの監視」で説明されているように、Enterprise Managerの「上位セッション」を使用して同時実行による問題を識別できます。
理想的なパフォーマンス・レベルになるようにデータベースが最適な構成になっていますか。たとえば、ログ・ファイルのサイズ設定の異常、アーカイブの問題、過度のチェックポイント、非効率的なパラメータ設定などの徴候はありませんか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、データベースの構成の問題が原因となっているパフォーマンスの問題は、ADDMにより診断されます。
短期間または断続的に発生するパフォーマンスの問題に関してユーザーが不満を持っていませんか。AWRによって作成されるスナップショットの間隔によって、短期間のパフォーマンスの問題がADDMで取得されない可能性があります。第7章「一時的なパフォーマンスの問題の解決」で説明されているように、短期間のパフォーマンスの問題は、アクティブ・セッション履歴レポートを使用して識別できます。
時間が経過するにつれてデータベースのパフォーマンスが低下している徴候はありませんか。たとえば、データベースの動作が6か月前と異なるとユーザーが感じていませんか。AWR期間の比較レポートを生成して、構成設定、ワークロード・プロファイルおよび統計の差を、パフォーマンスが安定していた期間とパフォーマンスが低下していた期間で比較して識別します。第8章「時間の経過によるパフォーマンス低下の解決」で説明されているように、この操作によりパフォーマンスの低下の原因を識別できます。
システムに影響を与える過度のシステム・リソースを使用するSQL文はありませんか。第3章「データベースのパフォーマンスの自動監視」および「ADDMの検出結果に基づく高負荷SQL文の識別」で説明されているように、高負荷SQL文によって発生するパフォーマンスの問題はADDMにより診断されます。また、「上位SQLに基づく高負荷SQL文の識別」で説明されているように、Enterprise Managerの上位SQLを使用することで高負荷SQL文を識別できます。これらを識別すると、第10章「SQL文のチューニング」で説明されているように、SQLチューニング・アドバイザを使用して高負荷SQL文をチューニングできます。
連続してアクセスされるためボトルネックの原因になっているデータベース・オブジェクトはありませんか。第3章「データベースのパフォーマンスの自動監視」で説明されているように、オブジェクトの競合によって発生するパフォーマンスの問題は、ADDMにより診断されます。また、第11章「データ・アクセス・パスの最適化」で説明されているように、SQLアクセス・アドバイザを使用してこれらのオブジェクトへのデータ・アクセス・パスを最適化できます。
チューニング後に、SQL文のパフォーマンスが低下していませんか。SQL文をチューニングすると、SQL文の実行計画の変更の原因となり、SQLのパフォーマンスに大きく影響します。変更はSQLパフォーマンスの向上につながる場合もあります。場合によっては、システム変更によってSQL文が低下し、SQLパフォーマンスが低下することがあります。本番システムで変更する前に、第12章「SQLパフォーマンスの影響分析」で説明されているように、SQLパフォーマンス・アナライザを使用して、テスト・システムでチューニングしたSQL文からパフォーマンスの影響を分析できます。
|
 Copyright © 2007, 2008 Oracle Corporation. All Rights Reserved. |
|