在今天的文章里，我想谈下sql server 2014里非常酷的提升：现在你终于可以根据需要的iops来压制查询！资源调控器（resource governor）自sql server 2008起引入，但提供的功能还是有所限制：你只能限制cpu时间（这个已经很棒了），还有你能限制查询（从每个独立的查询）内存量。
但作为dba的你，你经常会进行一些数据库维护操作，例如索引重建，dbcc checkdb操作等。我们都知道，这些操作会在你的存储里带来大量的iops直至峰值。如果在7 * 24在线的数据库来说，这个会影响你的生产力，给业务和销售额带来很大影响。
自sql server 2014开始，这个情况就变了，因为你可以通过资源调控器来部署指定的资源池来限制iops使用率。当你隔离你的dba操作到指定的资源池时，你能指定资源池可以使用的最大iops（包括最小iops）。因此你可以压制下dba操作需要的iops。你的生产工作量就可以更好的使用你的存储。更多信息可以查看微软在线帮助。
我想用一个非常简单的例子来展示下这个行为。假设你是dba，正要进行常规索引重建操作，这个需要通过资源调控器对它们的最大iops使用率进行控制。第1步我们为dba操作创建专用的资源池和工作负荷组。
-- create a new resource pool for the dbas. -- we use a very high value for max_iops_per_volume so that we are -- currently running unlimited. create resource pool dbapool with ( max_iops_per_volume = 100000 ) go
-- create a new workload group for the dbas create workload group dbagroup using dbapool go
从刚才的代码可以看到，create resource pool语句现在为你提供max_iops_per_volume属性（包括min_iops_per_volume）。这里我设置了一个很高的值，因此在第一次执行时iops不会受限，这里我们根据需要的iops建立了初始基线。下一步我会创建资源调控器需要的分类函数。
-- create a new classifier function for resource governor create function dbo.myclassifierfunction() returns sysname with schemabinding as begin declare @groupname sysname if suser_name() = 'dbauser' begin set @groupname = 'dbagroup' end else begin set @groupname = 'default' end return @groupname; end go
在分类函数里我们根据登录进行评估。如果登录是dbauser，进入的会话会在dbagroup工作负荷组里。否则就进入默认的工作负荷组。最后我们在资源调控器注册并配置它，这样我们的设置就生效了。
-- register the classifier function within resource governor alter resource governor with ( classifier_function = dbo.myclassifierfunction ) go
-- reconfigure resource governor alter resource governor reconfigure go
现在当你创建名为dbauser的登录时，你可以用它连接到你的sql server。你可以在dmv sys.dm_exec_sessions 看下 group_id列验证下到来的会话是否在正确的工作负荷组里。下一步我在contoretaildw数据库的factonlinesales表里的datakey里创建一个非聚集索引。
-- create a simple non-clustered index create nonclustered index idx_datekey on factonlinesales(datekey) go
我们从开始就创建了资源池，现在在我们在我们的资源池里并没有限制。因此当我们现在进行刚才创建的非聚集索引的索引重建时，sql server会占用大量的iops。我们可以通过性能监控里的“sql server:resource pool stats:disk write io/sec”性能计数器来验证刚才创建的资源池。
alter index idx_datekey on factonlinesales rebuild go
可以看到索引重建花费近100的iops。接下来我要做的是限制dbapool资源池为仅50的iops：
-- let's change the resource pool by lowering the maximum iops. alter resource pool dbapool with ( max_iops_per_volume = 50 ) go
现在当你执行索引重建时，在性能监视器里可以清楚看到，在特定的资源池里只有平均50 iops。
另外disk write io throttled/sec性能计数器也会告诉为你资源调控器的iops的限制数。
使用以前的资源调控器，查询本身毫无办法，它是否被压制了。这对性能调优也是个非常重要的因素。当启用资源调控器时，没有特定的等待类型出现在sql server里。我的测试显示一旦资源调控器启用时，有更多的pageiolatch_sh/pageiolatch_ex等待类型，这就对了。下面2个图片显示了对于发生索引重建的会话里具体的等待类型信息——第1个没有资源调控器，第2个有资源调控器压制了iops。
从2个图中可以看到，2个运行的测试有巨大的区别，尤其是在pageiolatch_ex 和 sos_scheduler_yield等待类型。
从我站在iops压制来看，对于已有的功能来说，资源调控器是个很好的附加，这让资源调控器更加成熟。
大家可以尝试用这个新功能解决iops方面的问题。
以上所述就是本文的全部内容，希望对大家的学习有所帮助。