Azure Synapse Analytics 已知问题

此页列出了 Azure Synapse Analytics 中的已知问题，以及它们的解决日期或可能的解决方法。 在提交 Azure 支持请求之前，请查看此列表，看看你遇到的问题是否是已知问题，以及是否正在得到解决。

若要了解有关 Azure Synapse Analytics 的详细信息，请参阅 Azure Synapse Analytics 概述和 Azure Synapse Analytics 中的新增功能

当前已知问题

Azure Synapse Analytics 专用 SQL 池活动已知问题摘要

数据工厂复制命令失败，出现错误“由于 I/O 设备错误，无法执行请求”

Azure 数据工厂管道使用 COPY INTO Transact-SQL 语句将数据大规模引入专用 SQL 池表。 在某些情况下，在 Azure 数据工厂管道中使用文件拆分时，如果将 CSV 文件加载到专用 SQL 池表中，COPY INTO 语句可能会失败。 文件拆分是一种机制，在单个复制任务中加载几个更大的（1 GB+）文件时，可提高加载性能。 启用文件拆分后，多个并行线程可以加载单个文件，其中每个线程处理文件的一部分。

解决方法：受影响的客户应在 Azure 数据工厂中禁用文件拆分。

使用托管标识时，COPY INTO 语句失败，出现错误“发生导致此操作失败的内部 DMS 错误。”

使用托管标识执行 COPY INTO 命令时，语句在长时间运行的查询后可能会失败，并显示错误消息“发生一个内部 DMS 错误，导致此操作失败”。

解决方法：受影响的客户可以使用适用于存储帐户的替代身份验证方法，例如共享访问密钥。

客户无法使用指标监视其专用 SQL 池的使用情况

为了提高遥测数据的性能和可靠性，我们对遥测发射逻辑进行了一次内部升级，但却引发了一个意想不到的问题，影响了一些客户监视专用 SQL 池、tempdb 和数据仓库数据 IO 指标的能力。

解决方法：在确定问题后，我们的团队已采取措施确定根本原因并更新系统中的配置。 客户可以通过暂停并恢复其实例来解决此问题，这会还原实例的正常状态和遥测数据流。

使用 AUTO_CREATE_TABLE='ON' 将 parquet 文件引入到表中时查询失败

尝试使用 AUTO_CREATE_TABLE='ON' 将 parquet 文件引入到哈希分布式表中的用户可能会收到以下错误：

COPY statement using Parquet and auto create table enabled currently cannot load into hash-distributed tables

不支持使用 AUTO_CREATE_TABLE 将文件引入到自动创建的哈希分布式表中。 以前使用此不受支持的方案加载数据的客户应使用 CREATE TABLE AS SELECT （CTAS） 将数据复制到新表中并替换旧表。

查询失败并出现数据外泄错误

从现有专用 SQL 池创建的 Synapse 工作区报告与数据外泄保护相关的查询失败并显示常规性的错误消息，而数据外泄保护在 Synapse Analytics 中已关闭：

Data exfiltration to '{****}' is blocked. Add destination to allowed list for data exfiltration and try again.

解决方法：如果遇到类似错误，请联系 Azure 支持团队寻求帮助。

UPDATE STATISTICS 失败

执行 UPDATE STATISTICS 语句时，一些专用 SQL 池可能会遇到异常。 该命令会生成消息“提供的统计信息流已损坏”，并且无法更新统计信息。

向表添加新约束时，将会在分布中创建相关统计信息。 如果表上还创建了聚集索引，则它必须包含与约束相同的列（顺序相同），否则对这些列执行 UPDATE STATISTICS 命令可能会失败。

解决方法：确定表上是否存在约束和聚集索引。 如果是，则删除约束和聚集索引。 之后，请重新创建聚集索引，然后重新创建约束 ，确保两者按相同顺序包含相同的列。 如果表没有约束和聚集索引，或者该步骤导致相同的错误，请联系 Azure 支持团队以获取帮助。

在 ARM 部署中启用 TDE 网关超时

更新 TDE（透明数据加密）在内部实现为同步操作，并受到超时限制，可能会超时。 尽管已超时，但在大多数情况下，TDE操作在后台成功完成，但这会导致 ARM 模板中的后续操作被拒绝。

