2 SQLパフォーマンス・アナライザの概要

SQLパフォーマンス・アナライザは、本番システムまたは本番システムによく似たテスト・システムで実行できます。 SQLパフォーマンス・アナライザではテストするSQL文を実行する必要があるため、本番システムでシステム変更をテストすると、システムのスループットに影響します。パフォーマンスへの影響をテストするためにシステムで行うグローバル変更によって、システムのその他のユーザーが影響を受ける可能性もあります。システム変更が多数のセッションまたはSQL文に影響しない場合は、本番システムでSQLパフォーマンス・アナライザを実行できます。ただし、データベースのアップグレードなどのシステム全体の変更では本番システムを使用しないことをお薦めします。かわりに、本番システムに影響を与えずにシステム変更の影響をテストできるように、別のテスト・システムでSQLパフォーマンス・アナライザを実行することを検討してください。テスト・システムを使用すると、本番システムで実行されているその他のワークロードがSQLパフォーマンス・アナライザによって実行される分析に影響することもなくなります。推奨される方法はテスト・システムでSQLパフォーマンス・アナライザを実行する方法であり、その方法をここで説明します。本番システムでSQLパフォーマンス・アナライザを実行する場合は、適宜テスト・システムを本番システムに置き換えてください。

SQLパフォーマンス・アナライザを使用してシステム変更によるSQLパフォーマンスへの影響を分析する場合は、図2-1に示すステップを実行します。

図2-1 SQLパフォーマンス・アナライザのワークフロー

図2-1の説明が続きます
「図2-1 SQLパフォーマンス・アナライザのワークフロー」の説明

  1. 分析対象のSQLワークロードを取得して、SQLチューニング・セットに格納します。詳細は、「SQLワークロードの取得」を参照してください。

  2. 本番システムとは切り離されたテスト・システムを使用する場合は、次のステップを実行します。

    1. 可能なかぎり本番環境と一致するようにテスト・システムを設定します。

    2. SQLチューニング・セットをテスト・システムに転送します。

  3. テスト・システムで、SQLパフォーマンス・アナライザのタスクを作成します。詳細は、「SQLパフォーマンス・アナライザのタスクの作成」を参照してください。

  4. SQLチューニング・セットに格納されているSQL文のテスト実行または実行計画の生成を行って、変更前のSQL試行を作成します。詳細は、「変更前のSQLパフォーマンスの測定」を参照してください

  5. システム変更を実行します。詳細は、「システム変更の実行」を参照してください

  6. 変更後のテスト・システムでSQLチューニング・セット内のSQL文を再実行して、変更後のSQL試行を作成します。詳細は、「変更後のSQLパフォーマンスの測定」を参照してください

  7. 変更前バージョンと変更後バージョンのパフォーマンス・データを比較および分析し、レポートを作成して、システム変更後にパフォーマンスが改善されたSQL文、パフォーマンスの変更がなかったSQL文またはパフォーマンスが低下したSQL文を特定します。詳細は、「パフォーマンス測定値の比較」を参照してください

  8. 特定されたパフォーマンスが低下したSQL文をチューニングします。詳細は、「パフォーマンスが低下したSQL文の修正」を参照してください。

  9. パフォーマンスの目標を達成するまで、ステップ6から8を繰り返し、チューニングしたSQL文のパフォーマンスが許容範囲内であることを確認します。

    それぞれの比較において、以前のSQL試行を変更前のSQL試行として使用し、現在のSQL試行を変更後のSQL試行として使用できます。たとえば、最初のSQL試行を現在のSQL試行と比較して、すべての変更を評価したり、最新のSQL試行を現在のSQL試行と比較して、最新の変更のみを評価する場合があります。

ノート:

Oracle Enterprise Managerでは、このプロセスを簡単にするため、ステップ3から9が自動化されたワークフローが提供されています。

ノート:

SQLパフォーマンス・アナライザでプラガブル・データベース(PDB)を使用する場合、データの可視性および必要な権限が異なる場合があります。

関連項目:

SQLワークロードの取得

SQLパフォーマンス・アナライザを実行する前に、分析対象のSQLワークロードを表すSQL文のセットを本番システムで取得します。

取得したSQL文には、次の情報が含まれています。

  • SQLテキスト

  • 実行環境

    • SQL文を実行し、正確な実行統計を生成するために必要なバインド値であるSQLバインド

    • SQL文をコンパイルできる解析スキーマ

    • SQL文が実行される、初期化パラメータが含まれているコンパイル環境

  • SQL文の実行回数

SQLワークロードの取得は、本番システムのパフォーマンスにごくわずかな影響を与えますが、スループットには影響を与えません。より多くのSQL文が含まれているSQLワークロードでは、アプリケーションまたはデータベースの状態がよりよく表示されます。これによって、システム変更がSQLワークロードに与える可能性がある影響をSQLパフォーマンス・アナライザでより正確に予測できるようになります。そのため、可能なかぎり多くのSQL文を取得する必要があります。アプリケーションでコールされているすべてのSQL文またはデータベースで実行されているすべてのSQL文のいずれかを取得することをお薦めします。

取得したSQL文をSQLチューニング・セットに格納し、SQLパフォーマンス・アナライザの入力ソースとして使用できます。SQLチューニング・セットは、1つ以上のSQL文がその実行統計および実行コンテキストとともに含まれているデータベース・オブジェクトです。SQL文は、カーソル・キャッシュ、自動ワークロード・リポジトリ(AWR)、SQLトレース・ファイル、既存のSQLチューニング・セットなどの様々なソースからSQLチューニング・セットにロードできます。SQLチューニング・セットを使用してSQLワークロードを取得すると、次のことができます。

  • 単一の永続データベース・オブジェクトへのSQLテキストおよび必要な補助情報の格納

  • SQLチューニング・セット内の取得済SQL文の移入、更新、削除および選択

  • 自動ワークロード・リポジトリ(AWR)やカーソル・キャッシュなどの様々なデータ・ソースからのコンテンツのロードおよびマージ

  • SQLワークロードを取得したシステムからのSQLチューニング・セットのエクスポート、および別のシステムへのSQLチューニング・セットのインポート

  • SQLチューニング・アドバイザやSQLアクセス・ アドバイザなどの他のアドバイザへの入力ソースとしてのSQLワークロードの再使用

関連項目:

テスト・システムの設定

本番システムでSQLチューニング・セットにSQLワークロードを取得したら、ワークロードを取得したデータベースと同じデータベースまたは異なるデータベースでSQLパフォーマンス・アナライザの分析を実行できます。 分析ではリソースが多く消費されるため、本番データベースでワークロードを取得して、分析を実行できる別のテスト・データベースに転送することをお薦めします。これを行うには、SQLチューニング・セットを本番システムからエクスポートし、システム変更をテストする別のシステムにインポートします。

テスト・データベースを作成する方法はいくつもあります。たとえば、Recovery Manager(RMAN)のDUPLICATEコマンド、Oracle Data Pumpまたはトランスポータブル表領域を使用できます。RMANではテスト・データベースを既存のバックアップまたはアクティブな本番データ・ファイルから作成できるため、RMANを使用することをお薦めします。本番データベースとテスト・データベースは、同じホストまたは異なるホストのいずれにも存在できます。

可能なかぎり本番システムのデータベース環境と一致するようにテスト・データベース環境を構成する必要があります。これによって、システム変更がSQLパフォーマンスに与える影響をSQLパフォーマンス・アナライザでより正確に予測できるようになります。

テスト・システムを適切に構成したら、SQLチューニング・セットを本番システムからステージング表にエクスポートし、次にステージング表からテスト・システムにインポートします。

関連項目:

SQLパフォーマンス・アナライザ・タスクの作成

SQLワークロードを取得してテスト・システムに転送し、初期化データベース環境を適切に構成したら、SQLパフォーマンス・アナライザを実行して、システム変更がSQLパフォーマンスに与える影響を分析できます。

