SQL Server OS是在Windows之上，用于服務SQL Server的一個用戶級別的操作系統(tǒng)層次。它將操作系統(tǒng)部分的功能從整個SQL Server引擎中抽象出來，單獨形成一層，以便為存儲引擎提供服務。SQL Server OS主要提供了任務調(diào)度、內(nèi)存分配、死鎖檢測、資源檢測、鎖管理、Buffer Pool管理等多種功能。本篇文章主要是談一談SQL OS中所提供的任務調(diào)度機制。

數(shù)據(jù)庫層面的任務調(diào)度的起源是ACM上的一篇名為“Operating System Support for Database Management”。但是對于Windows來說，在操作系統(tǒng)層面專門加入支持數(shù)據(jù)庫的任務調(diào)度，還不如在SQL Server中專門抽象出來一層進行調(diào)度，既然可以抽象出來一層進行數(shù)據(jù)庫層面的任務調(diào)度，那么何不在這個抽象層進行內(nèi)存和IO等的管理呢？這個想法，就是SQL Server OS的起源。

在Windows NT4之后，Windows任務調(diào)度是搶占式的，也就是說Windows任務是根據(jù)任務的優(yōu)先級和時間片來決定。如果一個任務的時間片用完，或是有更高優(yōu)先級的任務正在等待，那么操作系統(tǒng)可以強制剝奪正在運行的線程（線程是任務調(diào)度的基本單位）所占用的CPU，將CPU資源讓給其它線程。

但是對于SQL Server來說，這種非合作式的、基于時間片的任務調(diào)度機制就不那么合適了。如果SQL Server使用Windows內(nèi)的任務調(diào)度機制來進行任務調(diào)度的話，Windows不會根據(jù)SQL Server的調(diào)度機制進行優(yōu)化，只是根據(jù)時間片和優(yōu)先級來中斷線程，這會導致如下兩個缺陷:

而對于SQL Server OS來說，線程調(diào)度采用的合作模式而不是搶占模式。這是因為這些數(shù)據(jù)庫內(nèi)的任務都在SQL Server這個SandBox之內(nèi)，SQL Server充分相信其內(nèi)線程，所以除非線程主動放棄CPU，SQL Server OS不會強制剝奪線程的CPU。這樣一來，雖然Worker之間的切換依然是通過Windows的Context Switch進行，但這種合作模式會大大減少所需Context Switch的次數(shù)。

SQL Server決定哪一個時間點哪一個線程運行，是通過一個叫Scheduler的東西進行的，下面讓我們來看Scheduler。

SQL Server中每一個邏輯CPU都有一個與之對應的Scheduler，只有拿到Scheduler所有權的任務才允許被執(zhí)行，Scheduler可以看做一個隊SQLOS來說的邏輯CPU。您可以通過sys.dm_os_schedulers這個DMV來看系統(tǒng)中所有的Scheduler，如圖1所示。

我的筆記本是一個i7四核8線程的CPU，對應的，可以看到除了DAC和運行系統(tǒng)任務的HIDDEN Scheduler，剩下的Scheduler一共8個，每個對應一個邏輯CPU，用于處理內(nèi)部Task。當然，您也可以通過設置Affinity來將某些Scheduler Offline，如圖2所示。注意，這個過程是在線的，無需重啟SQL Server就能實現(xiàn)。

此時，無需重啟實例就能看到4個Scheduler被Offline,如圖3所示:

一般來說，除非您的服務器上運行其他實例或程序，否則不需要控制Affinity。

在圖1中，我們還注意到，除了Visible的Scheduler之外，還有一些特殊的Scheduler，這些Scheduler的ID都大于255，這類Scheduler都用于系統(tǒng)內(nèi)部使用，比如說資源管理、DAC、備份還原操作等。另外，雖然Scheduler和邏輯CPU的個數(shù)一致，但這并不意味著Scheduler和固定的邏輯CPU相綁定，而是Scheduler可以在任何CPU上運行，只有您設置了Affinity Mask之后，Scheduler才會被固定在某個CPU上。這樣的一個好處是，當一個Scheduler非常繁忙時，可能不會導致只有一個物理CPU繁忙，因為Scheduler會在多個CPU之間移動，從而使得CPU的使用傾向于平均。

這意味著對于一個比較長的查詢，可以前半部分在CPU0上執(zhí)行，而后半部分在CPU1上執(zhí)行。

另外，在每一個Scheduler上，同一時間只能有一個Worker運行，所有的資源都就緒但沒有拿到Scheduler，那么這個Worker就處于Runnable狀態(tài)。下面讓我們來看一看Worker。

每一個Worker可以看做是對應一個線程（或纖程），Scheduler不會直接調(diào)度線程，而是調(diào)度Worker。Worker會隨著負載的增加而增加，換句話說，Worker是按需增加，直到增加到最大數(shù)字。在SQL Server中，默認的Worker最大數(shù)是由SQL Server進行管理的。根據(jù)32位還是64位，以及CPU的數(shù)量來設置最大Worker,具體的計算公式，您可以參閱BOL：(v=sql.105).aspx。當然您也可以設置最大Worker數(shù)量，如圖4所示。

如果是自動配置，那么SQL Server的最大工作線程數(shù)量可以在sys.dm_os_sys_info中看到，如圖5所示。

Worker實際上會對應Windows上的一個線程，并與某個特定Scheduler綁定，每一個Worker只要開始執(zhí)行Task,除非Task完成，否則Worker永遠不會放棄這個Task,如果一個Task在運行過程由于鎖、IO等陷入等待，那么實際上Worker就會陷入等待。

此外，同一個連接內(nèi)的多個Batch之間傾向于使用同一個Worker,比如第一個Batch使用了Worker 100,那么第二個Batch也同樣傾向于是用Worker 100，但這并不絕對。

正在運行的任務所是用的Worker，我們可以通過DMV sys.dm_exec_requests查看正在運行的任務，其中的Task_Address列可以看到正在運行的Task,再通過sys.dm_os_tasks的Worker_Address來查看對應的Worker。

SQL Server會為每一個Worker保留大約2M左右的內(nèi)存，對于每一個Scheduler上所能有的Worker數(shù)量是服務器的最大Worker數(shù)量/在線的Scheduler,每一個Scheduler所綁定的Worker會形成Worker池，這意味著每一個Scheduler需要Worker時，首先在Worker池中中查找空閑的Worker，如果沒有空閑的Worker時，才會創(chuàng)建新的Worker。這個行為會和連接池類似。

那么當一個Scheduler空閑超過15分鐘，或是Windows面臨內(nèi)存壓力時。SQL Server就會嘗試Trim這個Worker池來釋放被Worker所占用的內(nèi)存。

Task是Worker上運行的最小任務單元。只能拿到Worker的Task才能夠運行。我們可以看下面一個簡單的例子，如代碼1所示。

SELECT @@VERSION goSELECT @@SPID go