转载

在SQL Server 2014里，如何用资源调控器压制你的存储？

在今天的文章里，我想谈下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操作创建专用的资源池和工作负荷组。

 1 -- Create a new Resource Pool for the DBAs.  2 -- We use a very high value for MAX_IOPS_PER_VOLUME so that we are  3 -- currently running unlimited.  4 CREATE RESOURCE POOL DbaPool WITH  5 (  6     MAX_IOPS_PER_VOLUME = 100000  7 )  8 GO  9  10 -- Create a new Workload Group for the DBAs 11 CREATE WORKLOAD GROUP DbaGroup 12 USING DbaPool 13 GO

从刚才的代码可以看到， CREATE RESOURCE POOL 语句现在为你提供 MAX_IOPS_PER_VOLUME 属性（包括 MIN_IOPS_PER_VOLUME ）。这里我设置了一个很高的值，因此在第一次执行时IOPS不会受限，这里我们根据需要的IOPS建立了初始基线。下一步我会创建资源调控器需要的分类函数。

 1 -- Create a new Classifier Function for Resource Governor  2 CREATE FUNCTION dbo.MyClassifierFunction()  3 RETURNS SYSNAME WITH SCHEMABINDING  4 AS  5 BEGIN  6     DECLARE @GroupName SYSNAME  7       8     IF SUSER_NAME() = 'DbaUser'  9     BEGIN 10         SET @GroupName = 'DbaGroup' 11     END 12     ELSE 13     BEGIN 14         SET @GroupName = 'Default' 15     END 16      17     RETURN @GroupName; 18 END 19 GO

在分类函数里我们根据登录进行评估。如果登录是DbaUser，进入的会话会在DbaGroup工作负荷组里。否则就进入默认的工作负荷组。最后我们在资源调控器注册并配置它，这样我们的设置就生效了。

 1 -- Register the Classifier Function within Resource Governor  2 ALTER RESOURCE GOVERNOR WITH  3 (  4     CLASSIFIER_FUNCTION = dbo.MyClassifierFunction  5 )  6 GO  7   8 -- Reconfigure Resource Governor  9 ALTER RESOURCE GOVERNOR RECONFIGURE 10 GO

现在当你创建名为DbaUser的登录时，你可以用它连接到你的SQL Server。你可以在DMV sys.dm_exec_sessions 看下 group_id列验证下到来的会话是否在正确的工作负荷组里。下一步我在ContoRetailDW数据库的FactOnlineSales表里的DataKey里创建一个非聚集索引。

1 -- Create a simple Non-Clustered Index 2 CREATE NONCLUSTERED INDEX idx_DateKey ON FactOnlineSales(DateKey) 3 GO

我们从开始就创建了资源池，现在在我们在我们的资源池里并没有限制。因此当我们现在进行刚才创建的非聚集索引的索引重建时，SQL Server会占用大量的IOPS。我们可以通过性能监控里的“ SQL Server:Resource Pool Stats:Disk Write IO/Sec ”性能计数器来验证刚才创建的资源池。

1 ALTER INDEX idx_DateKey ON FactOnlineSales REBUILD 2 GO

在SQL Server 2014里，如何用资源调控器压制你的存储？

可以看到索引重建花费近100的IOPS。接下来我要做的是限制DbaPool资源池为仅50的IOPS：

1 -- Let's change the Resource Pool by lowering the maximum IOPS. 2 ALTER RESOURCE POOL DbaPool WITH 3 ( 4     MAX_IOPS_PER_VOLUME = 50 5 ) 6 GO

现在当你执行索引重建时，在性能监视器里可以清楚看到，在特定的资源池里只有平均50 IOPS。

在SQL Server 2014里，如何用资源调控器压制你的存储？

另外 Disk Write IO Throttled/sec 性能计数器也会告诉为你资源调控器的IOPS的限制数。

使用以前的资源调控器，查询本身毫无办法，它是否被压制了。这对性能调优也是个非常重要的因素。当启用资源调控器时，没有特定的等待类型出现在SQL Server里。我的测试显示一旦资源调控器启用时，并没有更多的 PAGEIOLATCH_SH/PAGEIOLATCH_EX 等待类型，这就对了。下面2个图片显示了对于发生索引重建的会话里具体的等待类型信息——第1个没有资源调控器，第2个有资源调控器压制了IOPS。

在SQL Server 2014里，如何用资源调控器压制你的存储？