SQLパフォーマンス・アナライザを実行するには、まずSQLパフォーマンス・アナライザのタスクを作成する必要があります。タスクは、SQLパフォーマンス・アナライザの完全な分析に関するすべてのデータがカプセル化されているコンテナです。SQLパフォーマンス・アナライザの分析は、2つ以上のSQL試行と1つの比較で構成されています。SQL試行で、特定の環境条件下でのSQLチューニング・セットの実行パフォーマンスがカプセル化されます。SQLパフォーマンス・アナライザのタスクを作成する場合は、入力ソースとしてSQLチューニング・セットを選択する必要があります。テスト実行または実行計画の方法でSQL試行を構築する場合、SQL文のソースとしてSQLチューニング・セットが使用されます。SQLパフォーマンス・アナライザは、2つの試行間での環境の相違による影響を表示します。

関連項目:

データベース管理

この項では、データベース管理の新機能および拡張機能について説明します。

  • Enterprise ManagerでのSQLパフォーマンス・アナライザの拡張: Enterprise Managerでは、次のSQLパフォーマンス・アナライザ(SPA)の拡張が使用できるようになりました。
    • Oracle Javascript Extension Toolkit (JET)を使用したSPAタスクおよびトライアルの作成と表示のための最新化されたUI
      • タスクおよび試行の概要: 最近のレポートおよび最近作成されたタスクを表示する新しいグラフィカル・チャートで、より適切な概要が表示されます。
      • 統合ユーザー・エクスペリエンス: 変更の種類に関係なく、新しいタスクを作成するためのワークフローは同じです。
      • 柔軟性の向上: 基本モードは最小限の入力で使用できますが、拡張モードでは柔軟性が向上し、個々のタスクに対してEXECUTE_FULLDMLやWORKLOAD_IMPACT_THRESHOLDなどの構成パラメータを変更できます。
      • 合理化および時間の節約: 複数のメトリックに関するレポートを同時に生成する機能。レポートにアクセスすることなく、SPAタスクの結果の概要を提供します。
      • 新規ワークフロー: 移行用に最適化されたワークフロー。
    • SPAタスクおよび試行のパフォーマンス強化。計画変更のある文のみを実行し、文をパラレルに実行できるため、実行時間を短縮する新しいハイブリッド・ワークフローが含まれます。

    これらの拡張機能は、Oracle Enterprise Manager 24aiリリース1更新1 (24.1.0.1)以降で使用可能です。

  • Autonomous Databasesのガイド付き検出プロセス: ガイド付きプロセスを使用してAutonomous Databasesを検出できるようになりました。この簡略化されたプロセスでは、複数のAutonomous Databasesを同時に検出すること、高度な検索機能の使用によってAutonomous Databasesをフィルタして検索すること、およびEnterprise ManagerコンソールでOracle Cloud Infrastructureのリージョンおよびコンパートメントをナビゲートすることができます。

    詳細は、『Oracle Enterprise Manager Oracle Autonomous Databases管理者ガイド』のガイド付きプロセスの使用によるホスト以外のターゲットとしてのAutonomous Databasesの検出を参照してください。

  • 「パフォーマンス・ハブ」の「自動データベース診断モニター(ADDM)」タブ: 「パフォーマンス・ハブ」の「ADDM」タブを使用して、ADDMによって格納された情報にアクセスできるようになりました。ADDMでは、AWRデータの定期的な分析、パフォーマンス問題の根本原因の特定、問題を修正するための推奨事項の提供、および問題のないアプリケーション領域の識別が実行されます。AWRはパフォーマンスに関する履歴データのリポジトリであるため、ADDMを使用すると、イベント発生後のパフォーマンス問題を分析でき、多くの場合、問題を再現するために必要な時間とリソースの節約になります。

    詳細は、Oracle Cloud Infrastructureドキュメントで自動データベース診断モニター(ADDM)を参照してください。

  • 「ADDMスポットライト」での新しいスイム・レーンビジュアライゼーション: 「ADDMスポットライト」内の、スイム・レーンビジュアライゼーションでは、選択した時間範囲について集計された時系列データを使用して、ADDMタスクの全体的な影響(%)に基づいて結果が表示されます。このビジュアライゼーション・オプションを使用するには、「結果」タブ内の「サマリー」チャートの右上隅にあるスイム・レーンアイコン (スイム・レーン)アイコンをクリックします。スイム・レーンビジュアライゼーションでは、バブルのサイズによって結果の全体的な影響が示され、各バブルの上にマウスを置くと、分析期間および結果に関する詳細情報を確認できます。
  • Enterprise Managerでのデータ・マスキングとサブセット化の機能強化: Enterprise Managerで次のOracle Data Masking and Subsettingの拡張機能を使用できるようになりました。

    • Oracle Javascript Extension Toolkit (JET)によるデータ検出およびデータ・マスキングのための最新化されたUI

      • 統合されたコンソール・エクスペリエンス: Data Discovery and Data Maskingの主要コンポーネントである「概要」、「データ検出」、「データ・マスキング」および「データ・サブセッティング」すべてを、1つの合理化されたインタフェース内で、簡単に切り替えることができます。

      • 簡素化されたナビゲーション: 再編成されたメニューを使用して機能にアクセスし、各コンポーネント内で直感的に直接ナビゲーションできます。

      • ワークフロー図: 新しく導入された明確でわかりやすい図を使用して、一般的なワークフローを視覚化します。

      • エンタープライズレベルの概要ダッシュボード: まったく新しい「Data Masking and Subsettingの概要」ダッシュボードでインサイトを得ます。データベース全体の検出およびマスキング・アクティビティを効果的に管理するためのメトリックが提供されます。

    • データ検出およびデータ・マスキングのためのUIパフォーマンス機能拡張

      • 最適化されたワークフロー実行: リクエストされた操作に必要なデータのみをロードし、リソース使用率とユーザー待機時間を削減することで、不要な遅延なしでワークフローを実行できます。
      • レスポンシブ・デザイン: 様々なサイズのデバイスにシームレスに適応するUIを使用して、デスクトップ、タブレットおよびスマートフォンにわたり一貫したエクスペリエンスを実現します。
      • ワークフロー実行の高速化: マスキング・フォーマットまたは定義の作成、Oracle JET UIの活用、および遅延ロードの最適化などの操作に、改善されたフロー実行時間を使用できます。
      • 改善されたフィルタリング: データのロードによってさらに高速なクライアント側検索を使用して、サーバー側フィルタリングへの依存性をなくします。
      • 一括操作のサポート: 一括操作(機密列の一括での追加など)により、簡略化された繰返しタスクを実行して、クリックと労力を最小限にできます。
      • 直感的なマスキング・フォーマット作成: フォーマット・エントリの再編成でのドラッグ・アンド・ドロップのサポートにより、カスタム・マスキング・フォーマットの作成に、簡略化されたワークフローを使用できます。

    詳細は、Oracle AI Data Masking and Subsettingガイドのデータ・マスキングおよびサブセット化についてを参照してください。

  • Raftベースのシャーディングを監視するための新しいメトリック: Oracle AI Database 26ai以降では、次のメトリックを使用してEnterprise Managerでのシャード・レプリケーション・ユニットを監視できるようになりました:
    • グローバル分散データベースの場合
      • シャード・レプリケーション・ユニットのサマリー: Oracle Globally Distributed Databaseでのレプリケーション・ユニットのサマリーを提供します。
    • プラガブル・データベースの場合
      • シャード適用ラグ: シャード・レプリケーション適用コーディネータ・プロセスおよびレプリケーション・ユニット適用ラグに関する情報を提供します。
      • シャード・レプリケーション・ユニット: シャード内のレプリケーション・ユニットの詳細を提供します。
      • シャード・トランスポート・ラグ: シャード・レプリケーション・トランスポート・ラグに関する情報を提供します。

    詳細は、Oracle Enterprise Manager Oracle AI Databaseメトリック・リファレンス・マニュアルのグローバル分散データベースおよびプラガブル・データベースを参照してください。

変更前のSQLパフォーマンスの測定

システム変更を行う前に、変更前のSQL試行を作成します。 SQLパフォーマンス・アナライザでのSQL試行に必要なパフォーマンス・データは、次に示す方法で生成できます。

  • テスト実行

    この方法では、SQLパフォーマンス・アナライザを介してSQL文をテスト実行します。SPAパフォーマンス・アナライザを実行しているデータベースまたはリモート・データベースで実行できます。

  • 実行計画

    この方法では、SQLパフォーマンス・アナライザを介してSQL文に対してのみ実行計画を生成します。SPAパフォーマンス・アナライザを実行しているデータベースまたはリモート・データベースで実行できます。EXPLAIN PLAN文と異なり、実行計画の方法を使用するSQL試行ではバインド値が考慮され、実際の実行計画が生成されます。

  • SQLチューニング・セットの変換

    この方法では、SQLチューニング・セットに格納されている実行統計と計画を変換します。この方法はAPIでのみサポートされています。

テスト実行の方法では、ワークロードに含まれている各SQL文が完了するまで実行されます。実行中、SQLパフォーマンス・アナライザによってワークロードのSQL文ごとに実行計画が生成され、実行統計が計算されます。SQLチューニング・セット内の各SQL文は、SQL文の初期の実行順序または同時実行性を維持せずに、その他のSQL文とは別に実行されます。これは、実行タイムアウトが発生するまで可能なかぎり多く(最大10回)、SQL文ごとに2回以上実行されます。最初の実行は、バッファ・キャッシュの準備のために使用されます。以降のすべての実行は、平均に基づいてSQL文の実行時の実行統計を計算するために使用されます。SQL文が実行される実際の回数は、SQL文の実行時間の長さによって異なります。実行時間が長いSQL文は2回だけ実行され、この実行から得られた実行統計が使用されます。その他の(比較的時間の短い)SQL文は複数回実行され、これらの実行から実行統計の平均が計算されます(最初の実行で得られた統計は計算に使用されません)。複数の実行の統計の平均を求めることで、SQLパフォーマンス・アナライザは各SQL文の実行統計をより正確に計算できます。データベースが受ける可能性がある影響を回避するために、DDLはサポートされていません。デフォルトでは、DMLの問合せ部分のみが実行されます。APIを使用する場合は、EXECUTE_FULLDMLタスク・パラメータを使用することでDML全体を実行できます。パラレルDMLはサポートされておらず、パラレル・ヒントが削除されないかぎり、その問合せ部分は実行されません。

