Azure SQL Managed Instance的已知问题

applies to：Azure SQL Managed Instance

本文列出了Azure SQL Managed Instance的当前已知问题及其解决日期或可能的解决方法。 若要了解有关Azure SQL Managed Instance的详细信息，请参阅 什么是 Azure SQL Managed Instance？ 和 Azure SQL Managed Instance？

已知问题

具有解决方法

由于等待“HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING”的时间过长，登录以读取次要副本失败

尝试连接到 故障转移组 的只读辅助副本时，您可能会看到此错误，作为 Microsoft OLE DB Driver 19 for SQL Server 驱动程序的一个异常，或连接通过 Managed Instance 链接 进行复制的数据库时。

当辅助副本因行版本缺失而导致无法进行登录时会发生此错误，这是由于在次要副本重启或回收（无论是出于维护还是由于故障转移）期间，正在进行的事务中的行版本丢失造成的。 实例重启或故障转移时，存储在tempdb 的版本数据将被清除。 在故障转移或重启之前启动的长时间运行的活动事务存在时，辅助读取查询将被中止。

若要解决此问题，请在主副本上回滚或提交活动事务。 若要避免此错误，请最大程度地减少主副本上长时间运行的写入事务。

在源自SQL Managed Instance的SQL Server数据库上运行 DBCC CHECKDB 时出错 8992

在 SQL Server 2022 数据库上运行 DBCC CHECKDB 命令时，如果您删除了索引或具有索引的表，并且该数据库原本来自 Azure SQL 托管实例（例如还原备份文件后或通过 SQL 托管实例链接功能），您可能会看到以下错误：

Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.

若要解决此问题，请先从 Azure SQL Managed Instance 中的源数据库删除索引或包含该索引的表，然后恢复数据库，或再次连接至 SQL Server 2022。 如果无法从源Azure SQL Managed Instance重新创建数据库，请联系Azure support以帮助解决此问题。

Azure门户中的长期备份列表显示活动数据库和已删除数据库的备份文件，其名称相同

可以在Backups选项卡上Azure SQL Managed Instance的Azure门户页上列出和管理长期备份。该页列出了活动或已删除的数据库、有关其长期备份的基本信息，以及用于管理备份的链接。 选择“管理”链接时，将打开一个新的侧窗格，其中包含备份列表。 由于筛选逻辑出现问题，列表会显示活动数据库和具有相同名称的已删除数据库的备份。 选择要删除的备份时需要特别注意这一点，以避免删除错误数据库的备份。

解决方法：使用列表中显示的备份时间 (UTC) 信息来区分属于实例上不同时间段存在的同名数据库的备份。 或者，使用 PowerShell 命令 Get-AzSqlInstanceDatabaseLongTermRetentionBackup 和 Remove-AzSqlInstanceDatabaseLongTermRetentionBackup，或 CLI 命令 az sql midb ltr-backup list 和 az sql midb ltr-backup delete，通过 DatabaseState 参数和 DatabaseDeletionTime 返回值管理长期备份，以筛选数据库的备份。

从服务器信任组中删除 SQL 托管实例后，可以执行分布式事务

服务器信任组用于在托管实例之间建立信任，这是执行分布式事务的先决条件。 从服务器信任组中删除 SQL 托管实例或删除组后，仍可以执行分布式事务。 若要确保禁用分布式事务，请在 SQL 托管实例上执行 用户启动的手动故障转移 。

无法创建与之前删除的逻辑服务器同名的SQL Managed Instance

在为 Azure SQL 数据库或 SQL 托管实例创建逻辑服务器时，系统会为 <name>.database.windows.com 创建 DNS 记录。 此 DNS 记录必须是唯一的。 如果为 SQL 数据库创建逻辑服务器，然后将其删除，该名称将保留 7 天。 在此期间，无法创建与已删除逻辑服务器同名的SQL Managed Instance。 一种解决方案是，为 SQL 托管实例（Managed Instance）使用不同的名称，或者创建支持请求以释放逻辑服务器名称。

服务主体无法访问Microsoft Entra ID和 AKV

