機械翻訳について

問合せパフォーマンスのチューニング

問合せのパフォーマンスを調整して、問合せを最適化し、問合せの実行時間を高速化できます。

問合せとパフォーマンスについて

分析が実行されると、データベースの集計および処理に優先順位が付けられ、処理を増やすために「BIサーバー」に可能なかぎり少ないデータが送信されます。 分析を作成する際は、この原則を堅持してパフォーマンスを最大化する必要があります。

問合せの実行時に、発生する3つのフェーズを次に示します。

  1. SQLコンパイル。
  2. データベースSQLの実行
  3. 結果セットが取得され、分析に表示されます。

問合せの実行時に発生するステップを含む問合せアーキテクチャを次に示します。

otbi_query_arch_phases.pngの説明が続きます
図otbi_query_arch_phases.pngの説明
フェーズ ステップ 説明
1 1 1つ以上のサブジェクト領域の列を使用して分析を作成し、適切なフィルタおよびグラフを追加して実行します。
1 2 「プレゼンテーション・サービス」はリクエストを受信し、サブジェクト領域および列に基づいて論理SQL文を「BIサーバー」に送信します。
1 3 「BIサーバー」は次のことを実行します:
  1. メタデータ・リポジトリでマップされたビュー・オブジェクトおよびビュー・リンクと論理SQLが相互に関連付けられます。
    • SQLがWebLogic ADFレイヤーに移動して、ビュー・オブジェクトおよびビュー・リンクのSQL定義が取得されます。
    • Oracle Fusion Cloud Applicationsセキュリティは、これらのSQL定義に適用されます。
  2. ビュー・オブジェクト問合せが集計されて、物理データベースSQLが作成されます。
2 4 集計やデータ・セキュリティを含むデータベース問合せがデータベースで実行されます。
2 5 集計されたデータセットがBIサーバーに戻され、その結果がマージされ、追加の計算またはフィルタが適用されます。
3 6 最終データセットは「プレゼンテーション・サービス」に戻され、表示用に書式設定されて分析に表示されます。

問合せのパフォーマンスの最大化

分析の設計方法は、「BIサーバー」が物理問合せをどのように構築するかに影響します。これにより、パフォーマンスを最大化するためにデータベースにどのくらいの処理が集中しているかが決まります。

ここでは、アドホック分析を作成する際に、いくつかのファクタを考慮する必要があります。

分析のパフォーマンスを改善するためには、次の点が重要です。

  • 必要なサブジェクト領域と列のみを選択してください。 選択内容によって、データベース問合せで使用するビュー・オブジェクトとデータベース表が決まります。 不要な表があれば、処理対象の問合せや結合が増えます。
  • 適切なフィルタを追加してデータベースの索引を使用し、BIサーバーに返される結果データを削減します。
  • 不要なビジュアル・グラフを削除します。
  • 使用されていないデータ列を削除します。 ビジュアル・グラフで使用されていない列が物理SQLの実行に含まれると、データベース問合せの処理オーバーヘッドが増加する場合があります。

問合せのパフォーマンスを低下させる可能性がある要因と、その改善のために何ができるかを次に示します。

ファクタ 説明 提案
セキュリティ 広範なセキュリティ権限があるユーザーの場合は分析のパフォーマンスがよくなり、制限がある場合は悪化する場合があります。 セキュリティをレビューして簡素化します。 ロールの数を最小限に抑え、データ・セキュリティを強制するために複雑なカスタム問合せを使用しないようにします。
サブジェクト領域間 複数のサブジェクト領域を含む分析は、パフォーマンスに影響を与える可能性があります。 分析をレビューして、問合せのサブジェクト領域をいくつか削除できるかどうかを検討してください。 すべてのサブジェクト領域が必要ですか。 分析を作成したときに、特定のサブジェクト領域の追加中にパフォーマンスに影響がありましたか。
階層 階層(特に大きい階層)は、パフォーマンスに影響を与える可能性があります。

ツリーおよびマネージャなどの階層ディメンションに対する問合せは、パフォーマンスに影響を与えることがあります。 「BIサーバー」では、列フラット化アプローチを使用して、階層内の特定のノードのデータをすばやくフェッチします。 ただし、階層の異なるレベルについては事前集計されません。

階層を削除して、パフォーマンスが向上するかどうかを確認してください。 すべての問合せを慎重に作成し、十分なフィルタを適用して、結果セットを小さく維持することも重要です。
属性数 多くの場合、不必要な大量の列が分析で使用されています。 基準内の列数をできるだけ少なくしてください。
フレックスフィールド 分析で使用するフレックスフィールドが多すぎると、パフォーマンスが低下する場合があります。 フレックスフィールドを削除して、パフォーマンスが向上するかどうかを確認します。 フィルタでフレックスフィールドを使用しないでください。
データ量 大量のデータの問合せに時間がかかるかを分析します。 すべてのレコードを問い合せる場合もありますが、数行のみを返すため、データベースまたは「BIサーバー」で多くの処理が必要になります。 特にデータベース内の索引がある列について、分析にフィルタを追加することを検討してください。