サイズによっては、SQLワークロードの実行に時間およびリソースが大量に消費される可能性があります。実行計画の方法では、実行統計を収集せずに、実行計画のみの生成を選択することができます。この方法によって、試行を実行する時間が短縮され、システム・リソースへの影響が減少しますが、分析時に使用できるのは実行計画のみのため、包括的なパフォーマンスの分析は実行できません。ただし、EXPLAIN PLANコマンドで計画を生成した場合とは異なり、SQLパフォーマンス・アナライザから、実行計画の生成時にオプティマイザにバインド値が提供されるため、SQL文の実行時に計画の結果に関してより信頼性の高い予測が得られます。

どちらの場合も、データベース・リンクを使用して、別のデータベースでSQLワークロードをリモートで実行することができます。SQLパフォーマンス・アナライザによって、データベース・リンクを介してリモート・データベースへの接続が確立され、そのデータベースでSQL文が実行され、SQL文ごとの実行計画およびランタイム統計が収集されて、ローカル・データベースのSQL試行に以降の分析で使用可能な結果が格納されます。この方法は、次の操作を行う場合に有効です。

  • データベースのアップグレードのテスト

  • 別のバージョンのOracle AI Databaseが実行されているシステムでのSQLワークロードの実行

  • 別のテスト・システムへのSQLパフォーマンス・アナライザの分析結果の格納

  • ハードウェア構成が異なる複数のシステムでのテストの実行

  • 本番システムで古いバージョンのOracle AI Databaseを使用している場合のSQLパフォーマンス・アナライザの最新機能の使用

SQLワークロードを実行すると、生成された実行計画およびランタイム統計がSQL試行に格納されます。

