Azure SQL 数据库无服务器计算层中的自动暂停和自动继续

适用于：Azure SQL 数据库

本文解释了 Azure SQL 数据库中无服务器计算层的自动暂停和自动恢复行为，以及它如何与 Azure SQL 数据库的各种功能交互。

目前，通用服务层是唯一支持无服务器自动暂停和自动恢复的服务层。

要监控无服务器数据库状态，请参见 “监控暂停和恢复状态”。

自动暂停

如果在自动暂停延迟期间以下所有条件都成立，将启动自动暂停：

会话数 = 0
对于在用户资源池中运行的用户工作负载，CPU = 0

默认情况下，会自动暂停一小时。

防止自动暂停的功能

如果你使用以下任何功能，请关闭自动暂停。无论数据库处于非活跃状态多久，数据库都会保持在线状态。以下功能防止自动暂停，但支持自动缩放：

地理复制（活跃的地理复制和故障切换组）
长期备份保留（LTR）
为包含无服务器数据库的逻辑服务器创建的 DNS 别名

以下功能场景也防止自动暂停：

SQL 数据同步中使用的同步数据库。与同步数据库不同，中心数据库和成员数据库支持自动暂停。
在弹性作业中，启用自动暂停的无服务器数据库不被作为 作业数据库支持。作为弹性作业目标的无服务器数据库支持自动暂停。作业连接恢复数据库。
在部署某些需要数据库联机的服务更新时，自动暂停功能会被暂时阻止。在这种情况下，一旦服务更新完成，就会再次允许自动暂停。

自动恢复

如果以下任一条件成立，自动恢复将开始：

Feature	自动恢复触发器
身份验证和授权	登录尝试
威胁检测	在数据库或服务器层面启用或禁用威胁检测设置。修改数据库或服务器级别的威胁检测设置。
数据发现和分类	添加、修改、删除或查看敏感度标签
审核	查看审核记录。更新或查看审核策略。
数据掩码	添加、修改、删除或查看数据屏蔽规则
透明数据加密	查看透明数据加密的状况或状态
漏洞评估	手动启动的扫描和定期扫描（如果启用）
查询（性能）数据存储	修改或查看查询存储设置
性能建议	查看或应用性能建议
自动优化	应用与验证自动调优建议，如自动索引
数据库复制	创建数据库作为副本。导出到 BACPAC 文件。
SQL 数据同步	按照可配置的时间表或手动执行中心和成员数据库之间的同步
修改特定的数据库元数据	在数据库中添加或修改Azure标签。更改最大 vCore 数、最小 vCore 数或自动暂停延迟。
SQL Server Management Studio （SSMS）	在18.1之前的SSMS版本中，并对服务器内任意数据库打开新查询窗口，任何自动暂停的数据库都会被恢复。如果你使用SSMS 18.1版本或更高版本，就不会出现这种情况。

执行上述操作的监控、管理或其他解决方案会触发自动恢复。自动恢复也会在某些需要数据库在线的服务更新部署时开始。

自动恢复触发器识别

Azure Monitor 活动日志在 Started 和 Caller 事件的 JSON 的属性下，显示了 Resume Databases 操作的自动恢复触发器。更多信息请参见 “监控无服务器计算层”。

延迟

延迟通常在自动恢复1分钟左右，自动暂停1到10分钟左右。任一操作的延迟可以低至约一秒。

客户管理的透明数据加密

密钥删除或吊销

如果你使用客户管理的透明数据加密（自带密钥 (BYOK)），并且在发生密钥删除或撤销时无服务器数据库已自动暂停，则该数据库将保持自动暂停状态。在这种情况下，在下次恢复数据库后，大约 10 分钟内数据库将无法访问。该数据库变为不可访问后，恢复过程将与预配的计算数据库相同。如果无服务器数据库在密钥删除或撤销发生时在线，数据库也会在大约10分钟内变得无法访问，方式与配置计算数据库相同。

密钥轮换

如果你使用客户管理的透明数据加密（BYOK）并启用无服务器自动暂停，数据库在密钥轮换时会自动恢复。当满足自动暂停条件时，数据库会自动暂停。

自动暂停故障排除

自动恢复连接故障排除

如果无服务器数据库处于暂停状态，则第一次连接尝试将恢复数据库，并返回一个错误，指出数据库将不可用，错误代码为 40613。数据库恢复后，重新尝试连接。数据库通常不到一分钟就能恢复。

所有云连接应用都应使用连接重试逻辑建议。应用程序需要重试逻辑才能在瞬态连接错误后成功。重试逻辑对于无服务器数据库尤为重要，因为自动恢复导致的临时连接错误是可预测的。

有关连接重试逻辑选项和建议，请参阅：

自动暂停的故障排除

如果你启用了自动暂停但没有使用阻止自动暂停的功能，但数据库在延迟后不会自动暂停，可能是应用程序或用户会话阻止了自动暂停。

要查看当前是否有应用程序或用户会话连接到数据库，请运行以下查询：

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
          (
          wg.name like 'UserPrimaryGroup.DB%'
          AND
          TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
          )
      OR
      wg.name = 'DACGroup'
      );

Tip

在运行查询后，请确保断开与数据库的连接。否则，查询所使用的打开的会话会阻止自动暂停。

如果结果集不是空的，说明会话目前阻止自动暂停。
如果结果集为空，仍然有可能在自动暂停延迟期间稍早的某个时间点存在处于打开状态的会话，且持续时间可能很短。要检查延迟期间的活动，可以使用 Azure SQL 数据库的 Auditing 和 Azure Synapse Analytics，并查看相关期间的审计数据。

Important

无服务器数据库无法按预期自动暂停的最常见原因是，无论有无并发 CPU 利用率，用户资源池中都存在打开的会话。

Last updated on 2026-08-14