在某些情况下，存在使用服务主体访问 Microsoft Entra ID（之前称为 Azure Active Directory）和 Azure Key Vault（AKV）服务的问题。 因此，此问题会影响Microsoft Entra身份验证和透明数据加密（TDE）与SQL Managed Instance的使用。 你可能会遇到此问题作为间歇性连接问题，或者无法运行此类 CREATE LOGIN/USER FROM EXTERNAL PROVIDER 语句或 EXECUTE AS LOGIN/USER。 在某些情况下，在新的Azure SQL Managed Instance上使用客户管理的密钥设置 TDE 也可能不起作用。

Workaround：若要防止此问题发生在SQL Managed Instance、执行任何更新命令之前，或者在更新命令后遇到此问题，请转到Azure门户中SQL managed instance的 Overview 页面。 在 Settings 下，选择 Microsoft Entra ID 以访问 SQL Managed Instance Microsoft Entra ID 管理页。 查找以下错误消息：

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

如果遇到此错误消息，请选择该错误消息，并按照提供的分步说明作，直到此错误得到解决。

尝试移除不为空的文件时，返回了错误的错误

SQL Server和SQL Managed Instance 不允许用户删除不为空的文件。 如果尝试使用 ALTER DATABASE REMOVE FILE 语句删除非空数据文件，则错误：

Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.

更改服务层级和创建实例的操作会被正在进行的数据库还原操作阻止

正在进行的RESTORE语句、数据迁移服务的迁移过程以及内置的时间点还原功能，可能会阻止服务层的更新，或阻碍调整现有实例的大小和创建新实例的操作，直到还原过程完成。

还原过程会阻止其运行时所在的子网的托管实例和实例池中的这些操作。 实例池中的实例不受影响。 服务层级创建或更改的操作不会失败或超时。这些操作将在还原过程完成或取消后继续执行。

解决方法：请等待还原过程完成，或者，如果创建或更新服务层级的操作的优先级更高，可取消还原过程。

发生故障转移后，可读的辅助副本上的Resource Governor需要重新配置。

资源 管理器 功能能够限制分配给用户工作负载的资源，但在故障转移或用户发起的服务层变更（例如更改最大 vCore 或最大实例存储大小）后，可能会错误地对某些用户工作负载进行分类。

解决方法：如果您使用ALTER RESOURCE GOVERNOR RECONFIGURE，请在可读的次要副本启动时定期运行，或将其作为执行 SQL 任务的 SQL Agent 作业的一部分。

跨数据库 Service Broker 对话框需要在服务层升级后重新初始化

更改服务层作后，跨数据库 Service Broker 对话框停止将消息传送到其他数据库中的服务。 这些消息没有丢失，可以在发送方队列中找到它们。 SQL Managed Instance中 vCore 或实例存储大小的任何更改都会导致 service_broke_guid 视图中的 值更改为所有数据库。 使用引用其他数据库中 Service Brokers 的 DIALOG 语句创建的任何语句都停止将消息传送到目标服务。

解决方法：先停止使用跨数据库 Service Broker 对话的任何活动，再更新服务层级，然后重新初始化这些活动。 如果服务层更改后未传递的消息仍然存在，请从源队列读取消息并将其重新发送到目标队列。

由于小型数据库文件导致存储空间超出限制

CREATE DATABASE、ALTER DATABASE ADD FILE 和 RESTORE DATABASE 语句可能会失败，因为实例达到常规用途服务层级的Azure Storage限制，但未达到业务关键服务层级。

SQL Managed Instance的每个常规用途实例最多保留 35 TB 的存储空间，用于Azure高级磁盘空间。 每个数据库文件放置在单独的物理磁盘上。 磁盘大小可以为 128 GB、256 GB、512 GB、1 TB 或 4 TB。 不会为磁盘上的未使用空间付费，但 Azure 高级磁盘大小的总和不能超过 35 TB。 在某些情况下，由于内部碎片导致，总共不需要 8 TB 的 SQL 托管实例可能会超过 Azure 存储大小的 35 TB 限制。