ブラインド問合せはフィルタなしで実行され、大規模なデータsets.All問合せを大きいトランザクション表に対してフェッチする必要があるため、時間制限を回避してください。 たとえば、時間ディメンション・フィルタと、就業者などのキー・ディメンションによって制限する追加フィルタを含めます。 トランザクション表のデータベース索引がある列にフィルタを適用します。 これにより、「BIサーバー」から問合せに対して適切な実行計画が生成されます。

副問合せ(NOT IN、IN) 別の問合せの結果に基づいてIN (またはNOT IN)のフィルタを適用すると、メイン問合せのすべての行に対して副問合せが実行されます。 NOT INまたはINの問合せを論理和集合演算子または論理SQLで置換します。
計算メジャー メジャーの計算には、多くのデータの問合せが含まれる場合があります。 可能な場合は、サブジェクト領域で事前定義済のメジャーを使用します。
フィルタ フィルタまたはフィルタがない分析で大量のデータが致命的になると、パフォーマンスが低下する可能性があります。 フィルタを追加し、フィルタ列に関数またはフレックスフィールドを適用しないようにします。 可能な場合は、フィルタに索引付き列を使用します。

オファリングのOTBIサブジェクト領域の系統を参照し、各サブジェクト領域の索引付けされた列をドキュメント化します。

My Oracle Support (ドキュメントID 2679006.1)の分析およびレポートの考慮事項に関する詳細なガイドラインを確認します。

サブジェクト領域を使用したパフォーマンスの診断

これらの例は、OTBI Usage Real TimeおよびPerformance Real Timeサブジェクト領域を使用して使用状況とパフォーマンスを理解する方法を示しています。これにより、パフォーマンスのボトルネックを診断し、分析の実行速度が遅いか最適化できるかを理解できます。

OTBI使用状況リアルタイム・サブジェクト領域は、ユーザー、分析およびダッシュボード、サブジェクト領域別にOTBIの使用状況トレンドを監視します。 OTBIパフォーマンス・リアルタイム・サブジェクト領域は、使用状況、分析実行時間、実行エラーおよびデータベース物理SQL実行統計を監視します。 「OTBIの使用およびパフォーマンス・サブジェクト領域のリファレンス」を参照してください。

OTBIの使用サブジェクト領域は、2つのジョブ・ロール用にプロビジョニングされます: ITセキュリティ・マネージャおよびアプリケーション実装コンサルタント。 これらを他のジョブ・ロールに使用するには、セキュリティ・コンソールでOTBI使用トランザクション分析職務およびOTBIパフォーマンス・トランザクション分析職務をカスタム・ジョブ・ロールに付与します。 各サブジェクト領域のセキュリティ詳細を確認するには、特定のサブジェクト領域ガイドを参照してください。

ユーザー数の分析

この例を使用して、ユーザー数がパフォーマンスに影響する可能性があるかどうかを理解します。

この例では、OTBIにアクセスしているユーザーの現在の数を決定する分析、および長時間実行問合せの傾向を識別するヒストグラム分析を作成します。

  1. 「レポートおよび分析」作業領域で「作成」をクリックし、「分析」を選択します。 OTBI使用リアルタイム・サブジェクト領域を選択し、「続行」をクリックします
  2. 「列の選択」ページで、サブジェクト領域およびフォルダを展開します。 「ファクト - 使用状況メトリック」フォルダからユーザー数を選択し、「次」をクリックします。 分析にディメンションを含めていないため、すべてのユーザーの合計が表示されます。
  3. 「ビューの選択」ページで、表ビューを選択し、「次」をクリックします。
  4. 残りのページで、「次」をクリックしてデフォルト値を受け入れます。
  5. 「保存」ページで、分析の名前を入力し、保存するカタログ・フォルダを選択して「送信」をクリックします。

    その結果、システム上のユーザー数を含む単一列の表が作成されます。 この分析を絞り込むには、OTBIレポート・フォルダの「レポート名」列と「レポート・パス」列を分析に追加して、使用中のレポートを決定します。

問合せパフォーマンスの分析

