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 是一個大查詢，並且總是以某種方式從計划緩存中逐出。