針對 XMLA 端點連線能力進行疑難排解

Power BI 中的 XMLA 端點依賴原生的 Analysis Services 通訊協定來存取 Power BI 語意模型。 因此,XMLA 端點疑難排解會與針對一般 Analysis Services 連線進行疑難排解大致相同。 不過,某些特定於 Power BI 特定相依性的相關差異也適用。

開始之前

針對 XMLA 端點案例進行疑難排解之前,請務必檢閱使用 XMLA 端點連線至語意模型中所涵蓋的基本概念。 其中涵蓋最常見的 XMLA 端點使用案例。 其他 Power BI 疑難排解指南 (例如針對閘道進行疑難排解 - Power BI針對「使用 Excel 分析」進行疑難排解) 也很有幫助。

啟用 XMLA 端點

您可以同時在 Power BI Premium、Premium Per User 和 Power BI Embedded 容量上啟用 XMLA 端點。 在較小的容量 (例如,只有 2.5 GB 記憶體的 A1 容量) 中,您可能會在嘗試將 XMLA 端點設定為 [讀取/寫入],然後選取 [套用] 時,於 [容量設定] 中遇到錯誤。 此錯誤表示「您的工作負載設定發生問題。 請於稍後重試。」

以下是數個可嘗試的事項:

  • 將容量上其他服務的記憶體耗用量 (例如資料流程) 限制為 40% (或更少),或完全停用不必要的服務。
  • 將容量升級到較大的 SKU。 例如,從 A1 升級到 A3 容量即可解決此設定問題,而不需停用資料流程。

請記住,您也必須在 Power BI 管理入口網站中,啟用租用戶層級的匯出資料設定。 [使用 Excel 分析] 功能也需要此設定。

建立用戶端連線

啟用 XMLA 端點之後,在容量上測試與工作區的連線能力是個不錯的主意。 若要深入了解,請參閱連線到 Premium 工作區。 此外,請務必閱讀連線需求一節,以取得有關目前 XMLA 連線能力限制的實用秘訣和資訊。

使用服務主體連線

如果您已啟用租用戶設定,以允許服務主體使用 Power BI API (如啟用服務主體中所述),您就能夠使用服務主體連線到 XMLA 端點。 請記住,服務主體在工作區或語意模型層級上,需要具有與一般使用者相同層級的存取權限。

若要使用服務主體,請務必在連接字串中指定應用程式身分識別資訊,如下所示:

  • User ID=<app:appid@tenantid>
  • Password=<application secret>

例如:

Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:91ab91bb-6b32-4f6d-8bbc-97a0f9f8906b@19373176-316e-4dc7-834c-328902628ad4;Password=6drX...;

如果您收到下列錯誤:

「因為帳戶資訊不完整,所以我們無法連線到語意模型。 針對服務主體,確定您會使用格式應用程式,一起指定租用戶識別碼與應用程式識別碼:<appId>@<tenantId>,然後再試一次。」

確定您會使用正確的格式,一起指定租用戶識別碼與應用程式識別碼。

指定應用程式識別碼但不指定租用戶識別碼也同樣有效。 不過,在此情況下,您必須以實際的租用戶識別碼取代資料來源 URL 中的 myorg 別名。 Power BI 接著可在正確的租用戶中尋找服務主體。 但最佳做法是使用 myorg 別名,並在使用者識別碼參數中,一起指定租用戶識別碼和應用程式識別碼。

使用 Microsoft Entra B2B 連線

透過支援 Power BI 中的 Microsoft Entra 企業對企業 (B2B),您可以為外部來賓使用者提供透過 XMLA 端點存取語意模型的權限。 請確定已在 Power BI 管理入口網站中,啟用與外部使用者共用內容設定。 若要深入了解,請參閱使用 Microsoft Entra B2B 將 Power BI 內容散發給外部來賓使用者

部署語意模型

您可以將 Visual Studio (SSDT) 中的表格式模型專案部署至指派給 Premium 容量的工作區,方式與部署至 Azure Analysis Services 大致相同。 不過,部署時,還有一些額外考量。 請務必檢閱《使用 XMLA 端點連線至語意模型》一文中的從 Visual Studio (SSDT) 部署模型專案一節。

