調試SQL Server緩慢：相同的數據庫，不同的服務器

Question

一段時間以來，我們一直在我們新開發的（基於VMWare的）SQL Server 2005數據庫服務器上發現軼事緩慢。最近這個問題已經出現，我開始尋找問題的根源。

下面是一個奇怪的部分：在我用作性能測試用例的存儲過程中，根據運行的數據庫服務器的不同，執行速度有30倍的差異。這是使用相同的數據庫（mdf）和日誌（ldf）文件，從慢速服務器分離，複製並重新連接到快速服務器。這似乎不是一個（虛擬化）的硬件問題：他的慢服務器有4倍的CPU容量和2倍的內存作爲快之一。

盡我所知，問題在於服務器的環境/配置（操作系統或SQL Server安裝）。但是，我檢查了一堆變量（SQL Server配置選項，運行服務，磁盤碎片），並沒有發現任何對測試產生影響的內容。

我應該看什麼東西？我可以使用哪些工具來調查爲什麼會發生這種情況？

Answer 1

盲目檢查變量和設置不會讓你走得很遠。你需要有條不紊地進行。

1. 這兩個過程是否以相同的方式執行？也就是說，這個計劃是不同的？快速檢查SET STATISTICS IO ON並運行這兩種情況。邏輯讀取的數量是否相同？物理讀取的次數是否相同？寫入的數量是否相同？邏輯讀取或寫入的差異將表明不同的計劃。物理讀取的差異（儘管邏輯讀取相似）表示緩存和內存問題。如果計劃不同，則需要進一步調查實際執行計劃中的不同之處。一個計劃是否使用了不同程度的並行性？有人使用不同的連接類型嗎？不同的訪問路徑？
2. 如果計劃相似但執行仍然不同，並且您不能責怪IO子系統，那麼您需要檢查爭用。使用SET STATISTICS TIME ON並比較兩種情況下的經過時間和工作時間。類似的工作時間，但不同的經過時間表明在一種情況下還有更多的等待。使用sys.dm_exec_requests中的wait_type和wait_resource信息來確定爭用的原因。

調查方法在Waits and Queues whitepaper中有更詳細的討論。

Answer 2

運行SQL Server Profiler收集有關SQL Server中正在運行的進程的信息。這可能是最好的開始。這會給你一個消耗大量資源的好主意。

如果索引/重建索引或重寫查詢後仍然存在問題，那麼下一步就是運行PerfMon。