例如，SQL Managed Instance的常规用途实例可能有一个大小为 1.2 TB 的大型文件放置在 4 TB 磁盘上。 它还可以将 248 个文件（每个大小为 1 GB）放在单独的 128 GB 磁盘上。 在本示例中：

• 分配的磁盘存储总大小为 1 x 4 TB + 248 x 128 GB = 35 TB。
• 实例上的数据库的总预留空间为 1 x 1.2 TB + 248 x 1 GB = 1.4 TB。

某些情况下，由于文件的特定分布，SQL Managed Instance 可能会达到为附加 Azure 高级磁盘保留的 35TB 限制，这可能超出你的预期。

在此示例中，只要未添加新文件，现有数据库就会继续工作并且可以毫无问题地增长。 由于新磁盘驱动器没有足够的空间，因此无法创建或还原新数据库，即使所有数据库的总大小未达到实例大小限制也是如此。 返回的错误尚不清楚。

可以使用系统视图识别剩余文件的数目。 如果达到此限制，请尝试使用 DBCC SHRINKFILE 语句来清空并删除一些较小的文件，或切换到没有此限制的业务关键层。

显示 GUID 值而不是数据库名称

多个系统视图、性能计数器、错误消息、XEvent 和错误日志条目显示了 GUID 数据库标识符而非实际的数据库名称。 不要依赖这些 GUID 标识符，因为它们将来会被替换为实际的数据库名称。

解决方法：使用视图 从物理数据库名称中解析出实际数据库名称，该名称以 GUID 数据库标识符的形式指定：

SELECT name AS ActualDatabaseName,
       physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;

CLR 模块和链接的服务器有时无法引用本地 IP 地址

SQL 托管实例中的 CLR 模块以及引用当前实例的链接服务器或分布式查询有时无法解析本地实例的 IP 地址。 此错误是暂时性问题。

无解决方法

使用无效凭据连接到只读副本数据库时出现误导性错误消息

尝试使用 ApplicationIntent=ReadOnly 和无效凭据连接到业务关键层实例的只读辅助副本时，该实例将报告一个错误，指示 master 数据库为只读。 该实例未能正确地报告凭据无效。

当实例链接到SQL Server时，不会执行差异备份

在 SQL Server 和 Azure SQL 托管实例之间配置 link时，无论其是否为主角色，都会对 Azure SQL 托管实例执行自动的完整备份和事务日志备份。 但是，目前不会进行差异备份，这可能会导致还原时间比预期的要长。

用于事务复制的系统登录名数量增加

Azure SQL Managed Instance服务为事务复制创建系统登录名。 可以在 SSMS（Object Explorer>Security>Logins） 或 sys.syslogins 系统视图中找到此登录名。 登录名格式如下所示 DBxCy\WF-abcde01234QWERT，登录具有 公共 服务器角色。 在某些情况下，将重新创建此登录名，并且由于内部问题，不会删除以前的登录名。 此错误可能导致登录次数增加。 这些登录名不表示安全威胁，你可以安全地忽略它们。 请勿删除这些登录名，因为至少有一个登录名用于事务复制。

SSDT 不支持Microsoft Entra登录名和用户

SQL Server Data Tools不完全支持Microsoft Entra登录名和用户。

不支持模拟Microsoft Entra登录类型

以下 Microsoft Entra 主体对象不支持使用 EXECUTE AS USER 或 EXECUTE AS LOGIN 模拟：

• 别名 Microsoft Entra 用户。 在这种情况下，该作返回错误 15517。
• 基于Microsoft Entra应用程序或服务主体的Microsoft Entra登录和用户。 在这种情况下，该作返回错误 15517 和 15406。

异地故障转移之后，必须重新配置事务复制

如果在故障转移组中的数据库上启用事务复制，则 SQL Managed Instance 管理员必须在故障转移到另一个区域后，清理旧主数据库上的所有发布，并在新的主数据库上重新配置这些发布。 有关详细信息，请参阅复制。

不保留错误日志

SQL Managed Instance中可用的错误日志不会保留，并且其大小不包括在最大存储限制中。 在发生故障转移时可能会自动清除错误日志。 错误日志历史记录中可能存在差距，因为SQL Managed Instance多次在多个虚拟机上移动。