部署新模型

在預設設定中,Visual Studio 會在部署作業期間嘗試處理模型,以便將來自資料來源的資料載入到語意模型。 如從 Visual Studio (SSDT) 部署模型專案中所述,此作業可能會失敗,因為無法在部署作業期間指定資料來源認證。 相反地,如果您尚未針對任何現有語意模型定義資料來源的認證,您就必須使用 Power BI 使用者介面 ([語意模型]>[設定]>[資料來源認證]>[編輯認證]),在語意模型設定中指定資料來源認證。 定義資料來源認證之後,Power BI 就可以在中繼資料部署成功且已建立語意模型之後,針對任何新的語意模型自動將認證套用到此資料來源。

如果 Power BI 無法將您的新語意模型繫結至資料來源認證,您將會收到錯誤,指出「無法處理資料庫。 原因:無法將修改儲存至伺服器。」錯誤碼為 "DMTS_DatasourceHasNoCredentialError",如下所示:

模型部署錯誤

若要避免處理失敗,請將 [部署選項]>[處理選項] 設定為 [不處理],如下圖所示。 Visual Studio 接著就只會部署中繼資料。 然後,您可以設定資料來源認證,並在 Power BI 使用者介面中,針對語意模型按一下 [立即重新整理]

[不處理] 選項

從現有語意模型新增專案

不支援從現有語意模型匯入中繼資料,以在 Visual Studio 中建立新的表格式專案。 不過,您可以使用 SQL Server Management Studio 來連線到語意模型、編寫中繼資料的指令碼,然後在其他表格式專案中重複使用。

將語意模型移轉至 Power BI

建議您為表格式模型指定 1500 (或更高) 相容性層級。 此相容性層級支援大部分的功能和資料來源類型。 較新的相容性層級會與較早的層級回溯相容。

支援的資料提供者

在 1500 相容性層級上,Power BI 支援下列資料來源類型:

  • 提供者資料來源 (模型中繼資料中含有連接字串的舊版)。
  • 結構化資料來源 (透過 1400 相容性層級引進)。
  • 資料來源的內嵌 M 宣告 (因為 Power BI Desktop 會宣告這類資料來源)。

建議您使用結構化資料來源,Visual Studio 預設會在進行匯入資料流程時建立這類來源。 不過,如果您正打算將現有模型移轉到 Power BI 以使用提供者資料來源,請確定提供者資料來源依賴支援的資料提供者。 特別是 Microsoft OLE DB Driver for SQL Server 和任何協力廠商 ODBC 驅動程式。 針對 OLE DB Driver for SQL Server,您必須將資料來源定義切換到 .NET Framework Data Provider For SQL Server。 對於可能無法在 Power BI 服務中使用的協力廠商 ODBC 驅動程式,您必須改為切換到結構化資料來源定義。

此外,也建議您在 SQL Server 資料來源定義中,以 .NET Framework Data Provider for SQL Server 取代已過期的 Microsoft OLE DB Driver for SQL Server (SQLNCLI11)。

下表提供 .NET Framework Data Provider for SQL Server 連接字串範例,可用來取代 OLE DB Driver for SQL Server 的對應連接字串。

OLE DB Driver for SQL Server .NET Framework Data Provider for SQL Server
Provider=SQLNCLI11;Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW;Trusted_Connection=yes; Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW2016;Integrated Security=SSPI;Encrypt=true;TrustServerCertificate=false

交互參照分割區來源

就像有多個資料來源類型,表格式模型也可以包含多個分割區來源類型,以將資料匯入到資料表。 具體而言,分割區可以使用查詢分割區來源或 M 分割區來源。 這些分割區來源類型接著就能參考提供者資料來源或結構化資料來源。 儘管 Azure Analysis Services 中的表格式模型支援交互參照這些不同的資料來源和分割區類型,Power BI 還是會強制執行更嚴格的關聯性。 查詢分割區來源必須參考提供者資料來源,而 M 分割區來源必須參考結構化資料來源。 Power BI 中不支援其他組合。 如果您想要移轉交互參照語意模型,下表描述支援的設定:

資料來源 分割區來源 註解 支援 XMLA 端點
提供者資料來源 查詢分割區來源 AS 引擎會使用卡匣型連線堆疊來存取資料來源。 Yes
提供者資料來源 M 分割區來源 AS 引擎會將提供者資料來源轉譯為一般結構化資料來源,然後使用混搭引擎來匯入資料。 No
結構化資料來源 查詢分割區來源 AS 引擎會將分割區來源上的原生查詢包裝成 M 運算式,然後使用混搭引擎來匯入資料。 No
結構化資料來源 M 分割區來源 AS 引擎會使用混搭引擎來匯入資料。 Yes

資料來源和模擬

您可以為提供者資料來源定義的模擬設定與 Power BI 無關。 Power BI 會使用以語意模型設定為基礎的不同機制來管理資料來源認證。 基於這個理由,如果您要建立提供者資料來源,請務必選取 [服務帳戶]

模擬服務帳戶

更精細的處理

在 Power BI 中觸發已排程的重新整理或視需要重新整理時,Power BI 通常會重新整理整個語意模型。 在許多情況下,以更有選擇性的方式再次執行重新整理會更有效率。 您可以在 SQL Server Management Studio (SSMS) 中 (如下所示),或是使用協力廠商工具或指令碼,來執行更精細的處理工作。

在 SSMS 中處理資料表

Refresh TMSL 命令中的覆寫

Refresh 命令 (TMSL) 中的覆寫,可供使用者選擇不同磁碟分割查詢定義或重新整理作業的資料來源定義。

電子郵件訂用帳戶

使用 XMLA 端點重新整理的語意模型不會觸發電子郵件訂閱

Premium 容量的錯誤

連線至 SSMS 中的伺服器錯誤

使用 SQL Server Management Studio (SSMS) 連線至 Power BI 工作區時,可能會顯示下列錯誤:

TITLE: Connect to Server
------------------------------
Cannot connect to powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
------------------------------
ADDITIONAL INFORMATION: 
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId: 
Date (UTC): 10/6/2021 1:03:25 AM (Microsoft.AnalysisServices.AdomdClient)
------------------------------
The remote server returned an error: (400) Bad Request. (System)

使用 SSMS 連線至 Power BI 工作區時,請確保下列各項:

SSMS 的查詢執行

連線到 Power BI PremiumPower BI Embedded 容量中的工作區時,SQL Server Management Studio 可能會顯示下列錯誤:

Executing the query ...
Error -1052311437: We had to move the session with ID '<Session ID>' to another Power BI Premium node. Moving the session temporarily interrupted this trace - tracing will resume automatically as soon as the session has been fully moved to the new node.

這是可在 SSMS 18.8 和更新版本中忽略的資訊訊息,因為客戶端程式庫會自動重新連線。 請注意,使用 SSMS v18.7.1 或更低版本安裝的用戶端程式庫不支援工作階段追蹤。 下載最新的 SSMS

使用 XMLA 端點執行大型命令

使用 XMLA 端點執行大型命令時,您可能會遇到下列錯誤:

Executing the query ...
Error -1052311437:
The remote server returned an error: (400) Bad Request.

Technical Details:
RootActivityId: 3716c0f7-3d01-4595-8061-e6b2bd9f3428
Date (UTC): 11/13/2020 7:57:16 PM
Run complete

使用 SSMS v18.7.1 或更低版本,在 Power BI Premium 或 Power BI Embedded 容量中的語意模型上執行長時間執行 (> 1 分鐘) 的重新整理作業時,SSMS 可能會顯示此錯誤,即使重新整理作業成功也一樣。 這是由用戶端程式庫中的已知問題所引發,其中系統並未正確追蹤重新整理要求的狀態。 此錯誤已在 SSMS 18.8 與更新版本中解決。 下載最新的 SSMS

當較大型的要求需要重新導向至 Premium 叢集中的不同節點時,也可能會發生此錯誤。 當您嘗試使用大型 TMSL 指令碼建立或變更語意模型時,通常會顯示此錯誤。 在這種情況下,執行命令之前將初始目錄指定為資料庫名稱,通常可以避免此錯誤。

建立新的資料庫時,您可以建立空白的語意模型,例如:

{   
  "create": {   
    "database": {   
      "name": "DatabaseName"
    }   
  }   
} 

建立新的語意模型後,請指定初始目錄,然後變更語意模型。

其他用戶端應用程式和工具

在 Power BI Premium 容量中連線和使用語意模型的用戶端應用程式和工具 (例如 Excel、 Power BI Desktop、SSMS 或外部工具) 可能會導致發生下列錯誤:遠端伺服器傳回錯誤:(400) 錯誤要求。 當基礎 DAX 查詢或 XMLA 命令長時間執行時,可能會導致發生此錯誤。 若要降低潛在錯誤,請務必使用安裝最新版本 Analysis Services 用戶端程式庫的最新應用程式和工具,並定期更新。 無論應用程式或工具為何,透過 XMLA 端點在 Premium 容量中連線和使用語意模型的最低需求用戶端程式庫版本如下:

用戶端程式庫 版本
MSOLAP 15.1.65.22
AMO 19.12.7.0
ADOMD 19.12.7.0

在 SSMS 中編輯角色成員資格

當使用 SQL Server Management Studio (SSMS) v18.8 編輯語意模型的角色成員資格時,SSMS 可能會顯示下列錯誤:

Failed to save modifications to the server. 
Error returned: ‘Metadata change of current operation cannot be resolved, please check the command or try again later.’ 

這是因為應用程式服務 REST API 中的已知問題所致。 這將會在即將推出的版本中解決。 在此同時,若要解決此錯誤,請在 [角色屬性] 中按一下 [指令碼],然後輸入下列 TMSL 命令並加以執行:

{ 
  "createOrReplace": { 
    "object": { 
      "database": "AdventureWorks", 
      "role": "Role" 
    }, 
    "role": { 
      "name": "Role", 
      "modelPermission": "read", 
      "members": [ 
        { 
          "memberName": "xxxx", 
          "identityProvider": "AzureAD" 
        }, 
        { 
          "memberName": “xxxx” 
          "identityProvider": "AzureAD" 
        } 
      ] 
    } 
  } 
} 

發佈錯誤 - 即時連線的語意模型

使用 Analysis Services Connector 重新發佈即時連線的語意模型時,可能會顯示下列錯誤「存在相同名稱的現有報表/語意模型。請刪除或重新命名現有語意模型,然後再重試。」。

無法發佈至 Power BI 錯誤。

這是因為要發佈的語意模型有不同的連接字串,但名稱與現有語意模型名稱相同。 若要解決此問題,請刪除或重新命名現有的語意模型。 也請務必重新發佈與此報表有關的任何應用程式。 如有必要,下游使用者應收到更新具有新報表位址之任何書籤的通知,以確定他們可以存取最新的報表。

無法載入即時連線的語意模型

嘗試使用 2024 年 3 月或更新版本的 Power BI Desktop 建立新的即時連線模型或開啟現有的即時連線模型的使用者可能會遇到類似下列內容的錯誤:「我們無法在 Power BI 中連線到您的模型。資料集可能已被刪除、重新命名、移動,或者您可能沒有存取它的權限。

無法載入模型錯誤的螢幕擷取畫面。

當在使用者環境中設定了 Proxy 且該 Proxy 阻止存取 Power BI 服務時,可能會發生此錯誤。 從 2024 年 3 月版本的 Power BI Desktop 開始,使用者環境必須允許連線到位於端點 *.pbidedicated.windows.net 的 Power BI 服務或主權雲端的對應 Power BI 服務端點。

若要驗證問題是否是 Proxy 設定所導致的,請嘗試使用 Power BI Desktop 中的 SQL Server Analysis Services 連接器或任何第一方或第三方外部工具 (例如 SQL Server Management Studio) 來連線到任何進階工作區。

如需測試一般 XML/A 連線能力的詳細資訊,請參閱本文中的建立用戶端連線一節。

工作區/伺服器別名

不同於 Azure Analysis Services,Premium 工作區不支援伺服器名稱別名

DISCOVER_M_EXPRESSIONS

使用 XMLA 端點的 Power BI 目前不支援 DMV DISCOVER_M_EXPRESSIONS 資料管理檢視 (DMV)。 應用程式可以使用表格式物件模型 (TOM) 以取得資料模型使用的 M 運算式。

資源控管 Premium 中的命令記憶體限制

Premium 容量可以使用資源控管以確保沒有任何單一語意模型作業可以超過容量的可用記憶體資源量 (取決於 SKU)。 例如,P1 訂用帳戶的有效記憶體限制為每個項目 25 GB,P2 訂用帳戶的現制為 50 GB,而 P3 訂用帳戶的現制為 100 GB。 除了語意模型 (資料庫) 大小,有效的記憶體限制也會套用至基礎語意模型命令作業,例如 CreateAlterRefresh

命令的有效記憶體限制是以容量記憶體限制 (取決於 SKU) 或 DbpropMsmdRequestMemoryLimit XMLA 屬性值的較小者為基礎。

例如,針對 P1 容量,若:

  • DbpropMsmdRequestMemoryLimit = 0 (或未指定),則命令的有效記憶體限制為 25 GB。

  • DbpropMsmdRequestMemoryLimit = 5 GB,則命令的有效記憶體限制為 5 GB。

  • DbpropMsmdRequestMemoryLimit = 50 GB,則命令的有效記憶體限制為 25 GB。

一般而言,命令的有效記憶體限制會根據語意模型允許的記憶體 (按容量 (25 GB、50 GB、100 GB)) 及命令開始執行時語意模型已使用的記憶體量進行計算。 例如,在 P1 容量上使用 12 GB 的語意模型允許新命令的有效記憶體限制為 13 GB。 不過,當應用程式選擇性指定時,DbPropMsmdRequestMemoryLimit XMLA 屬性可以進一步限制有效記憶體限制。 使用上述範例,如果在 DbPropMsmdRequestMemoryLimit 屬性中指定 10 GB,則命令的有效限制進一步減少為 10 GB。

如果命令作業嘗試使用超過限制允許的記憶體,則作業可能會失敗並傳回錯誤。 例如,下列錯誤說明,由於語意模型在命令開始執行時已使用 12 GB (12288 MB),因此已超過 25 GB 的有效記憶體限制 (P1 容量),且已針對命令作業套用 13 GB (13312 MB) 的有效限制:

「資源控管:此作業已取消,因為記憶體不足而無法完成執行。 增加託管此語意模型的 Premium 容量記憶體,或者透過限制匯入資料量等動作以減少語意模型的磁碟使用量。 更多詳細資料:已使用記憶體 13312 MB、記憶體限制 13312 MB、命令執行前的記憶體大小 12288 MB。 深入了解:https://go.microsoft.com/fwlink/?linkid=2159753。」

在某些情況下,如下列錯誤所示,「已使用的記憶體為」為 0 但「命令執行前資料庫大小」所顯示的數量已經大於有效的記憶體限制。 這表示作業無法開始執行,因為語意模型已使用的記憶體量大於 SKU 的記憶體限制。

「資源控管:此作業已取消,因為記憶體不足而無法完成執行。 增加託管此語意模型的 Premium 容量記憶體,或者透過限制匯入資料量等動作以減少語意模型的磁碟使用量。 更多詳細資料:已使用記憶體 0 MB、記憶體限制 25600 MB、命令執行前的記憶體大小 26000 MB。 深入了解:https://go.microsoft.com/fwlink/?linkid=2159753。」

若要盡可能避免超過有效的記憶體限制:

  • 針對語意模型,升級至較大型的 Premium 容量 (SKU) 大小。
  • 透過限制每次重新整理載入的資料量,減少語意模型的磁碟使用量。
  • 針對透過 XMLA 端點的重新整理作業,請減少平行處理的資料分割數目。 使用單一命令平行處理太多資料分割可能會超過有效的記憶體限制。