この例を使用して、パフォーマンスのボトルネックを診断し、分析の実行速度が遅いか、最適化できるかを把握します。

  1. 「レポートおよび分析」作業領域で「作成」をクリックし、「分析」を選択します。 OTBIパフォーマンス・リアルタイム・サブジェクト領域を選択し、「続行」をクリックします
  2. 「列の選択」ページで、サブジェクト領域およびフォルダを展開します。 OTBIレポート・フォルダから「レポート名」を選択し、「次」をクリックします。
  3. 「ファクト - パフォーマンス・トラッキング」フォルダの「導出されたメトリック」フォルダから合計実行時間を2回追加します。
  4. 問合せ実行メトリック・フォルダからレポート行数を追加します。 「次」をクリックします
  5. 問合せ実行メトリック・フォルダからレポート数を追加します。 「次」をクリックします
  6. 「ビューの選択」ページで、ピボット・ビューを選択して「次」をクリックします。
  7. 残りのページで、「次」をクリックしてデフォルト値を受け入れます。
  8. 「保存」ページで、分析のパフォーマンス・ヒストグラムに名前を付け、マイ・フォルダを選択して、「送信」をクリックします。
  9. 「カタログ」をクリックし、カタログでマイ・フォルダに移動し、分析の「編集」をクリックします。
  10. 「条件」タブを選択します。 「オプション」をクリックし、最初の合計実行時間列で「昇順ソート」を選択します。
  11. 2番目の実行時間の「オプション」をクリックし、「式の編集」を選択します。 式の編集ダイアログで、カスタム見出し合計実行時間ビンと入力し、列式に実行時間の範囲(5秒未満から5分を超える範囲)でbinまでの次の文を入力します:
    CASE WHEN "Derived metrics"."Total Execution Time" <= 5 THEN 'Less than 5Seconds' WHEN "Derived metrics"."Total Execution Time" BETWEEN 5 AND 30 THEN'Between 5 and 30 Seconds' WHEN "Derived metrics"."Total Execution Time"BETWEEN 30 AND 60 THEN 'Between 30 and 60 seconds' WHEN "Derived metrics"."Total Execution Time" BETWEEN 60 AND 120 THEN 'Between 60 and 120 seconds' WHEN "Derived metrics"."Total Execution Time" BETWEEN 120 AND 300 THEN 'Between 120 and 300 seconds' ELSE 'Greater than 300 seconds' END
  12. 「結果」タブで、ピボット表の「ビューの編集」をクリックします。
  13. ピボット表エディタのレイアウト」・ペインで、次のようにします。
    • 「合計実行時間ビン」列を行セクションに移動します。
    • レポート数をメジャー・セクションに移動します。
    • 残りの列を「除外」セクションに移動して、ピボット表に表示されないようにします。
  14. 「完了」をクリックします。

    この情報をグラフまたは表として表示して、実行時間が長すぎるレポートの数を表示できます。 使用率が最も高く、実行時間が最も長いものに優先順位を付けることができます。

レポートのパフォーマンスのチューニング

SQL問合せチューニングを使用して、レポートのパフォーマンスを改善できます。

問合せのパフォーマンスを低下させる可能性があるいくつかの要因と、改善のための提案を次に示します。

ファクタ 説明 提案
フィルタ 大量のデータを許容するフィルタを使用するレポートや、フィルタを使用しないレポートでは、パフォーマンスが悪化する可能性があります。 データを制限するには、フィルタ条件を使用します。
結合 多数の表を結合するレポートの実行速度は遅くなる可能性があります。 不要な結合があれば削除します。
データ量 大量のデータを許容するフィルタを使用するレポートや、フィルタを使用しないレポートでは、パフォーマンスが悪化する可能性があります。 データを制限するためのフィルタ条件を追加します。可能な場合はデータベース索引のある列を使用します。 小さい表にはキャッシュを使用します。
索引 データベース索引を使用するフィルタにより、パフォーマンスを向上させることができます。 SQLヒントを使用して、使用する索引を管理します。
サブクエリー サブクエリーはパフォーマンスに影響を与える可能性があります。
  • 複雑なサブクエリーを避け、必要に応じてグローバル一時表を使用します。
  • 可能であれば、WHERE句のサブクエリーが多すぎないようにしてください。 かわりに、外部結合を使用して問合せをリライトします。
集計 これは、データベース内の集計に優先順位を付けるのに役立ちます。
  • 複数の集計にはOracle SQL分析関数を使用します。
  • 複雑な集計関数には、CASE文およびDECODE関数を使用します。

分析で使用されるSQL文のレビュー

次のステップを使用して、論理SQL文および物理SQL文を確認できます。

論理SQLは、分析のために「BIサーバー」に発行されるソース固有のSQLではありません。 論理問合せでは、リポジトリ(RPD)メタデータのプレゼンテーション・レイヤーのサブジェクト領域からの列名を使用します。 論理リクエストに基づいて、「BIサーバー」は、最適化されたソース固有のSQLを、メタデータの物理レイヤーの実際のデータ・ソースに発行します。 管理権限がある場合、分析のための論理SQLと物理SQLの両方をレビューできます。

  1. 分析の編集時に論理SQLを表示する場合:
    1. レポートおよびアナリティクス作業領域で、「編集」をクリックしてアナリティクスを編集のために開き、「拡張」タブをクリックします。
    2. 「発行されたSQL」セクションで、論理SQL文を確認します。
  2. 「管理」ページからSQL文を表示する場合。
    1. 「自分のプロファイル」をクリックし、「管理」をクリックします。
    2. 「管理」ページの「セッション管理」セクションで、「セッションの管理」リンクをクリックします。

      管理および「セッションの管理」ページにアクセスするには、Business Intelligence管理者である必要があります。

    3. 「セッションの管理」ページの「アクション」列で、「ログの表示」リンクをクリックしてSQL文を確認します。