已解决

更改连接类型不会影响通过故障转移组终结点的连接

（2025年11月解决）

如果某个实例加入故障转移组，则更改该实例的连接类型不会影响通过故障转移组侦听器终结点建立的连接。

在缩放操作期间，使用故障转移组侦听器临时无法访问实例

（2025年4月解决）

有时，扩展 SQL 托管实例需要将实例移动到其他虚拟群集，连同相关的由服务维护的 DNS 记录一起移动。 如果 SQL 托管实例参与故障转移组，则对应于其关联的故障转移组侦听器的 DNS 记录（如果实例是当前异地主节点，则为读写侦听器；如果实例是当前异地辅助节点，则为只读侦听器）会被移动到新的虚拟群集。

在当前的缩放作设计中，侦听器 DNS 记录会从原始虚拟群集中删除，然后再将 SQL 托管实例完全迁移到新的虚拟群集。 在某些情况下，此设计会导致在使用侦听器时，实例的 IP 地址长时间无法被解析。 在此期间，尝试通过侦听器终结点访问正在缩放实例的 SQL 客户端可能会遇到登录失败，并收到以下错误消息：

Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).

此问题将通过对缩放操作进行重新设计来解决。

msdb 中用于手动备份的表不保留用户名

（2023年8月解决） 最近引入对自动备份 msdb 的支持当前不包含用户名信息。

使用SQL Server身份验证时，不支持带有“@”的用户名

中间包含 @ 符号（例如，abc@xy）的用户名无法使用SQL Server身份验证登录。

没有使用 CHECKSUM 的手动备份可能无法还原

（2020年6月解决） 在某些情况下，在没有CHECKSUM的情况下还原在 SQL 托管实例上创建的数据库的手动备份可能会失败。 在这种情况下，请重试还原备份，直到成功为止。

解决方法：对启用了 SQL 托管实例 CHECKSUM 的数据库进行手动备份。

未将资源组的权限应用于SQL Managed Instance

将 SQL 托管实例参与者 Azure 角色应用于资源组 (RG) 时，它并不适用于 SQL 托管实例，并且没有效果。

Workaround：为订阅级别的用户设置 SQL 托管实例参与者角色。

Azure门户上的误导性错误消息，建议重新创建服务主体

Azure Azure SQL Managed Instance门户的 Active Directory admin 页可能会显示以下错误消息，即使服务主体已存在：

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

如果 SQL 托管实例的服务主体已存在，并且/或 SQL 托管实例上的Microsoft Entra身份验证有效，则可以忽略此错误消息。

若要检查服务主体是否存在，请导航到 Azure 门户上的 Enterprise 应用程序页， 从 Application< 类型中选择 Managed Identities c1>，选择 Apply，然后在搜索框中键入 SQL 托管实例的名称。 如果实例名称出现在结果列表中，则表示服务主体已存在，不需要进一步的操作。

如果已按照错误消息中的说明选择链接，则会重新创建 SQL 托管实例的服务主体。 在这种情况下，请将Microsoft Entra ID读取权限分配给新创建的服务主体，以便Microsoft Entra身份验证正常工作。 还可以按照instructions通过Azure PowerShell运行此步骤。

system_health事件会话的event_file目标无法访问

（2025年5月部分解决）当您尝试读取事件会话event_file目标system_health的内容时，会收到错误 40538，“指定的任何文件路径都需要以https://开头的有效 URL。”

最初，此问题发生在 SQL Server Management Studio （SSMS），或使用 sys.fn_xe_file_target_read_file 函数读取会话数据时。

2025 年 5 月，此问题已解决，用于从 SSMS 读取会话数据。 使用 sys.fn_xe_file_target_read_file 函数读取事件数据时，无法解决此问题。

这种行为更改是所需安全修复的意外后果。 可以通过在 Azure Blob Storage 中创建与 system_health 目标相同的 event_file 会话来解决此问题。 有关详细信息，包括用于创建 system_health 会话（可修改以创建等效 system_health）的 T-SQL 脚本，请参阅 使用 system_health 会话。