基于SQL Server OS的任务调度机制详解
SQL Server OS是在Windows之上，用于服务SQL Server的一个用户级别的操作系统层次。它将操作系统部分的功能从整个SQL Server引擎中抽象出来，单独形成一层，以便为存储
SQL Server OS是在Windows之上，用于服务SQL Server的一个用户级别的操作系统层次。它将操作系统部分的功能从整个SQL Server引擎中抽象出来，单独形成一层，以便为存储引擎提供服务。SQL Server OS主要提供了任务调度、内存分配、死锁检测、资源检测、锁管理、Buffer Pool管理等多种功能。本篇文章主要是谈一谈SQL OS中所提供的任务调度机制。
抢占式(Preemptive)调度与非抢占式(non-Preemptive)调度数据库层面的任务调度的起源是ACM上的一篇名为“Operating System Support for Database Management”。但是对于Windows来说，在操作系统层面专门加入支持数据库的任务调度，还不如在SQL Server中专门抽象出来一层进行调度，既然可以抽象出来一层进行数据库层面的任务调度，那么何不在这个抽象层进行内存和IO等的管理呢？这个想法，就是SQL Server OS的起源。
在Windows NT4之后，Windows任务调度是抢占式的，也就是说Windows任务是根据任务的优先级和时间片来决定。如果一个任务的时间片用完，或是有更高优先级的任务正在等待，那么操作系统可以强制剥夺正在运行的线程（线程是任务调度的基本单位）所占用的CPU，将CPU资源让给其它线程。
但是对于SQL Server来说，这种非合作式的、基于时间片的任务调度机制就不那么合适了。如果SQL Server使用Windows内的任务调度机制来进行任务调度的话，Windows不会根据SQL Server的调度机制进行优化，只是根据时间片和优先级来中断线程，这会导致如下两个缺陷:
Windows不会知道SQL Server中任务(也就是SQL OS中的Task,会在文章后面讲到)的最佳中断点，这势必会造成更多的Context Switch（Context Switch代价非常非常高昂,需要线程字用户态和核心态之间转换），因为Windows调度不是线程本身决定是否该出让CPU，而是由Windows决定。Windows并不会知道当前数据库中对应的线程是否正在做关键任务，只会不分青红皂白的夺取线程的CPU。 连入SQL Server的连接不可能一直在执行，每一个Batch之间会有大量空闲时间。如果每个连接都需要单独占用一个线程，那么SQL Server维护这些线程就需要消耗额外的资源，这是很不明智的。而对于SQL Server OS来说，线程调度采用的合作模式而不是抢占模式。这是因为这些数据库内的任务都在SQL Server这个SandBox之内，SQL Server充分相信其内线程，所以除非线程主动放弃CPU，SQL Server OS不会强制剥夺线程的CPU。这样一来，虽然Worker之间的切换依然是通过Windows的Context Switch进行，但这种合作模式会大大减少所需Context Switch的次数。
SQL Server决定哪一个时间点哪一个线程运行，是通过一个叫Scheduler的东西进行的，下面让我们来看Scheduler。
Scheduler SQL Server中每一个逻辑CPU都有一个与之对应的Scheduler，只有拿到Scheduler所有权的任务才允许被执行，Scheduler可以看做一个队SQLOS来说的逻辑CPU。您可以通过sys.dm_os_schedulers这个DMV来看系统中所有的Scheduler，如图1所示。
http://msdn.microsoft.com/zh-cn/library/ms187024(v=sql.105).aspx。当然您也可以设置最大Worker数量，如图4所示。
SELECT @@VERSION goSELECT @@SPID go
代码1.一个连接上的两个Batch
代码1中的两个Batch属于一个连接，每一个Batch中都是一个简单的Task,如我们前面所说，这两个Task更倾向于复用同一个Worker，因为他们属于同一个连接。但也有可能，这两个Task使用了不同的Worker,甚至是不同的Scheduler。
除了用户所用的Task之外，还有一些永久的系统Task，这类Task会永远占据Worker,这些Task包括死锁检测、Lazy Writer等。
Task在Scheduler上的平均分配
新的Task还会尝试在Scheduler之间平均分配，可以通过sys.dm_os_schedulers来看到一个load_factor列，这列的值就是用于供Task向Scheduler进行分配时，用来参考。
每次一个新的Task进入Node时，会选择负载最少的的Scheduler。但是，如果每次都来做一次选择，那么就会在Task入队时造成瓶颈(这个瓶颈类似于TempDB SGAM页争抢)。因此SQL OS对于每一个连接，都会记住上次运行的Scheduler ID，在新的Task进入时作为提示(Hint)。但如果一个Scheduler的负载大于所有Scheduler平均值的20%，则会忽略这个提示。负载可以通过上面提到的load_factor列来看，对于某个Task运行的时间比较长，则很有可能造成Scheduler上Task分配的不均匀。
Worker的Yield由于SQL Server是非抢占式调度，那么就不能为了完成某个Task，让Worker占据Scheduler一直运行。如果是这样，那么处于Runnable的Worker将会饥饿，这不利于大量并发，也违背了SQL OS调度的初衷。
因此，在合适的时间点让出Scheduler就是关键。Worker让出CPU使得其它Worker可以运行的过程称之为yield。yield大体可分为两种，一种是所谓的“natural yield”,这种方式是Worker在运行过程中被锁或是某些资源阻塞，此时，该Worker就会让出Scheduler来让其它Worker运行。另外一种情况是Worker没有遇到阻塞，但在时间片到了之后，主动让出Scheduler,这就是所谓的“voluntarily yield”，这也就是SOS_SCHEDULER_YIELD等待类型的由来，一个Worker由RUNNING状态转到WAITING状态的过程被称之为switching。SQL OS的一个基本思想就是，要多进行switching，来保证高并发。下面我们来看几种常见的yield场景:
SQL Server OS中的抢占式任务调度
对于一些代码来说，SQL Server会存在一些抢占式代码。如果您在等待类型中看到“PREEMPTIVE_*”类型的等待，说明这里面的代码正在运行在抢占式任务调度模式。这类任务包括扩展存储过程、调用Windows API、日志增长（日志填0）。我们知道，合作式的任务调度需要任务本身Yield，但这类代码在SQL Server 之外，如果让他们运行在合作式任务调度这个SandBox之内，这类代码如果不yield，则会永远占用Scheduler。这是非常危险的。
因此，在进入抢占式模式之前，首先需要将Scheduler的控制权交给在Runable队列中的下一个Worker。此时，抢占式模式运行的代码不再由SQL OS控制，转而由Windows任务调度系统控制。因此一个Task的生命周期如果再加上转到抢占式任务调度模式，则会如图6所示。
图6.一个Task完整的生命周期 每一个Scheduler的任务调度
对于每一个Scheduler的调度，一个简单的模型如图7所示。
图7.一个Scheduler的调度周期模型
小结
SQL Server OS在Windows之上抽象出一套非抢占式的任务调度机制，从而减少了Context Switch。同时，又有一套线程自己的yield机制，相比Windows随机抢占数据库之内的线程而言，让线程自己来yield则会大量减少Context Switch,从而提升了并发性。
