你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure SQL 托管实例的已知问题
适用于： 
Azure SQL 托管实例
本文列出了 Azure SQL 托管实例的当前已知问题及其解决日期或可能的解决方法。 若要了解有关 Azure SQL 托管实例的详细信息，请参阅 Azure SQL 托管实例是什么？以及 Azure SQL 托管实例中的新增功能？
注意
Microsoft Entra ID 以前称为 Azure Active Directory (Azure AD)。
已知问题
有解决方法
Azure 门户中的长期备份列表显示活动数据库和具有相同名称的已删除数据库的备份文件
可以在“备份”选项卡上的 Azure SQL 托管实例的 Azure 门户页上列出和管理长期备份。该页列出了活动数据库或已删除的数据库、有关其长期备份的基本信息，以及用于管理备份的链接。 选择“管理”链接时，将打开一个新的侧窗格，其中包含备份列表。 由于筛选逻辑出现问题，列表会显示活动数据库和具有相同名称的已删除数据库的备份。 选择要删除的备份时需要特别注意这一点，以避免删除错误数据库的备份。
解决方法：使用列表中显示的备份时间 (UTC) 信息来区分属于实例上不同时间段存在的同名数据库的备份。 或者，使用 PowerShell 命令 Get-AzSqlInstanceDatabaseLongTermRetentionBackup 和 Remove-AzSqlInstanceDatabaseLongTermRetentionBackup 或者 CLI 命令 az sql midb ltr-backup list 和 az sql midb ltr-backup delete 来利用 DatabaseState 参数和 DatabaseDeletionTime 返回值筛选数据库的备份，从而管理长期备份。
无法访问 system_health 事件会话的 event_file 目标
尝试读取 system_health 事件会话的目标 event_file 内容时，错误 40538：“指定的文件路径值必须是以https:// 开头的有效 URL。”会出现在 SQL Server Management Studio 中，或使用 sys.fn_xe_file_target_read_file 函数读取会话数据时。
这种行为更改是由最近的必要安全修补造成的意外后果。 我们正在调查其他更改的可行性，使客户能够安全地继续在 Azure SQL 托管实例中使用 system_health 会话。 同时，客户可以通过在 Azure Blob 存储中使用 event_file 目标创建等效的 system_health 会话来解决此问题。 有关详细信息，包括用于创建 system_health 会话（可修改以创建等效 system_health）的 T-SQL 脚本，请参阅 使用 system_health 会话。
使用 @query 参数时，过程 sp_send_dbmail 可能会失败
在使用 @query 参数时，过程 sp_send_dbmail 可能会失败。 sysadmin 帐户执行存储过程时失败。
此问题是由一个已知漏洞引起的，与 sp_send_dbmail 使用模拟的方式相关。
解决方法：请确保在适当的已创建自定义帐户，而不是在 sysadmin 帐户下调用 sp_send_dbmail。
下面是如何创建专用帐户和如何对通过 sp_send_dbmail 发送电子邮件的现有对象进行修改的示例。
USE [msdb]
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name]
GO
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_user_name=N'user_name'
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name]
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_name=N'msdb'
GO
-- Step 4: Set a principal in the email profile
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
关于智利 2022 年时区更新的临时指导
2022 年 8 月 8 日，智利政府正式宣布夏令时 (DST) 时区变化。 从 2022 年 9 月 10 日星期六中午 12:00 到 2023 年 4 月 1 日星期六中午 12:00，官方时间将提前 60 分钟。 此更改影响以下三个时区：太平洋 SA 标准时间、Easter Island 标准时间和 Magallanes 标准时间。 使用受影响时区的 Azure SQL 托管实例不会反映更改，除非 Microsoft 发布 OS 更新以支持此更改，并且 Azure SQL 托管实例服务会包含 OS 级别的更新。
解决方法：如果需要更改托管实例的受影响时区，请注意限制并遵循文档中的指导。
更改连接类型不会影响通过故障转移组终结点的连接
如果某个实例加入故障转移组，则更改该实例的连接类型不会影响通过故障转移组侦听器终结点建立的连接。
解决方法：在更改连接类型后删除并重新创建故障转移组。
使用 @query 参数时，过程 sp_send_dbmail 可能会暂时失败
在使用 @query 参数时，过程 sp_send_dbmail 可能会暂时失败。 发生此问题时，过程 sp_send_dbmail 的每一秒执行都会失败，并显示 Msg 22050, Level 16, State 1 错误和 Failed to initialize sqlcmd library with error number -2147467259 消息。 为了能够正确看到此错误，应使用参数 @exclude_query_output 的默认值 0 调用该过程，否则错误不会传播。
此问题是由一个已知 bug 引起的，这个 bug 与 sp_send_dbmail 使用模拟和连接池的方式相关。
若要解决此问题，请将用于发送电子邮件的代码包装到依赖于输出参数 @mailitem_id 的重试逻辑中。 如果执行失败，则参数值为 NULL，表示应该再次调用 sp_send_dbmail 以成功发送电子邮件。 下面是此重试逻辑的示例：
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
从服务器信任组删除托管实例后可以执行分布式事务
服务器信任组用于在托管实例之间建立信任，这是执行分布式事务的先决条件。 在从服务器信任组中删除托管实例后，或在删除该组后，你仍然可以执行分布式事务。 若要确保禁用分布式事务，可以使用一种解决方法，即用户发起的手动故障转移（在托管实例上应用）。
执行托管实例缩放操作后无法执行分布式事务
包括更改服务层或 vCore 数量在内的 SQL 托管实例缩放操作会重置后端的服务器信任组设置，并禁止运行分布式事务。 解决方法是在 Azure 门户上删除并创建新的服务器信任组。
无法创建与之前删除的逻辑服务器同名的 SQL 托管实例
为 Azure SQL 数据库创建 Azure 中的逻辑服务器以及在创建 SQL 托管实例时，将创建 <name>.database.windows.com 的 DNS 记录。 该 DNS 记录必须唯一。 因此，如果为 SQL 数据库创建逻辑服务器并随后删除该逻辑服务器，在经过 7 天的阈值期限后，将从记录中释放其名称。 在此期限内，无法使用与已删除逻辑服务器相同的名称创建 SQL 托管实例。 一种解决方法是为 SQL 托管实例使用不同的名称，或者创建支持票证来释放逻辑服务器名称。
服务主体无法访问 Microsoft Entra ID 和 AKV
在某些情况下，用于访问 Microsoft Entra ID（以前称为 Azure Active Directory）和 Azure Key Vault (AKV) 服务的服务主体可能存在问题。 这个问题最终会对 Microsoft Entra 身份验证和 SQL 托管实例的透明数据加密 (TDE) 的使用产生影响。 这种情况可能会体现为间歇性的连接问题，或者是无法运行 CREATE LOGIN/USER FROM EXTERNAL PROVIDER 或 EXECUTE AS LOGIN/USER 之类的语句。 在某些情况下，在新的 Azure SQL 托管实例上使用客户托管密钥设置 TDE 也可能不起作用。
解决方法：如果要防止在执行任何更新命令之前 SQL 托管实例出现此问题，或者如果在执行更新命令后遇到了此问题，请转到 Azure 门户中 SQL 托管实例的概述页面。 在“设置”下，选择“Microsoft Entra ID”以访问 SQL 托管实例 Microsoft Entra ID 管理页面。 验证是否可以看到错误消息“托管实例需要服务主体才能访问 Microsoft Entra ID。 单击此处创建服务主体”。 如果看到此错误消息，请选择它，然后按照提供的分步说明操作，直到解决此错误为止。
通过门户对故障转移组进行手动故障转移的限制
如果故障转移组跨越不同 Azure 订阅或资源组中的实例，则无法从故障转移组中的主实例启动手动故障转移。
解决方法：通过门户从异地辅助实例启动故障转移。
SQL 代理角色需要拥有对非 sysadmin 登录名的显式 EXECUTE 权限
如果将非 sysadmin 登录名添加到任何 SQL 代理固定数据库角色，则会存在一个问题，即必须向 master 数据库中的三个存储过程授予显式 EXECUTE 权限，这些登录名才能正常使用。 如果遇到此问题，将显示错误消息 The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229)。
解决方法：将登录名添加到 SQL 代理固定数据库角色（SQLAgentUserRole、SQLAgentReaderRole 或 SQLAgentOperatorRole）后，对于添加到这些角色的每个登录名，请执行以下 T-SQL 脚本，向列出的存储过程显式授予 EXECUTE 权限。
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
内存中 OLTP 内存限制不适用
在某些情况下，业务关键服务不能正确应用内存优化对象的最大内存限制。 SQL 托管实例可以让工作负荷使用更多的内存进行内存中 OLTP 操作，这可能影响实例的可用性和稳定性。 达到限制的内存中 OLTP 查询可能不会立即失败。 使用较多内存中 OLTP 内存的查询在达到限制的情况下会更快地失败。
解决方法：使用 SQL Server Management Studio监视内存中 OLTP 存储的使用情况，确保工作负载使用的内存不会超过可用内存。 提高基于 vCore 数的内存限制，或者优化工作负荷，让其使用较少的内存。
尝试删除不为空的文件时，返回了错误的错误
SQL Server 和 SQL 托管实例不允许用户删除不为空的文件。 如果尝试使用 ALTER DATABASE REMOVE FILE 语句删除非空数据文件，系统不会立即返回 Msg 5042 – The file '<file_name>' cannot be removed because it is not empty 错误。 SQL 托管实例会继续尝试删除该文件，操作会在 30 分钟后失败并显示 Internal server error。
更改服务层级和创建实例的操作会被正在进行的数据库还原操作阻止
正在运行的 RESTORE 语句、数据迁移服务的迁移过程以及内置的时间点还原都会阻止对服务层级的更新操作或者对现有实例的重设大小操作以及创建新实例的操作，直至还原过程完成为止。
还原过程会阻止其运行时所在的子网的托管实例和实例池中的这些操作。 实例池中的实例不受影响。 服务层级创建或更改操作不会失败或超时。还原过程完成或取消后，将继续执行这些操作。
解决方法：请等待还原过程完成，或者，如果创建或更新服务层级的操作的优先级更高，可取消还原过程。
故障转移后，可能需要重新配置“业务关键”服务层级上的 Resource Governor
Resource Governor 功能可让你限制分配给用户工作负荷的资源。在故障转移或者完成用户发起的服务层级更改（例如，更改最大 vCore 数或最大实例存储大小）后，Resource Governor 可能会错误地分类某些用户工作负荷。
解决方法：如果使用 Resource Governor，请定期运行 ALTER RESOURCE GOVERNOR RECONFIGURE，或者在完成 SQL 代理作业（该作业在实例启动时执行 SQL 任务）的过程中运行此命令。
升级服务层级后必须重新初始化跨数据库 Service Broker 对话
完成更改服务层级的操作后，跨数据库 Service Broker 对话会停止向其他数据库中的服务传递消息。 这些消息没有丢失，可以在发送方队列中找到它们。 在 SQL 托管实例中对 vCore 或实例存储大小进行任何更改都会导致 sys.databases 视图中所有数据库的 service_broke_guid 值发生更改。 使用 BEGIN DIALOG 语句创建的、引用其他数据库中的 Service Broker 的任何 DIALOG 将停止向目标服务传递消息。
解决方法：先停止使用跨数据库 Service Broker 对话的任何活动，再更新服务层级，然后重新初始化这些活动。 如果在更改服务层级后存在任何未传递的剩余消息，请从源队列中读取消息，然后将其重新发送到目标队列。
小型数据库文件超出存储空间
CREATE DATABASE、ALTER DATABASE ADD FILE 和 RESTORE DATABASE 语句可能会失败，因为实例可能会达到 Azure 存储限制。
每个 SQL 托管实例的常规用途实例都为 Azure 高级磁盘空间保留了最多 35 TB 存储空间。 每个数据库文件放置在单独的物理磁盘上。 磁盘大小可以为 128 GB、256 GB、512 GB、1 TB 或 4 TB。 磁盘上未使用的空间不收费，但 Azure 高级磁盘大小总计不能超过 35 TB。 在某些情况下，由于内部碎片，总共不需要 8 TB 的托管实例可能会超过 35 TB 的 Azure 存储大小限制。
例如，SQL 托管实例的常规用途实例可将一个大小为 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 托管实例的实例可能会出乎意料地达到为附加的 Azure 高级磁盘预留的 35 TB 存储空间大小限制。
在此示例中，只要未添加新文件，现有数据库就会继续工作并且可以毫无问题地增长。 由于没有足够的空间用于新磁盘驱动器，因此无法创建或还原新数据库，即使所有数据库的总大小未达到实例大小限制也是如此。 这种情况下返回的错误并不明确。
可以使用系统视图识别剩余文件的数目。 如果达到此限制，请尝试使用 DBCC SHRINKFILE 语句来清空并删除一些较小的文件，或切换到没有此限制的业务关键层。
显示 GUID 值而不是数据库名称
多个系统视图、性能计数器、错误消息、XEvent 和错误日志条目显示了 GUID 数据库标识符而非实际的数据库名称。 不要依赖这些 GUID 标识符，因为它们将来会被替换为实际的数据库名称。
解决方法：使用 sys.databases 视图从物理数据库名称（以 GUID 数据库标识符的形式指定）解析实际数据库名称：
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
CLR 模块和链接的服务器有时无法引用本地 IP 地址
放在 SQL 托管实例中的 CLR 模块以及引用当前实例的链接服务器或分布式查询有时可能无法解析本地实例的 IP。 此错误是暂时性问题。
跨同一实例中的两个数据库的事务范围不受支持
（2020 年 3 月已解决）如果两个查询被发送到同一事务范围下相同实例内的两个数据库，那么 .Net 中的 TransactionScope 类就无法正常运行：
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
解决方法（自 2020 年 3 月起不再需要） ：使用 SqlConnection.ChangeDatabase(String) 在连接上下文中使用其他数据库，而非使用两个连接。
无解决方法
当实例链接到 SQL Server 时不会进行差异备份
当配置 SQL Server 和 Azure SQL 托管实例之间的链接时，无论托管实例是否处于主要角色，都会对其进行自动完整备份和事务日志备份。 但是，目前不会进行差异备份，这可能会导致还原时间比预期的要长。
用于事务复制的系统登录名数量增加
Azure SQL 托管实例服务正在为事务复制创建系统登录名。 此登录名可以在 SSMS 中（在对象资源管理器的“安全性”-“登录名”下），或者在系统视图 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 托管实例管理员必须清理旧的主节点上所有发布内容，然后在故障转移到另一个区域后，在新的主节点上重新配置这些发布内容。 有关详细信息，请参阅复制。
tempdb 结构和内容会重新创建
tempdb 数据库始终拆分为 12 个数据文件，文件结构不可更改。 无法更改每个文件的最大大小，并且无法将新文件添加到 tempdb。 当实例启动或发生故障转移时，tempdb 数据库始终作为空数据库重新创建，且在 tempdb 中所做的任何更改都不会保留。
不保留错误日志
SQL 托管实例中可用的错误日志不会持久保留，并且它们的大小不包括在最大存储限制中。 在发生故障转移时可能会自动清除错误日志。 错误日志历史记录中可能存在差距，因为 SQL 托管实例在多个虚拟机上转移了多次。
缩放操作期间，使用故障转移组侦听器的临时实例不可访问性
缩放托管实例有时需要将实例，连同关联服务维护的 DNS 记录一起移动到不同的虚拟群集。 如果托管实例参与故障转移组，则对应于其关联的故障转移组侦听器的 DNS 记录（如果实例是当前地区主实例，则为读写侦听器；如果实例是当前地区辅助实例，则为只读侦听器）会被移动到新的虚拟群集。
在当前的缩放操作设计中，侦听器 DNS 记录会在托管实例本身完全迁移到新的虚拟群集之前，从初始虚拟群集中移除，这在某些情况下会导致长时间无法使用侦听器解析实例的 IP 地址。 在此期间，尝试访问使用侦听器端点进行缩放的实例的 SQL 客户端可能会出现登录失败，并伴有以下错误消息：“错误 40532：无法打开登录请求的服务器“xxx.xxx.xxx.xxx”。 登录失败。 （Microsoft SQL Server，错误：40532）。”
此问题将通过对缩放操作进行重新设计来解决。
已解决
msdb 中用于手动备份的表不保留用户名
（已于 2023 年 8 月解决） 我们最近在 msdb 中引入了对自动备份的支持，但该表当前不包含用户名信息。
对外部表的查询失败，出现“不受支持”错误消息
对外部表的查询可能会失败，并出现错误消息“此数据库的当前服务层级或性能级别不支持对外部表进行查询。 请考虑升级数据库的服务层级或性能级别”。 Azure SQL 托管实例中唯一受支持的外部表类型为 PolyBase 外部表（预览版）。 若要允许对 PolyBase 外部表进行查询，需要通过运行 sp_configure 命令在托管实例上启用 PolyBase。
SQL 托管实例不支持与 Azure SQL 数据库的弹性查询功能相关的外部表，但未显式阻止创建和查询这些表。 由于支持 PolyBase 外部表，因此引入了新的检查，阻止在托管实例中查询任何类型的外部表，除非启用了 PolyBase。
如果使用不受支持的弹性查询外部表从托管实例查询 Azure SQL 数据库或 Azure Synapse 中的数据，应改用链接服务器功能。 若要建立从 SQL 托管实例到 SQL 数据库的链接服务器连接，请按照这篇文章中的说明进行操作。 若要建立从 SQL 托管实例到 SQL Synapse 的链接服务器连接，请查看分步说明。 由于配置和测试链接服务器连接需要一些时间，因此你可以使用一种替代方法作为临时解决方案，以支持查询与弹性查询功能相关的外部表：
解决方法：执行以下命令（每个实例一次），以启用对外部表的查询：
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
使用 SQL Server 身份验证时，不支持带有“@”的用户名
中间包含了“@”符号的用户名（例如 'abc@xy'）无法使用 SQL Server 身份验证登录。
没有使用 CHECKSUM 的手动备份可能无法还原
（已于 2020 年 6 月解决） 在某些情况下，没有使用 CHECKSUM 在托管实例上进行的数据库手动备份可能无法还原。 在这种情况下，请重试还原备份，直到成功为止。
解决方法：在启用了 CHECKSUM 的情况下在托管实例上手动备份数据库。
在修改、禁用或启用现有作业后代理无响应
在某些情况下，修改、禁用或启用现有作业可能会导致代理无响应。 此问题在被检测到后自动缓解，导致代理进程重启。
资源组上的权限不应用于 SQL 托管实例
将 SQL 托管实例参与者 Azure 角色应用于资源组 (RG) 时，该角色不应用于 SQL 托管实例，因此不起作用。
解决方法：在订阅级别为用户设置“SQL 托管实例参与者”角色。
重启代理进程可能会中断 SQL 代理作业
（2020 年 3 月已解决）SQL 代理在每次启动作业时都会新建一个会话，从而逐渐增加内存消耗。 为了避免达到内部内存限制，从而阻止已计划作业的执行，一旦代理的内存消耗量达到阈值，就会重启代理进程。 这可能会中断重启时正在运行的作业的执行。
sp_send_db_mail 中不支持 @query 参数
sp_send_db_mail 过程中的 @query 参数不起作用。
有关 Azure 门户上建议重新创建服务主体的误导性错误消息
即使服务主体已存在，Azure SQL 托管实例 Azure 门户的“Active Directory 管理”页面也可能显示以下错误消息：
托管实例需要服务主体才能访问 Microsoft Entra ID（以前称为 Azure Active Directory）。 单击此处创建服务主体”
如果托管实例的服务主体已存在，且/或托管实例上的 Microsoft Entra 身份验证有效，则可以忽略此错误消息。
若要检查服务主体是否存在，请导航到 Azure 门户上的“企业应用程序”页，从“应用程序类型”下拉列表中选择“托管标识”，选择“应用”，然后在搜索框中键入托管实例的名称。 如果实例名称出现在结果列表中，则表示服务主体已存在，不需要进一步的操作。
如果你已按照错误消息中的说明进行操作并选择了错误消息中的链接，则已重新创建托管实例的服务主体。 在这种情况下，请为新建的服务主体分配 Microsoft Entra ID 读取权限，以便 Microsoft Entra 身份验证正常工作。 可以按照说明通过 Azure PowerShell 完成此操作。
参与内容制作
若要参与 Azure SQL 文档制作，请参阅文档参与者指南。
相关内容
有关 SQL 托管实例更新和改进的列表，请参阅 SQL 托管实例服务更新。
有关所有 Azure 服务的更新和改进，请参阅服务更新。