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。所以对于你的第一个问题，答案是否取决于

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

来到您的场景并询问..

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

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

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

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

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

凭借绩效洞察力，您可以获得

Answer 2

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

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

总结一下，由于1,2中的查询发生了，结果是3。

就我提出的问题而言，sproc2是一个大问题，并且不知何故总是被逐出计划缓存。