SQL Server 2005查询处理结构-用户模式计划（UMS）

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、内存、锁都会出现这样的情况。