SQL Server 2005 64位查詢阻止

Question

我們遇到了SQL Server性能方面的一些困難，希望得到一些幫助。

我們的環境是： -

的Windows 2003 x64企業版R2 英特爾E5450四核處理器3GHz的16GB RAM 的SQL Server 2005 64位企業版（9.00.3282.00） 數據庫的兼容性是8（但在測試9以及） 超線程關閉

我們有與正在查詢（低效地）一個120萬行表中的一個數據庫，但是導致所有4個處理器被飽和到其中所有其他查詢被阻塞，直到所述點查詢完成。這包括查詢來分離數據庫和完全不相關的表。

如果使用MAXDOP 1選項運行查詢，那麼所有4個內核以25％的速度運行，查詢需要4倍的時間，這種情況下沒有阻塞。除此之外，我們在SQL 2000上運行相同的查詢，響應時間相同，但沒有CPU飽和。

我們懷疑問題可能在tempdb上發生爭用。在這個特定的實例中，我們有一個使用臨時表的存儲過程，以及訪問我假設的臨時數據庫的並行查詢。

顯然，標準響應將重新編寫查詢。首先，這不是一個真正可行的選擇，其次這只是治療問題的症狀。本質上，服務器無法處理多個請求，這非常值得關注。

有沒有人知道任何補丁，配置更改或已知的問題，可能會導致此？有沒有人見過這個？這是一個64位的細微差別嗎？

問候

李

Answer 1

聽起來像在tempdb中鎖定其有效地阻止其他任何可能使用tempdb運行，​​直到它完成。特別是它可能是sysobjects表被鎖定。

理想的一步是重新編寫查詢以阻止將tempdb鎖定其整個持續時間，但是，我猜這是不容易的。

您可以嘗試設置SQL的第二個實例來運行此數據庫。這樣，任何臨時鎖定只會影響其本身，而不會影響服務器上的任何其他數據庫。

要解決在同一數據庫上運行的其他查詢的問題，您可以查看多個臨時數據庫文件。

但是，一旦你想要解決這個問題，你真的需要返回問題查詢並嘗試使其佔用空間更小。正如克里斯汀評論的那樣，簡單地改變創建臨時表的方式會對事物的鎖定方式產生重大影響。

Answer 2

聲音像表格沒有正確索引。一個有120萬行的表不應該帶任何東西來查詢。我有超過六千萬行的表格，我以毫秒爲單位查詢該表格。

什麼查詢看起來像什麼，表是什麼樣的？