排查 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 终结点。 请记住,服务主体要求工作区或语义模型级别的与普通用户相同的访问权限级别。

若要使用服务主体,请确保在连接字符串中将应用程序标识信息指定为:

  • 用户 ID - 应用:appid@tenantid

  • 密码

    • 证书:指纹 (建议安全)

      Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=cert:<thumbprint>;

    • 应用程序机密

      Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=<secret>;

如果收到以下错误:

“无法连接到语义模型,因为帐户信息不完整。 对于服务主体,请确保使用 app:<appId>@<tenantId> 格式指定租户 ID 和应用 ID,然后重试。”

请确保使用正确的格式指定租户 ID 和应用 ID。

也可以指定应用 ID 而不指定租户 ID。 但是,在这种情况下,必须将数据源 URL 中的 myorg 别名替换为实际租户 ID。 然后 Power BI 可以在正确的租户中查找服务主体。 但作为最佳做法,请使用 myorg 别名,并在用户 ID 参数中指定租户 ID 和应用 ID。

使用 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,必须将数据源定义切换到用于 SQL Server 的 .NET Framework 数据提供程序。 对于在 Power BI 服务中可能不可用的第三方 ODBC 驱动程序,必须改为切换到结构化数据源定义。

此外,建议将 SQL Server 数据源定义中过时的 Microsoft OLE DB Driver for SQL Server (SQLNCLI11) 替换为适用于 SQL Server 的 .NET Framework 数据提供程序。

下表提供了适用于 SQL Server 的 .NET Framework 数据提供程序连接字符串示例,该连接字符串替换 OLE DB Driver for SQL Server 相应的连接字符串。

适用于 SQL Server 的 OLE DB 驱动程序 用于 SQL Server 的 .NET Framework 数据访问接口
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 引擎使用基于插件的连接堆栈来访问数据源。
提供程序数据源 M 分区源 AS 引擎将提供程序数据源转换为泛型结构化数据源,然后使用糅合引擎导入数据。
结构化数据源 查询分区源 AS 引擎将分区源上的本机查询包装到一个 M 表达式中,然后使用糅合引擎导入数据。
结构化数据源 M 分区源 AS 引擎使用糅合引擎来导入数据。

数据源和模拟

可为提供程序数据源定义的模拟设置与 Power BI 无关。 Power BI 使用基于语义模型设置的不同机制来管理数据源凭据。 为此,如果要创建提供程序数据源,请确保选择“服务帐户”。

模拟服务帐户

细化处理

在 Power BI 中触发计划刷新或按需刷新时,Power BI 通常会刷新整个语义模型。 在许多情况下,选择性地执行刷新更有效。 你可以在 SQL Server Management Studio (SSMS) 中执行细化处理任务(如下所示),或使用第三方工具或脚本。

在 SSMS 中处理表

Refresh TMSL 命令中的替代

Refresh 命令 (TMSL) 中的替代允许用户为刷新操作选择其他分区查询定义或数据源定义。

电子邮件订阅

使用 XMLA 终结点刷新的语义模型不会触发电子邮件订阅

高级容量错误

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

当需要将非常大的请求重定向到高级群集中的不同节点时,也可能发生此错误。 当你尝试使用大型 TMSL 脚本创建或更改语义模型时,通常会看到此错误。 在这种情况下,在执行命令之前,通常可以通过将初始目录指定为数据库名称来避免此错误。

创建新数据库时,可以创建一个空语义模型,例如:

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

创建新的语义模型后,请指定初始目录,然后更改语义模型。

其他客户端应用程序和工具

客户端应用程序和工具(例如 Excel、Power BI Desktop、SSMS 或连接到 Power BI Premium 容量中的语义模型并使用它的外部工具)可能会导致以下错误:“远程服务器返回错误: (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 连接器重新发布实时连接的语义模型时,可能会显示以下错误:“存在同名的现有报表/语义模型。请删除或重命名现有语义模型,然后重试”。

“无法发布到 Power BI”错误。

这是由于要发布的语义模型具有不同的连接字符串,但与现有语义模型具有相同的名称。 要解决此问题,请删除或重命名现有语义模型。 还要确保重新发布依赖于该报表的任何应用。 如有必要,还应告知下游用户使用新的报表地址更新任何书签,以确保他们能够访问最新的报表。

无法加载实时连接的语义模型

尝试创建新的实时连接模型或打开现有实时连接模型的用户(使用 2024 年 3 月或更高版本的 Power BI Desktop)可能会遇到类似于以下内容的错误:“我们无法连接到Power BI 服务中的模型。数据集可能已被删除、重命名、移动,或者你可能无权访问数据集。

无法加载模型错误的屏幕截图。

在用户环境中配置代理并且代理阻止访问Power BI 服务时,可能会出现此错误。 从 2024 年 3 月版 Power BI Desktop 开始,用户的环境必须允许 Power BI 服务连接到终结点 *.pbidedicated.windows.net 或主权云的相应Power BI 服务终结点。

若要验证问题是代理设置的结果,请尝试 Power BI Desktop 中的 SQL Server Analysis Services 连接器或任何第一方或第三方外部工具(如 SQL Server Management Studio)连接到任何高级工作区。

有关 测试常规 XML/A 连接的详细信息,请参阅本文中的“建立客户端连接 ”部分。

Excel 工作簿无法打开

Excel 工作簿可能无法打开,并出现错误“数据源初始化失败。检查数据库服务器或联系数据库管理员。“。 如果工作簿包含与 Power BI 语义模型的连接,请检查连接字符串是否包含属性“Catalog Rebound=True”。 如果找到该属性,请将其删除,保存工作簿,然后再次尝试打开它。

当与 Power BI 语义模型建立连接由提供程序优化时,Analysis Services OLE DB 提供程序(MSOLAP)在较新版本的 Excel 中自动添加“Catalog Rebound=True”属性。 由于该属性持久保存到工作簿中,因此当使用不支持优化的提供程序的较旧版本的 Excel 中打开同一工作簿时,Excel 将无法打开该工作簿。

Catalog Rebound”仅用于内部使用。

工作区/服务器别名

与Azure 分析服务不同,高级工作区不支持服务器名称别名

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。

如果命令操作尝试使用超过限制所允许的内存量,则操作可能会失败,并返回错误。 例如,以下错误说明已超出 25 GB(P1 容量)的有效内存限制,因为在命令开始执行时,语义模型已使用 12 GB (12288 MB),而命令操作应用了 13 GB (13312 MB) 的有效限制:

“资源管理: 此操作已取消,因为没有足够的内存来完成运行。 增加托管此语义模型的高级容量的内存,或通过执行限制导入数据量等操作来减少语义模型的内存占用量。 更多详细信息: 已使用内存 13312 MB,内存限制 13312 MB,命令执行前数据库大小 12288 MB。 了解详细信息: https://go.microsoft.com/fwlink/?linkid=2159753。”

在某些情况下,如以下错误所示,“已使用的内存”为 0,但“命令执行前的数据库大小”的显示值已经超出有效内存限制。 这意味着操作无法开始执行,因为语义模型已使用的内存量大于 SKU 的内存限制。

“资源管理: 此操作已取消,因为没有足够的内存来完成运行。 增加托管此语义模型的高级容量的内存,或通过执行限制导入数据量等操作来减少语义模型的内存占用量。 更多详细信息: 已使用内存 0 MB,内存限制 25600 MB,命令执行前数据库大小 26000 MB。 了解详细信息: https://go.microsoft.com/fwlink/?linkid=2159753。”

若要避免超过有效内存限制的可能性,可采取以下措施:

  • 将语义模型升级到较大的 Premium 容量 (SKU) 大小。
  • 通过限制每次刷新时加载的数据量减少语义模型的内存占用量。
  • 对于通过 XMLA 终结点进行的刷新操作,减少正在并行处理的分区数。 使用单个命令并行处理过多分区可能会超出有效的内存限制。