針對 Power BI Desktop 中的 DirectQuery 模型問題進行疑難排解

本文可協助您診斷在 Power BI Desktop 或 Power BI 服務中開發的 Power BI DirectQuery 資料模型的效能問題。 本文也會描述如何取得詳細資訊，以協助您最佳化報表。

您應該在 Power BI Desktop 中 (而不是在 Power BI 服務或 Power BI 報表伺服器中) 開始任何效能問題的診斷。 效能問題通常取決於基礎資料來源的效能層級。 您可以在隔離的 Power BI Desktop 環境中更輕鬆地識別和診斷這些問題，而不會牽涉到內部部署閘道等元件。

如果您在 Power BI Desktop 中找不到效能問題，您可以將調查焦點放在 Power BI 服務中的報表細節。

在查看頁面上的許多視覺效果之前，您也應該嘗試將問題隔離到個別視覺效果。

效能分析器

效能分析器是用來識別疑難排解程序中效能問題的實用工具。 如果您可以在 Power BI Desktop 的頁面上識別單一緩慢的視覺效果，您可以使用效能分析器來判斷 Power BI Desktop 傳送至基礎來源的查詢。

您也可以檢視基礎資料來源發出的追蹤和診斷資訊。 這類追蹤可以包含查詢執行方式的詳細資料，以及如何加以改善的實用資訊。

即使沒有來源的追蹤，您也可以檢視 Power BI 傳送的查詢及其執行次數。

注意

針對 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 Database
• Azure Synapse Analytics (先前稱為 SQL 資料倉儲)
• Oracle
• Teradata
• SAP HANA

若要輕鬆找到追蹤資料夾，請在 Power BI Desktop 中，選取 [檔案] > [選項及設定] > [選項]，然後選取 [診斷]。

在 [損毀傾印收集] 下，選取 [開啟損毀傾印/追蹤資料夾] 連結，以開啟 <User>\AppData\Local\Microsoft\Power BI Desktop\Traces 資料夾。

瀏覽至該資料夾的上層資料夾，然後開啟 AnalysisServicesWorkspaces 資料夾，其包含一個 workspace 子資料夾，用於 Power BI Desktop 每個開啟的執行個體。 子資料夾名稱具有整數尾碼，例如 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。

若要開啟追蹤檔案：

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 事件的一或多個配對，代表在評估 DAX 查詢過程中傳送至基礎資料來源的查詢。

多個 DAX 查詢可以平行執行，因此來自不同群組的事件可以相互交錯。 您可以使用 ActivityID 的值來判斷哪些事件屬於相同群組。

下列資料行也值得注意：

• TextData：事件的文字詳細資料。 Query Begin 和 Query End 事件的詳細資料是 DAX 查詢。 DirectQuery Begin 和 DirectQuery End 事件的詳細資料則是傳送至基礎來源的 SQL 查詢。 目前所選事件的 TextData 值也會出現在畫面底部的窗格中。
• EndTime：事件完成的時間。
• Duration：執行 DAX 或 SQL 查詢所花費的持續時間 (毫秒)。
• Error：是否發生錯誤，發生時事件也會以紅色顯示。

上圖會縮小一些較不有趣的資料行，讓您更容易看到更有趣的資料行。

請遵循此方法來擷取追蹤，以協助診斷潛在的效能問題：

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 資料表：

在 Power BI 視覺效果中，下列運算式會定義 SalesAmount 量值：

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

重新整理視覺效果會產生下圖中的 T-SQL 查詢。 Web_Sales、Item 和 Date_dim 模型資料表有三個子查詢。 儘管視覺效果只參考四個資料行，每個查詢都會傳回所有模型資料表資料行。

這些著色子查詢是 Power Query 查詢的確切定義。 使用此子查詢不會影響 DirectQuery 支援的資料來源效能。 SQL Server 等資料來源會直接最佳化，而不需要參考其他資料行。

Power BI 使用此模式的原因之一，是您可以定義 Power Query 查詢以使用特定的查詢陳述式。 Power BI 會直接使用所提供的查詢，不會嘗試改寫查詢。 此模式會禁止使用採用通用資料表運算式 (CTE) 及預存程序的查詢陳述式。 您無法在子查詢中使用這些陳述式。

閘道效能

如需如何疑難排解閘道效能問題的相關資訊，請參閱疑難排解閘道問題 - Power BI。

相關內容

如需 DirectQuery 的詳細資訊，請參閱下列資源：

• 在 Power BI Desktop 中使用 DirectQuery
• DirectQuery 支援的資料來源
• Power BI Desktop 中的 DirectQuery 模型
• Power BI Desktop 中的 DirectQuery 模型指南

有任何問題嗎？ 嘗試在 Power BI 社群提問