SQL Server 2005查詢處理結構-用戶模式計劃（UMS）

?

?? 在對數據庫進行性能調優時，必須全面的考慮各種可能造成系統性能瓶頸的各種因素，因此深入了解SQL Server 2005的查詢處理機構是非常有必要的。下面，我就重點介紹一下用戶模式計劃（UMS）。

?? SQL Server 使用協同多處理器模式取代了對稱多處理器模式。這兩種處理模式之間最大的區別在于處理器處理計劃方式不同。在協同模式下，同一時間在一個處理器上只能運行一個線程，并且當這個線程沒有任務要運行時，就會放棄對處理器的控制權。在這種方式下，可以允許多個線程相互協同使實際執行的任務數量最大化。

???控制這個協同行為是用戶模式計劃（User Mode Scheduler ，UMS）的任務。SQL Server啟動時，會為每個邏輯的或物理的處理器創建一個UMS，并且這個UMS可以在系統中使用。這樣，SQL Server就可以通過UMS執行自己的計劃，而不是將線程發送到操作系統，由操作系統按計劃在處理器上執行，認識到這一點是非常重要的。

??創建一個SQL Server的連接時，它對應的SPID就會分配到UMS。這個分配的進程就會采用一個基本的平衡算法，以實現盡可能的將進程平均的分散在多個UMS中。盡管一個連接請求通常會在同一個UMS中執行，但是這個請求通常會在同一UMS中執行，但是這個請求還是有可能在任何可用的UMS中處理。

??每個UMS都使用三個隊列來處理查詢：可執行的、正在執行的和等待中的。隊列中的線程遵循先進先出的原則。當一個查詢執行時，會為它分配一個線程并將這個線程放入到可執行的隊列中，可執行隊列中的線程會占用處理器。如果線程需要等待I/O、網絡或內存等資源的配置時，它就會停止處理器的占用，并移入等待中的隊列。

??等待分配資源的線程會一直保存在等待的隊列中。這是，SQL Server會跟蹤這個線程等待的時間量，并用等待時間表示，當分配的資源得到時，就用等待的類型表示。一旦得到分配的資源，這個線程就會從等待隊列中轉入可執行的隊列的底部。一個進程從可執行的隊列到轉入處理器上之前所花費的時間叫一次等待。?

??處理器計劃的內部執行步驟：

?（1）查詢首先必須被編譯，需要內存和處理器資源；

?（2）編譯過的計劃必須保存在查詢緩存中， 需要內存和處理器資源；

?（3）執行計劃會轉入到處理器中以執行這個查詢，需要內存、處理器資源和潛在的磁盤I/O；

?（4）當查詢讀/寫數據時，必須建立鎖，可能需要更多的內存、處理器資源和磁盤I/O

?（5）查詢的結果必須打包并傳送回客戶端，需要內存、處理器資源和網絡I/O；

?

?由以上步驟可看，內存必須至少被分配5次。如果系統內存緊張，這個進程就不得不每次都要等待所需要的內存分配，這也就導致了需要5次轉入到等待的隊列中，然后又需要5次轉回到可執行隊列。如果發生這樣的情況，每次資源的分配都會增加查詢的持續時間，查詢效率就會降低，形成內存瓶頸。同樣道理，CPU、磁盤I/O、內存、鎖都會出現這樣的情況。

轉載于:https://www.cnblogs.com/dbasys/archive/2009/01/08/1371784.html

總結

以上是生活随笔為你收集整理的SQL Server 2005查询处理结构-用户模式计划（UMS）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。