SQL Azure 资源限制以及 EXEC 如何影响它

Question

我有一个存储过程，我从 5 个表中读取数据。 从表 4 返回的数据实际上是通过 EXECuting 另一个存储过程调用的。

存储过程：

    SELECT from tbl_1
    SELECT from tbl_2
    SELECT from tbl_3
    EXEC sproc2 -- returns rows from tbl_4
    SELECT from tbl_5

有趣的是，在 C# 中对表 5 中的行执行dataReader.NextResult ，我意识到没有结果。 这并不经常发生，但我确实注意到这种情况发生了几次。

我从 SqlAzure 注意到的错误是

达到了数据库资源限制。

整个存储过程不应该在单个线程中运行，并且一旦开始执行就应该不受限制使用问题的影响吗？ 还是因为轮询调度导致 SQL Server 由于资源不可用而无法重新启动我的存储过程执行？

Answer 1

整个存储过程不应该在单个线程中运行吗

当您向 SQL Server 提交查询时，它可能会根据许多条件选择并行运行查询。 其中之一是cost Threshold for Parallelism度的cost Threshold for Parallelism 。 所以对于你的第一个问题，答案是它取决于

仅供参考......很多时候查询将受益于并行运行，因此并行性并不总是很糟糕。

来到你的场景并询问..

整个存储过程不应该在单个线程中运行，并且一旦开始执行就应该不受限制使用问题的影响吗？

SQL Server 可以估计查询所需的内存并可以停止其执行（甚至不会启动），直到它有足够的内存来启动..

但是在 Azure DTU 中是内存、IO、CPU 的组合，它们中的任何一个都可以达到其配额，并且无法限制查询使用有限的 IO、CPU

因此，如果 DTU 受到严重限制，则查询可以在其等待时间结束后停止。

为了解决此问题，Azure 提供了性能洞察，以通过查询了解有关 DTU 使用情况的更多信息，以便您可以对其进行微调。

通过性能洞察，您可以获得

Answer 2

所以，在查询存储中运行一堆查询并试图弄清楚我的数据库发生了什么之后，这就是我想出来的

我们偶尔会运行一些长时间运行的查询，执行清理的查询和收集日志的查询。 不幸的是，他们决定同时运行。 SQL 授予这些查询大内存。
随机查询开始超时，我注意到它们被resource_semaphore_query_compile等待类型阻止。 这意味着 SQL 没有针对该查询的缓存计划，它甚至没有足够的内存来再次编译该查询。
分配给 MEMORY_SQLQERESERVATIONS 的总内存很高，而分配给计划缓存的总内存很低，这是我与 sql server 上的一般内存使用情况进行比较的结果。

总而言之，由于 1 中的查询，2 发生了，结果是 3。

就我提出的问题而言，sproc2 是一个大查询，并且总是以某种方式从计划缓存中逐出。