解决方法：有两种方法可以缓解此问题。 首选选项是将 ARM 模板拆分为多个模板，以便其中一个模板包含 TDE 更新。 该操作减少了出现超时的可能性。另一种选择是在几分钟后重试部署。 在等待期间，TDE 更新操作很有可能成功，第二次重新部署模板可能会执行先前被拒绝的操作。

标记更新似乎失败

通过 Azure 门户或其他方法更改专用 SQL 池的标记时，即使更改成功，也可能会收到错误消息。

解决方法：可以确认对标记的更改是否已成功，并根据需要忽略/禁止显示错误消息。

通过代理连接可能会因网关问题而失败

从 Azure 网络边界外部建立连接时，所有连接都根据 Synapse 工作区的默认 连接策略 通过网关进行代理。 在 Synapse 工作区中使用专用终结点时，会应用相同的方法。 由于此策略，这可能会导致与专用池通信时延迟增加和吞吐量降低，并受到网关中断的影响。

解决方法：目前方案没有解决方法。

Azure Synapse 工作区活动已知问题摘要

下面是 Synapse 工作区的已知问题。

未列出具有用户分配的托管标识 (UAMI) 的 Blob 存储链接服务

在 Azure Synapse Analytics 中将 Blob 存储链接服务配置为使用“用户分配的托管标识”身份验证后，链接服务在“数据中心”-“已链接”->“Azure Blob 存储”下可能不可见>。

解决方法：工程团队目前已意识到此行为，正在着手修复。 替代方法是使用“系统分配的托管标识”身份验证方法而不使用“用户分配的托管标识”。

无法删除 Synapse 工作区且无法删除虚拟网络

删除 Synapse 工作区失败并显示错误消息：

Failed to delete Synapse workspace '[Workspace Name]'. Unable to delete virtual network. The correlationId is ********-****-****-****-************;

解决方法：可以通过重试删除操作来缓解此问题。 工程团队已意识到此行为，正在着手修复。

用于更新网络设置的 REST API PUT 操作或 ARM/Bicep 模板失败

使用 ARM 模板、Bicep 文件或直接 REST API PUT 操作更改 Synapse 工作区的公共网络访问设置和/或防火墙规则时，操作可能会失败。

解决方法：通过使用 REST API PATCH 操作或 Azure 门户 UI 来撤销所需的配置更改并重试这些更改，可以缓解该问题。 工程团队已意识到此行为，正在着手修复。

在标记值中加入方括号 [] 时的已知问题

在更新 Azure Synapse 工作区中的标记值的上下文中，包含方括号（[]）会导致更新操作失败。

解决方法：当前的解决方法是避免在 Azure Synapse 工作区标记值中使用方括号 ()[]。

没有专用于“Microsoft.Synapse/workspaces/trustedServiceBypassEnabled”设置的“GET”API 操作

问题摘要： 在 Azure Synapse Analytics 中，没有专用的“GET”API操作用于获取资源范围“Microsoft.Synapse/workspaces/trustedServiceBypassEnabled”处的“trustedServiceBypassEnabled”设置的状态。 虽然用户可以设置此配置，但他们无法通过此特定资源范围直接检索其状态。

冲击： 此限制会影响 Azure Policy 定义，因为它们无法强制实施“trustedServiceBypassEnabled”设置的特定状态。 客户无法使用 Azure Policy 来拒绝或管理此配置。

解决方法： Azure Policy 中没有可用的解决方法，用于强制实施此属性的所需配置状态。 但是，用户可以使用“GET”工作区操作来审核配置状态以用于报告目的。
此“GET”工作区操作映射到 Azure Policy 别名“Microsoft.Synapse/workspaces/trustedServiceBypassEnabled”。

如果操作是针对 Microsoft.Synapse/workspace 资源的 PUT 请求，则 Azure Policy 别名可用于通过拒绝 Azure Policy 效果来管理此属性，但如果 PUT 请求直接发送到 Microsoft.Synapse/workspaces/trustedServiceByPassConfiguration 子资源，则它只能用于审核目的。 父资源具有一个属性 [properties.trustedServiceBypassEnabled]，用于映射子资源中的配置，这就是为什么仍可以通过父资源的 Azure Policy 别名对其进行审核。

由于 Microsoft.Synapse/workspaces/trustedServiceByPassConfiguration 子资源没有可用的 GET作，Azure Policy 无法管理这些请求，Azure Policy 无法为其生成 Azure Policy 别名。

父资源：Microsoft.Synapse/workspaces

子资源：Microsoft.Synapse/workspaces/trustedServiceByPassConfiguration

Azure 门户直接向子资源的 PUT API 发出 PUT 请求，因此 Azure 门户与父Microsoft.Synapse/workspaces API 外部发出的任何其他 API 请求无法通过拒绝或其他可作的 Azure Policy 效果来管理 Azure Policy。

Azure Synapse Analytics 无服务器 SQL 池活动已知问题摘要

无服务器 SQL 池在查询 Azure Cosmos DB 分析存储时失败

从无服务器 SQL 池到 Azure Cosmos DB 分析存储的查询可能会失败，并显示以下错误消息之一：

• Resolving CosmosDB path has failed with error 'This request is not authorized to perform this operation'
• Resolving CosmosDB path has failed with error 'Key not found'

若要确认此问题，必须满足以下条件：

1. 与 Azure Cosmos DB 分析存储的连接使用专用终结点。
2. 重试查询成功。

解决方法：工程团队已意识到此行为，可能采取以下措施作为快速缓解措施：

1. 重试失败的查询。 它会自动刷新过期的令牌。
2. 禁用专用终结点。 在应用此更改之前，请与安全团队确认它符合公司安全策略。

Azure Cosmos DB 分析存储视图在列中传播错误的属性

在 Cosmos DB 分析存储上使用 Azure Synapse 无服务器池中的视图时，如果 Cosmos DB 分析存储中的文件发生更改，则更改不会正确传播到客户在视图上使用的 SELECT 语句。 因此，属性会错误地映射到结果中的另一列。

解决方法：工程团队已意识到此行为，可能采取以下措施作为快速缓解措施：

1. 请通过重命名列来重新创建视图。
2. 如果可能，请避免使用视图。

如果以数据库为作用域的凭据已被使用，则更改该凭据会失败

有时，你可能无法执行 ALTER DATABASE SCOPED CREDENTIAL 查询。 此问题的根本原因是凭据在首次使用后缓存，导致其无法更改。 返回的错误为：

• Failed to modify the identity field of the credential '{credential_name}' because the credential is used by an active database file.

解决方法：工程团队目前已知道此行为并正在修复。 解决方法是您可以删除并重新创建凭据，这也意味着要使用这些凭据重新创建外部表。 或者，可联系 Azure 支持团队寻求帮助。

无服务器 SQL 池中的查询失败

尽管用户对存储具有必要的权限，令牌过期也可能会导致查询执行期间出现错误。 这些错误消息也可能由于常见的用户错误而发生，例如，未将基于角色的访问控制 (RBAC) 角色分配给存储帐户时。

错误消息示例：

• WaitIOCompletion call failed. HRESULT = 0x80070005'. File/External table name: {path}
• Unable to resolve path '%' Error number 13807, Level 16, State 1, Message "Content of directory on path '%' cannot be listed.
• Error 16561: External table '<table_name>' is not accessible because content of directory cannot be listed.
• Error 13822: File {path} cannot be opened because it does not exist or it is used by another process.
• Error 16536: Cannot bulk load because the file "%ls" could not be opened.

解决方法：

解决方法因身份验证（Microsoft Entra（以前称为 Azure Active Directory）或托管服务标识 (MSI)）而异：

对于 Microsoft Entra 令牌过期：

• 对于长时间运行的查询，请切换到服务主体、托管标识或共享访问签名 (SAS)，而不是使用用户标识。 请参阅在 Azure Synapse Analytics 中控制无服务器 SQL 池对存储帐户的访问。

• 重启客户端 (SSMS/ADS) 来获取新令牌以建立连接。

对于 MSI 令牌过期：

• 先停用池，然后重新激活池以清除令牌缓存。 请与 Azure 支持团队联系以获取帮助。

由于授权标头太长导致的存储访问问题

无服务器 SQL 池中的错误消息示例：

• File {path} cannot be opened because it does not exist or it is used by another process.
• Content of directory on path {path} cannot be listed.
• WaitIOCompletion call failed. HRESULT = {code}'. File/External table name: {path}

运行查询时，会出现这些一般存储访问错误。 该问题可能发生在一个工作区中的用户身上，但在其他工作区中工作正常。 此行为应该是由令牌大小导致的。

通过在 PowerShell 中运行以下命令来检查 Microsoft Entra 令牌长度。 如果令牌长度接近 11000 或更长，请参阅“应对措施”部分。

(Get-AzAccessToken -ResourceUrl https://database.chinacloudapi.cn).Token.Length

解决方法：

建议的解决方法有：

• 如存储访问控制中所述，切换到托管标识存储授权。
• 减少安全组的数目（安全组数目为 90 个或更少会使生成的令牌具有兼容的长度）。
• 将安全组的数目增加到 200 以上（因为这会更改令牌的构造方式，它将包含 MS Graph API URI 而非完整的组列表）。 可以通过遵循管理组来添加虚拟/模拟组，实现此目的。接下来，你需要将用户添加到新创建的组中。

查询视图时显示了意外结果

当你查询在创建视图后基础架构已更改的视图时，可能会遇到意外结果。 这意味着该视图引用了已修改或不再存在的列或对象。 为了解决此问题，需要手动调整视图定义，以便与基础架构更改保持一致。

解决方法：手动调整视图定义。

超过 7,500 个字符的查询可能不会显示在 Log Analytics 中

在 Log Analytics 的 SynapseBuiltinSqlPoolRequestsEnded 表中可能无法捕获长度超过 7,500 个字符的查询。

解决方法：

建议的解决方法有：

• 在 Synapse 无服务器 SQL 池中使用 sys.dm_exec_requests_history 视图来访问查询执行的历史详细信息。
• 重构查询，使其长度小于 7,500 个字符（如果可行）。

最近关闭的已知问题

Azure Synapse Analytics 无服务器 SQL 池最近关闭的已知问题汇总

使用 Microsoft Entra 身份验证的查询在 1 小时后失败

使用 Microsoft Entra 身份验证的 SQL 连接在保持活动状态超过 1 小时后将开始失败。 这包括使用 Microsoft Entra 直通身份验证来查询存储，以及与 Microsoft Entra ID 进行交互的语句，例如 CREATE EXTERNAL PROVIDER。 这会影响使连接保持活动状态的每个工具，例如 SSMS（SQL Server Management Studio）和 ADS（Azure Data Studio）中的查询编辑器。 打开新连接以执行查询的工具不受影响，如 Synapse Studio。

状态：已解决

使用 OPENROWSET 读取 Azure Cosmos DB 数据时查询失败

使用 OPENROWSET 进行的从无服务器 SQL 池到 Cosmos DB 分析存储的查询失败，并显示以下错误消息：

Resolving CosmosDB path has failed with error 'bad allocation'.

状态：已解决

Azure Synapse Analytics Apache Spark 池最近关闭的已知问题汇总

在管道中使用笔记本时，使用适用于 Apache Spark 的 Azure Synapse 专用 SQL 池连接器从 Synapse Spark 写入到 SQL 专用池失败

在管道中使用笔记本时，当使用适用于 Apache Spark 的 Azure Synapse 专用 SQL 池连接器写入到 Azure Synapse Dedicated 专用池时，我们将看到错误消息：

com.microsoft.spark.sqlanalytics.SQLAnalyticsConnectorException: COPY statement input file schema discovery failed: Cannot bulk load. The file does not exist or you don't have file access rights.

状态：已解决

由于存储帐户限制，某些 spark 作业或任务过早失败，错误代码 503

在 2023 年 10 月 3 日至 2023 年 11 月 16 日期间，由于超出存储 API 限制阈值，有些 Azure Synapse Analytics Apache Spark 池可能经历过 Spark 作业或任务失败的问题。

状态：已解决

在 Spark 3.4 运行时中使用 Synapse 专用 SQL 池连接器时包含 LIKE 子句的查询失败

开源 Apache Spark 3.4 中引入了一个问题，它对特殊字符进行转义，但 Synapse SQL 不支持 escape 关键字。 当客户使用适用于 Apache Spark 的 Azure Synapse 专用 SQL 池连接器时，它可能会生成对 Synapse SQL 无效的 SQL 查询，并且 Synapse Spark 笔记本或批处理作业将引发类似于以下内容的错误：

com.microsoft.spark.sqlanalytics.SQLAnalyticsConnectorException: com.microsoft.sqlserver.jdbc.SQLServerException: Parse error at line: 1, column: XXX: Incorrect syntax near ''%test%''

状态：已解决

相关内容

• Synapse Studio 故障排除
• Azure Synapse Analytics 中的无服务器 SQL 池故障排除
• 在 Azure Synapse Analytics 中使用无服务器 SQL 池的最佳做法
• 排查专用 SQL 池查询速度缓慢的问题