SQL Server 2005查詢處理結(jié)構(gòu)-用戶模式計劃（UMS）

?

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

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

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

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

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

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

??處理器計劃的內(nèi)部執(zhí)行步驟：

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

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

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

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

?（5）查詢的結(jié)果必須打包并傳送回客戶端，需要內(nèi)存、處理器資源和網(wǎng)絡I/O；

?

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

轉(zhuǎn)載于:https://www.cnblogs.com/dbasys/archive/2009/01/08/1371784.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。