SQLチューニング・セットに格納されている実行統計および計画を使用して、SQL試行を作成することもできます。この方法は、APIでのみサポートされていますが、ワークロードを実行する別の方法(データベース・リプレイまたは別のアプリケーション・テスト・ツール)があり、テスト・システムでワークロードを実行するためにSQLパフォーマンス・アナライザが必要ない場合に有効なことがあります。このような場合でも、テストの実行中にSQLチューニング・セットを取得すると、SQLパフォーマンス・アナライザを使用してこれらのSQLチューニング・セットからSQL試行を作成し、より包括的な分析レポートを表示することができます。標準のSQLパフォーマンス・アナライザ・レポート(各試行内の実行計画は1つのみで、1セットのバインドでSQL文を実行して生成される実行統計は1セット)とは異なり、SQLチューニング・セットから作成したSQL試行を比較するレポートを生成して、複数の実行にわたって潜在的に多数の異なるバインド・セットが存在する2つの試行からすべての実行計画を表示することができます。

関連項目:

システム変更の実行

測定対象のSQLパフォーマンスにかかわる変更を行います。SQLパフォーマンス・アナライザでは、様々なタイプのシステム変更による影響を分析できます。 たとえば、データベースのアップグレード、新しい索引の作成、初期化パラメータの変更、オプティマイザ統計のリフレッシュなどをテストできます。本番システムでSQLパフォーマンス・アナライザを実行する場合は、残りのシステムへの影響を回避するためにプライベート・セッションを使用して変更を行うことを検討してください。

変更後のSQLパフォーマンスの測定

システム変更の実行後、変更後のSQL試行を作成します。 変更後のSQL試行は、変更前のSQL試行と同じ方法を使用して作成することを強くお薦めします。作成すると、変更後のSQL試行に新しいパフォーマンス・データセットが生成され、変更前のバージョンと比較可能になります。この結果は、新しいSQL試行または変更後のSQL試行に保存されます。

関連項目:

パフォーマンス測定値の比較

SQLパフォーマンス・アナライザでは、変更前と変更後のSQL文のパフォーマンスが比較され、SQL文の実行計画またはパフォーマンスでの変更を特定するレポートが生成されます。

SQLパフォーマンス・アナライザは、SQLワークロード全体の実行時間とワークロード内の個々のSQL文のレスポンス時間について、システム変更による影響を測定します。デフォルトでは、SQLパフォーマンス・アナライザは、比較のメトリックに経過時間を使用します。また、次のSQL実行統計の中から比較のメトリックを選択できます。

  • CPU時間

  • ユーザーI/O時間

  • バッファ読取り

  • 物理I/O

  • オプティマイザ・コスト

  • I/Oインターコネクト・バイト

  • 式形式でのこれらメトリックの組合せ

SQL試行で実行計画のみを生成する場合、SQLパフォーマンス・アナライザではSQL実行計画に格納されているオプティマイザ・コストが使用されます。

比較が完了すると、変更前と変更後のSQLパフォーマンスを比較するSQLパフォーマンス・アナライザ・レポートに結果のデータが生成されます。SQLパフォーマンス・アナライザ・レポートは、HTML、テキストまたはアクティブ・レポートとして表示できます。アクティブ・レポートには、インタラクティブなユーザー・インタフェースを使用するきめ細かなレポート機能が用意されており、データベースやOracle Enterprise Managerに接続されていないときでも詳細な分析を実行できます。

関連項目:

  • パフォーマンス測定値の比較とレポートの詳細は、「SQL試行の比較」を参照してください

低下したSQL文の修正

SQLパフォーマンス・アナライザが実行したパフォーマンス分析でSQL文の低下が見つかった場合は、変更を行って問題を解決します。 たとえば、SQLチューニング・アドバイザを実行するか、またはSQL計画ベースラインを使用して、パフォーマンスが低下したSQLを修正できます。その後、SQL文の実行プロセスを繰り返し、そのパフォーマンスを最初の実行と比較できます。満足できる分析結果になるまで、これらのステップを繰り返します。

関連項目: