通过

排查 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 终结点后，建议测试与容量上的工作区的连接性。 若要了解详细信息，请参阅 “连接到高级”工作区。 此外，请务必阅读 “连接要求 ”部分，了解有关当前 XMLA 连接限制的有用提示和信息。

使用服务主体进行连接

如果已启用租户设置以允许服务主体使用 Power BI API，如 “启用服务主体”中所述，可以使用服务主体连接到 XMLA 终结点。 请记住，服务主体需要与普通用户相同的工作区或语义模型级别的访问权限。

若要使用服务主体，请务必将连接字符串中的应用程序标识信息指定为：

  • 用户 ID - app：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）中的表格模型项目部署到分配给高级容量的工作区，这与 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 数据提供程序连接字符串的示例，该连接字符串替换了适用于 SQL Server 的 OLE DB 驱动程序的相应连接字符串。

适用于 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 引擎将提供程序数据源转换为通用结构化数据源，然后使用 Mashup 引擎导入数据。 否
结构化数据源 查询分区源 AS 引擎将分区源上的本机查询包装到 M 表达式中，然后使用 Mashup 引擎导入数据。 否
结构化数据源 M 分区源 AS 引擎使用 Mashup 引擎导入数据。 是的

数据源和身份冒充

可以为提供程序数据源定义的模拟设置与 Power BI 无关。 Power BI 使用基于语义模型设置的不同机制来管理数据源凭据。 出于此原因，请确保在创建提供程序数据源时选择 服务帐户 。

模拟服务帐户

精细处理

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

处理 SSMS 中的表

Refresh TMSL 命令中的替代

刷新命令（TMSL） 中的重载允许用户选择不同的分区查询定义或数据源定义进行刷新操作。

电子邮件订阅

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

高级账户容量中的错误

连接到 SSMS 中的服务器错误

使用 SQL Server Management Studio 连接到 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 Premium 或 Power 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 或 > 容量中的语义模型执行长时间运行的（超过 1 分钟）刷新操作时，即使刷新操作成功，SSMS 也可能显示此错误。 这是因为客户端库中的已知问题导致刷新请求的状态被错误跟踪。 这在 SSMS 18.8 及更高版本中得到解决。 下载最新的 SSMS。

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

创建新数据库时，可以创建空语义模型，例如：

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

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

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

在 Power BI Premium 容量中连接到和使用语义模型的客户端应用程序和工具（如 Excel、Power BI Desktop、SSMS 或外部工具）可能会导致以下错误：远程服务器返回错误：（400） 错误请求。 这种错误尤其可能发生在基础 DAX 查询或 XMLA 命令长时间运行的情况下。 若要缓解潜在错误，请确保使用最新应用程序和工具安装具有常规更新的 Analysis Services 客户端库 的最新版本。 无论应用程序或工具如何，通过 XMLA 终结点连接到高级容量并使用语义模型的最低要求客户端库版本都是：

客户端库 版本
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 开始，用户环境必须允许连接到终结点 *.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 Analysis Services 不同，高级工作区不支持服务器名称别名。

DISCOVER_M_EXPRESSIONS

使用 XMLA 端点的 Power BI 当前不支持 DMV DISCOVER_M_EXPRESSIONS 数据管理视图（DMV）。 应用程序可以使用表格对象模型（TOM）获取数据模型使用的 M 表达式。

高级版中资源管理命令的内存限制

高级容量使用资源调控来确保单个语义模型操作不能超过容量的可用内存资源量，这由 SKU 决定。 例如，对于 P1 订阅，每个项 的有效内存限制 为 25 GB，对于 P2 订阅，限制为 50 GB，对于 P3 订阅，限制为 100 GB。 除了语义模型（数据库）大小外，有效内存限制也适用于基础语义模型命令作，例如 创建、 更改和 刷新。

命令的有效内存限制基于以下两个值中的较小者：由 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“.”

了解内存错误和恢复

跨语义模型的负载均衡由系统自动管理。 内存错误（如此处讨论的错误）可能在容量需求高期间暂时发生。 在大多数情况下，当内存资源可用时，系统会快速恢复。 如果遇到内存错误，请稍等片刻，然后重试作。

如果内存错误持续或频繁发生，则表示容量可能需要额外的资源或优化。 在这种情况下，请考虑以下缓解策略，或联系Microsoft支持人员获取容量大小调整和工作负荷优化方面的帮助。

缓解策略

若要避免超出有效内存限制，请：

  • 升级到语义模型的更大高级容量（SKU）大小。
  • 通过限制每次刷新加载的数据量，减少语义模型的内存占用量。
  • 若要通过 XMLA 终结点执行刷新操作，请减少正在并行处理的分区数量。 与单个命令并行处理的分区过多可能超过有效的内存限制。

相关内容