为什么我的 Azure SQL (SQL Server) 数据库会在一段时间内因数据 IO 过载？

Question

我在 S2 版本 (50 DTU) 下运行 Azure SQL 数据库。正常使用服务器通常会挂在10%左右的DTU。但是，此服务器会定期进入一种状态，它将在数小时内将数据库的 DTU 使用率发送到 85-90%。然后突然间它恢复到正常的 10% 使用率。

在这种过载状态下，应用程序对服务器的查询似乎仍在快速运行。

我可以从 S2 => 任何东西（例如 S3） => S2 扩展服务器，它似乎清除了它挂在的任何状态。但是几个小时后它会再次重复相同的过载状态循环。我注意到的另一件奇怪的事情是，如果我在 S3 计划 (100 DTU) 24/7 上运行此服务器，我没有观察到这种行为。只有当我将数据库缩小到 S2 计划 (50 DTU) 时才会出现这种情况。在 S3 计划中，我始终保持 5-10% 的 DTU 使用率。显然没有得到充分利用。

我已经检查了 Azure SQL 查询报告以查找恶意查询，但我并没有真正看到任何异常，它显示我的查询使用资源，正如我所期望的那样。

正如我们在这里看到的，使用量都来自数据 IO。如果我在此处更改性能报告以显示 MAX 的顶级数据 IO 查询，我们会看到：

查看这些长期运行的查询似乎指向统计更新。并不是真正从我的应用程序运行的任何东西。例如，查询 16302 显示：

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

但话又说回来，报告还显示这些查询仅使用了服务器上数据 IO 使用量的一小部分（< 4%）。作为定期维护的一部分，我还每周在整个数据库上运行统计更新（和索引重建）。

这是另一份报告，它显示了仅在高资源使用率事件期间涵盖几个小时的时间跨度内的 MAX 数据 IO 查询。

正如我们所见，实际上没有任何查询报告大量数据 IO 使用情况。

我也在数据库上运行过sp_who2，sp_whoisacive并没有真正看到任何跳出来的东西（尽管我承认我不是这些工具的专家）。

我如何弄清楚这里发生了什么？我不认为我的任何应用程序查询都应归咎于这种资源使用，而且我感觉有一些内部进程在服务器后台运行，正在杀死它。

Answer 1

鉴于在峰值期间您的日志活动很少，我们可以假设没有发生任何（或太多）酒后驾车。

您曾提到尖峰不会影响性能，但又提到它会影响性能。是哪一个？

您还提到，在缩放操作后这种情况就会消失。这是有道理的，因为它类似于本地重新启动，这将有效地终止所有进程等。

我是否正确地猜测正在从应用程序层访问该数据库？如果是这样，我怀疑您的连接没有正确关闭。垃圾收集器应该最终处理这些问题（不应该依赖它），但我已经看到这种情况是由于应用程序层的未关闭连接而发生的。在我们的例子中，应用程序非常繁忙，以至于我们最终收到了并发连接错误，这就是导致我们出现问题的原因。

在峰值期间尝试以下查询：

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

如果我是正确的，您会发现返回的一大堆记录的状态为Sleeping，或更糟Running。如果是这种情况，您在应用程序层就会遇到更大的问题。

我们可以通过复制数据库、使用以下查询（使用基本层以避免过多的成本）并监视此行为来进一步调试此问题。

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );