次の方法で共有

Power BI Desktop での DirectQuery モデルのトラブルシューティング

  • [アーティクル]

この記事は、Power BI Desktop または Power BI サービスで開発した Power BI DirectQuery データ モデルのパフォーマンスの問題を診断するのに役立ちます。 この記事では、レポートの最適化に役立つ詳細情報を取得する方法についても説明します。

パフォーマンスの問題の診断は、Power BI サービスまたは Power BI Report Server ではなく、Power BI Desktop で始める必要があります。 パフォーマンスの問題の多くは、基になっているデータ ソースのパフォーマンス レベルによるものです。 オンプレミス ゲートウェイなどのコンポーネントを含まない、分離された Power BI Desktop 環境では、これらの問題をより簡単に特定して診断できます。

Power BI Desktop でパフォーマンスの問題が見つからない場合は、Power BI サービスでレポートの詳細に調査の焦点を合わせることができます。

また、ページ上の多くの視覚エフェクトを調べる前に、個々の視覚エフェクトに問題を分離する必要もあります。

パフォーマンス アナライザー

パフォーマンス アナライザーは、トラブルシューティング プロセス全体を通してパフォーマンスの問題を特定するための便利なツールです。 Power BI Desktop でページに遅い視覚エフェクトが 1 つ見つかった場合、パフォーマンス アナライザーを使って、Power BI Desktop が基になるソースに送信しているクエリを特定できます。

また、基になるデータ ソースから出力されているトレースと診断情報を表示できる場合もあります。 このようなトレースには、クエリの実行方法とそれを改善する方法の詳細に関する有用な情報が含まれることがあります。

ソースからのトレースがなくても、Power BI が送信したクエリとその実行時間を表示できます。

Note

DirectQuery の SQL ベースのソースの場合、パフォーマンス アナライザーには SQL Server、Oracle、Teradata のデータ ソースに対するクエリだけが表示されます。

[トレース ファイル]

既定では、Power BI Desktop は特定のセッションの間のイベントを FlightRecorderCurrent.trc という名前のトレース ファイルに記録します。 現在のセッションのトレース ファイルは、現在のユーザーの AppData フォルダーにあります (<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces)。

次の DirectQuery データ ソースは、Power BI がそれに送信するすべてのクエリを、トレース ファイルに書き込みます。 今後、ログで他の DirectQuery ソースがサポートされる可能性があります。

  • SQL Server
  • Azure SQL データベース
  • Azure Synapse Analytics (旧称 SQL Data Warehouse)
  • Oracle
  • Teradata
  • SAP HANA

Power BI Desktop でトレース ファイル フォルダーに簡単にアクセスするには、[ファイル]>[オプションと設定]>[オプション] を選んで、[診断] を選びます。

Screenshot of the Diagnostics section of the Power BI Desktop Options screen with the link to open the crash dump/traces folder.

[クラッシュ ダンプの収集] で [クラッシュ ダンプ/トレース フォルダーを開く] リンクを選んで、<User>\AppData\Local\Microsoft\Power BI Desktop\Traces フォルダーを開きます。

そのフォルダーの親フォルダーに移動してから、AnalysisServicesWorkspaces フォルダーを開きます。そこには、Power BI Desktop の開いているインスタンスごとに 1 つのワークスペース サブフォルダーが含まれます。 サブフォルダーの名前には、整数のサフィックスが付いています (例: AnalysisServicesWorkspace2058279583)。

各 AnalysisServicesWorkspace フォルダーに含まれる Data サブフォルダーに、現在の Power BI セッションのトレース ファイル FlightRecorderCurrent.trc が含まれます。 関連付けられている Power BI Desktop セッションが終了すると、このフォルダーはなくなります。

SQL Server Profiler ツールを使ってトレース ファイルを開くことができます。これは、無料の SQL Server Management Studio (SSMS) ダウンロードの一部として取得できます。 SQL Server Management Studio をダウンロードしてインストールした後、SQL Server Profiler を開きます。

Screenshot of SQL Server Profiler window with no highlighted traces.

トレース ファイルを開くには:

  1. SQL Server Profiler で、[ファイル]>[開く]>[トレース ファイル] を選びます。

  2. 現在の Power BI セッションのトレース ファイルへのパスに移動するか、それを入力して (例: <User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data)、FlightRecorderCurrent.trc を開きます。

SQL Server Profiler に、現在のセッションからのすべてのイベントが表示されます。 次のスクリーンショットでは、クエリのイベントのグループが強調されています。 各クエリ グループには次のイベントが含まれます。

  • Query Begin と Query End イベントは、Power BI UI で視覚エフェクトまたはフィルターを変更することで、または Power Query エディターでのデータのフィルター処理または変換によって生成される、DAX クエリの開始と終了を表します。

  • DirectQuery Begin と DirectQuery End イベントの 1 つ以上のペアは、DAX クエリの評価の一部として基になるデータ ソースに送信されたクエリを表します。

Screenshot of SQL Server Profiler with highlighted Query Begin and Query End events.

複数の DAX クエリを並列に実行できるので、異なるグループからのイベントが間に挟まっている可能性があります。 ActivityID の値を使って、同じグループに属しているイベントを特定できます。

次の列も重要です。

  • TextData: イベントのテキスト形式の詳細です。 Query Begin と Query End イベントの場合、詳細は DAX クエリです。 DirectQuery Begin と DirectQuery End イベントの場合、詳細は基になるソースに送信された SQL クエリです。 現在選ばれているイベントの TextData の値は、画面の下部にあるペインにも表示されます。
  • EndTime: イベントが完了した時刻です。
  • Duration: DAX または SQL クエリの実行にかかった時間 (ミリ秒単位)。
  • Error: エラーが発生したかどうか。発生した場合は、イベントも赤で表示されます。

上の画像では、あまり関係のない一部の列が除外されているため、より重要な列をいっそう簡単に確認できます。

可能性のあるパフォーマンスの問題の診断に役立つトレースをキャプチャするには、次のようにします。

  1. 複数のワークスペース フォルダーで混乱するのを避けるために、1 つの Power BI Desktop セッションを開きます。

  2. Power BI Desktop で関心のあるアクションのセットを実行します。 さらにアクションをいくつか実行して、目的のイベントがトレース ファイルに確実にフラッシュされるようにします。

  3. SQL Server Profiler を開いて、トレースを調べます。 Power BI Desktop を閉じるとトレース ファイルが削除されることに注意してください。 また、Power BI Desktop でのその他のアクションはすぐに表示されません。 新しいイベントを表示するには、トレース ファイルを閉じてもう一度開く必要があります。

個々のセッションを適度な小ささ (数百秒ではなく 10 秒くらいのアクション) にします。 このアプローチを使用すると、トレースファイルをより簡単に解釈できます。 トレース ファイルのサイズにも制限があるため、セッションが長い場合は、最初の方のイベントが削除される可能性があります。

クエリとサブクエリの形式

Power BI Desktop のクエリの一般的な形式では、クエリが参照するモデル テーブルごとにサブクエリが使われます。 Power Query エディターのクエリで、サブセレクト クエリが定義されています。 たとえば、SQL Server のリレーショナル データベースに次のような TPC-DS テーブルがあるとします。

Screenshot of a Power BI Desktop model view diagram that shows the related Item, Web_Sales, Customer and Date-dim TPC-DS tables.

Power BI の視覚エフェクトでは、次の式によって SalesAmount メジャーが定義されています。


SalesAmount = SUMX(Web_Sales, [ws_sales_price] * [ws_quantity])

Screenshot of a Power BI Desktop stacked column chart that displays sales amount by category.

視覚エフェクトの更新では、次の図の T-SQL クエリが生成されます。 Web_Sales、Item、Date_dim の各モデル テーブルに対する 3 つのサブクエリがあります。 視覚エフェクトでは 4 つの列のみが参照されていますが、各クエリからはモデル テーブルのすべての列が返されます。

網掛けされたこれらのサブクエリが、Power Query のクエリの厳密な定義です。 サブセレクトをこのように使っても、DirectQuery がサポートするデータ ソースのパフォーマンスに影響はありません。 SQL Server などのデータ ソースでは、他の列への参照は最適化により除外されます。

Power BI でこのパターンが使われる理由の 1 つは、ユーザーが Power Query クエリを定義して、特定のクエリ ステートメントを使用できるためです。 Power BI では、指定したとおりにクエリが使われ、その書き換えは試みられません。 このパターンでは、共通テーブル式 (CTE) とストアド プロシージャを使うクエリ ステートメントの使用が制限されます。 これらのステートメントをサブクエリで使うことはできません。

Screenshot of a T-SQL query that shows embedded subqueries, one for each model table.

ゲートウェイ パフォーマンス

ゲートウェイのパフォーマンスのトラブルシューティングについては、「ゲートウェイのトラブルシューティング - Power BI」をご覧ください。

関連するコンテンツ

DirectQuery の詳細については、次のリソースを参照してください。

わからないことがある場合は、 Power BI コミュニティで質問してみてください。