谈谈我的微软特约稿：《SQL Server 2014 新特性：IO资源调控》

一.本文所涉及的内容（Contents）

1. 本文所涉及的内容（Contents）
2. 背景（Contexts）
3. 撰写经历（Experience）
4. 特约稿正文（Content-body）
   1. 第一部分：生活中资源调控器；
   2. 第二部分：SQL Server中资源调控器；
   3. 第三部分：SQL Server资源调控器运用场景—CPU；
   4. 第四部分：SQL Server资源调控器运用场景—IO；
   5. 第五部分：总结；
   6. 第六部分：作者简介；
5. SQL Server 2014 新特性文章链接（IT168）

二.背景（Contexts）

　　写这篇文章的目的是想记录这次的撰写文章的经历，其实一篇技术文章来得并不容易，之前自己写博客的随意性很强，排版可以根据自己喜好，但是一篇文章要被大家所接受，让大家愿意读完其实是一件很难的事情，所以排版还是挺重要的，这里我想提示下IT168的编辑，我的SQL代码其实是有高亮的，但是编辑发出来后发现高亮不见，阅读起来的确很不爽，估计大家也有同样的感觉。再者就是讲讲这次的技术内容，其实在SQL Server 2014之前就有资源调控器这个功能了，所以网上也不少这方面的资料，所以要写这个主题就需要找到一些新的亮点（新功能+通俗类比），这也是读者感兴趣的地方。我对写这篇文章还有一个感受就是，你需要不断修改、完善你文章的内容，包括整体文章的架构是否合理？语言描述是否通顺？逻辑是否清晰？内容是否丰富？测试案例是否全面等等。所以这篇文章给我最大的感受是：一篇凭良心出品的文章的确来之不易。

　　2014年5月7日，从宋沄剑宋大侠得知有一个为IT168和微软撰写SQL Server 2014新功能文章的机会，撰写的内容为：SQL Server 2014的资源调控器（Resource Governor），这里再次感谢宋大侠的推荐。

三.撰写经历（Experience）

1. 接到任务的时候在忙公司的事情，简单看了看这个功能在网上的介绍，大概了解下之后就继续忙其它工作了；
2. 过了几天，感觉是时候动手撰写这篇文章了，继续查资料，简单做了下构思，就动手搭了文章的基本框架；
3. 框架搭建完，写了部分的描述，这需要一个环境进行测试，马上想到了在Azure创建一个带有SQL Server 2014的虚拟机，简单的测试了Resource Governor的CPU控制功能；
4. 继续写内容，突然有个灵感，我想把生活中的BRT引用到文中来，因为他们之间有着许多的共同点，而且可以作为开篇，让读者一下子就能在生活中找到共鸣；
5. 努力找BRT的图片当中；
6. 看到MSDN上关于Resource Governor的架构图，感觉有些不妥，于是就自己画了一个新的，而且我也可以画一个关于BRT的架构图，把公路资源这种画到图里面去，更加能通过BRT架构图引出Resource Governor的架构图；
7. 对Resource Governor的IO进行了测试和场景的设计与分析；
8. 继续对文章的架构进行调整，组织语言，初稿出来了；
9. 把文章发给宋沄剑，希望能得到一些建议，首先得到了他的肯定，同时他建议在开头和结尾加入云服务的概念，马上动手，确定后，再发一次给他，他转发给了IT168的编辑，在期待中煎熬度过；
10. 过了几天，想了想，为了避免编辑的修改建议，继续对文章进行再一次的修改，无论从语言、结构、描述等等方面继续完善，看得都感觉要吐了，再次转发给宋沄剑了；
11. 2014年5月27日，从宋沄剑那里得知，文章一次性通过了IT168和微软的审核了，爽了；
12. 2014年5月28日，文章在IT168的首页发布了；

四.特约稿正文（Content-body）

特此说明：由于版权的原因，这里的正文为引用IT168的稿件地址：http://tech.it168.com/a2014/0526/1627/000001627131_all.shtml

　　【IT168 专稿】在数据库服务器上，有三种硬件资源一直是影响数据库性能好坏的关键，甚至会影响到整个生产系统的使用，这三种资源分别是内存、CPU和物理IO。当数据库服务器上挂载了多个数据库的时候，极有可能发生资源的争夺，如何能保证重要数据库在拥有足够资源的前提下再把多余的资源提供给其它数据库呢?资源调控器应运而生。

在SQL Server 2014中已经增加了对物理IO资源的控制，这个功能在私有云的数据库服务器上的作用体现得尤为重要，它能够为私有云用户提供有效的控制、分配，并隔离物理IO资源。

一、生活中资源调控器

　　在讲述SQL Server 2014的资源调控器(Resource Governor)之前，让我们来找一找生活中资源调控器的影子。大家都知道一线城市的交通可以用拥堵一词来形容，你时常可以见到如图1所示的路面状况。

▲图1：生活中的资源调控器——城市交通

　　为了缓解拥堵的交通，北京、上海、广州等城市都修建了一个称之为BRT的交通设施，BRT的全称为Bus Rapid Transit，意为快速公交，就是在拥堵的公路上分配一条专门提供给公交车使用的车道，尽量保证大部分人出行的通畅。BRT专用车道的大致情况如图2所示。

▲图2：生活中的资源调控器——BRT专用车道

　　交通部门规定：在出行高峰期，BRT专用道只供公交车使用，其它机动车只能使用BRT专用道之外的车道资源。人有专门的人行道，自行车有自行车道。根据这个逻辑，可以得出如图3所示的人与车在使用道路资源的逻辑结构图：

▲图3：道路资源逻辑结构图

二、SQL Server中资源调控器

　　了解了生活中的资源调控器之后，我们马上进入今天的主题：SQL Server资源调控器，它与生活中的资源调控器有着惊人的相似之处。

　　SQL Server 2014的资源调控器默认包含了两个工作负荷组(internal、default)和两个资源池(internal、default)，在没有手动设置资源调控器的情况下，创建的数据库会默认放到default资源池当中。

　　SQL Server资源调控器接收到会话请求后，通过用户定义的分类器函数把会话进行划分并路由到相应的工作负荷组，再通过工作负荷组找到对应的资源池，由资源池中设置的内存、CPU和物理IO资源的阀值来决定会话请求的资源分配。根据描述，可以得出如图4所示的SQL Server资源调控器逻辑结构图：

▲图4：SQL Server资源调控器逻辑结构图

三、SQL Server资源调控器运用场景—CPU

　　理解了SQL Server资源调控器的原理之后，接着讲述资源调控器在CPU方面的运用场景：假设数据库服务器上有一个重要的数据库ImportantDB和一个普通的数据库GeneralDB，从业务出发，希望服务器上的资源在满足了ImportantDB之后才考虑分配多余的资源给GeneralDB，保证重要业务系统的正常运行。

　　需要说明的是：笔者的机器是Azure上的虚拟机，机器的配置如图5所示，下面的测试都是基于这个环境的，所以读者在自行测试的时候应该根据自己的机器环境进行调整。

▲图5：硬件环境

假设GeneralDB 数据库占用的CPU最大值为10%，ImportantDB数据库占用的CPU最大值为90%，实现这个需求的步骤如下：

1. 创建测试数据库

--创建重要业务数据库
CREATE DATABASE ImportantDB
GO
--创建普通业务数据库
CREATE DATABASE GeneralDB
GO

2. 创建并配置新的资源池和工作负荷组

--创建重要业务数据库的资源池
CREATE RESOURCE POOL rpImportantDB
WITH
(
     MAX_CPU_PERCENT = 90,
     MIN_CPU_PERCENT = 10
)
GO
--创建重要业务数据库的工作负荷组
CREATE WORKLOAD GROUP wgImportantDB
WITH
(
     IMPORTANCE = MEDIUM
)
USING rpImportantDB
GO

--创建普通业务数据库的资源池
CREATE RESOURCE POOL rpGeneralDB
WITH
(
     MAX_CPU_PERCENT = 10,
     MIN_CPU_PERCENT = 0
)
GO
--创建重要业务数据库的工作负荷组
CREATE WORKLOAD GROUP wgGeneralDB
WITH
(
     IMPORTANCE = LOW
)
USING rpGeneralDB
GO

3. 更新内存中资源调控器的配置

--更新内存中的配置
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

4. 查询资源调控器中资源池和工作负荷组的配置信息，返回结果如图6所示：

--查询获取资源池和工作负荷组配置
USE master
SELECT * FROM sys.resource_governor_resource_pools
SELECT * FROM sys.resource_governor_workload_groups
GO

▲图6

5. 创建分类器函数，这是一个用户自定义函数 (UDF)，它供资源调控器用来对会话进行分类，以便将它们路由到对应的工作负荷组中，函数返回工作负荷组的名称；

--创建分类器函数
CREATE FUNCTION fn_Classifier()
RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @strGroupName SYSNAME
    IF ORIGINAL_DB_NAME()='ImportantDB'
        SET @strGroupName='wgImportantDB'
    ELSE IF ORIGINAL_DB_NAME()='GeneralDB'
        SET @strGroupName='wgGeneralDB'
    ELSE
        SET @strGroupName='default'
    RETURN @strGroupName
END
GO

6. 将分类器函数fn_Classifier注册到资源调控器并更新内存中的配置

--注册分类器函数到资源调控器并更新内存中的配置
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fn_Classifier)
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

7. 接下来就是对CPU进行测试，创建能占用CPU的测试脚本，把下面的脚本分别保存为GeneralDB.sql和ImportantDB.sql：

--测试CPU
DECLARE @Counts INT
WHILE 1=1
BEGIN
    SELECT @Counts=COUNT(*) FROM SYS.COLUMNS A,SYS.COLUMNS B
END

8. Windows操作系统为SQL Server资源调控器提供了大量的性能计数器帮助了解资源的使用情况，查看SQLServer:Resource Pool Stats对象下的CPU usage%计数器，里面包括四个对象实例：default、internal和刚刚创建的rpGeneralDB、rpImportantDB，如图7所示：

▲图7：添加计数器

9. 因为分类器函数fn_Classifier 通过函数ORIGINAL_DB_NAME()返回用户在数据库连接字符串中指定的数据库名称，所以可以通过使用SQLCMD来模拟用户输入，SQLCMD调用GeneralDB.sql和ImportantDB.sql脚本的命令如下：

SQLCMD -S . -d GeneralDB -i GeneralDB.sql

SQLCMD -S . -d ImportantDB -i ImportantDB.sql

10. 性能计数器CPU usage%记录了在测试过程中CPU的使用情况，结果如图8所示：

▲图8：性能计数器

　　执行GeneralDB.sql后，蓝色实例rpGeneralDB占用了25%左右的CPU;接着在另外的窗口执行ImportantDB.sql后，紫色实例rpImportantDB同样占用了25%左右的CPU，以同样的方式继续增加紫色实例rpImportantDB的CPU占用量，当占用量超过了设置的90%，可以发现蓝色实例rpGeneralDB占用CPU百分比马上下降了。从这个测试的结果来看，SQL Server资源调控器已经达到我们预期对CPU资源的规划效果。

　　值得一提的是，大家可能已经发现rpImportantDB资源池的CPU usage%计数器的最新值高达97.470%，资源池不是设置了MAX_CPU_PERCENT = 90吗?怎么会超过这个限制呢?其实这是因为rpGeneralDB资源池的MIN_CPU_PERCENT = 0，所以在没有其它最小CPU的限制的话，rpImportantDB资源池占用的CPU是有可能达到100%的。

四、SQL Server资源调控器运用场景—IO

　　前面讲述关于CPU资源的控制更多的是为下面讲述SQL Server 2014在IO资源上的调控做铺垫，上面的例子是以数据库为单位规划各个库占用CPU的百分比，下面的例子我们就将以登陆用户来划分磁盘的IOPS;

　　假设generalUser用户占用的IOPS最大值为10，importantUser用户占用IOPS的最大值为20，实现这个需求的步骤如下：

1. 首先，解除分类器函数与资源调控器注册关系；

USE [master]
GO
--解除分类器函数注册
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = NULL)
GO

2. 接着，修改rpImportantDB、rpGeneralDB资源池，添加MAX_IOPS_PER_VOLUME和MIN_IOPS_PER_VOLUME两个属性值；

--修改重要业务数据库的资源池
ALTER RESOURCE POOL rpImportantDB
WITH
(
     MAX_CPU_PERCENT = 90,
     MIN_CPU_PERCENT = 10,
     MAX_IOPS_PER_VOLUME = 20,
     MIN_IOPS_PER_VOLUME = 0
)

--修改普通业务数据库的资源池
ALTER RESOURCE POOL rpGeneralDB
WITH
(
     MAX_CPU_PERCENT = 10,
     MIN_CPU_PERCENT = 0,
     MAX_IOPS_PER_VOLUME = 10,
     MIN_IOPS_PER_VOLUME = 0
)
GO

3. 接着修改分类器函数fn_Classifier()，把它修改成按照登陆用户：importantUser和generalUser（这两个登陆用户请自行创建，为了方便测试，这两个用户都是管理员身份）返回对应的工作负荷组名称；

--修改分类器函数
ALTER FUNCTION fn_Classifier()
RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @strGroupName SYSNAME
    IF SUSER_SNAME()='importantUser'
        SET @strGroupName='wgImportantDB'
    ELSE IF SUSER_SNAME()='generalUser'
        SET @strGroupName='wgGeneralDB'
    ELSE
        SET @strGroupName='default'
    RETURN @strGroupName
END
GO

4. 重新把分类器函数fn_Classifier()注册到资源调控器并更新内存中的配置；

--注册分类器函数到资源调控器并更新内存中的配置
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fnClassifier)
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

5. 在GeneralDB数据库中创建一个名为TestIOPS的表，并向表中插入10000行记录；

USE [GeneralDB]
GO
--创建表
CREATE TABLE [dbo].[TestIOPS](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [MyStr] [nchar](450) NULL
) ON [PRIMARY]
GO

--插入测试数据
SET NOCOUNT ON;
GO
DECLARE @count INT = 0;
WHILE (@count < 10000)
BEGIN
    INSERT INTO [GeneralDB].[dbo].[TestIOPS](MyStr)
        VALUES(REPLICATE('a',450));
    SET @count +=  1;
END
GO

6. 使用generalUser用户登陆SSMS，通过在TestIOPS表的MyStr字段创建一个非聚集索引来测试IOPS，在执行创建索引的脚本之前，打开性能计数器帮助监控创建索引时的IOPS，找到SQLServer:Resource Pool Stats对象下的Disk Write IO/sec计数器，计数器监控的结果如图9所示：

USE [GeneralDB]
GO
--创建索引
CREATE NONCLUSTERED INDEX idx_MyStr_1 ON [GeneralDB].[dbo].[TestIOPS] ([MyStr]);
GO

▲图9：计数器监控结果

　　从图9可以看出资源池rpGeneralDB 中Disk Write IO/sec计数器的最大值为10，发生Disk Write IO/sec的时间从22:54:52持续到22:55:02，持续时间大概为20秒；

7. 接着，使用importantUser用户登陆SSMS，创建上一步骤中一样的索引结构，只需要修改索引名称即可，同样需要监控SQLServer:Resource Pool Stats对象下的Disk Write IO/sec计数器，计数器监控的结果如图10所示：

USE [GeneralDB]
GO
--创建索引
CREATE NONCLUSTERED INDEX idx_MyStr_2 ON [GeneralDB].[dbo].[TestIOPS] ([MyStr]);
GO

▲图10：Write IO/sec计数器监视结果

　　从图10可以看出资源池rpImportantDB 中Disk Write IO/sec计数器的最大值为20，发生Disk Write IO/sec的时间从22:59:52持续到23:00:11，持续时间大概为9秒;

　　通过上面资源调控器的IOPS的测试，可以发现即使两个用户执行了相同操作，但IOPS却可以根据不同用户而有所区别，这完全归功于资源调控器对IO资源的控制，这将为数据库主机或者私有云上运行IO密集型工作负载提供解决方案。

五、总结

　　资源调控器(Resource Governor)在没有资源争夺的时候，那么运用可以分配到100%资源，如果达到了分类器函数的临界值，会按照预先分配的比例进行调配，从而保证重要业务在资源紧缺的情况下顺利进行，增强对数据库的管理性。SQL Server 2014的新功能中提供了一个非常重要的IO资源控制，这将为私有云用户提供更人性化的管理和服务。

作者简介

　　陈畅亮，微软SQL Server最有价值专家，目前就职于广州某互联网公司任数据库团队Leader，专注于数据库解决方案与性能调优。

五.SQL Server 2014 新特性文章链接（IT168）

• SQL Server 2014内存数据库深度解析
• SQL Server 2014新特性：SSD缓冲区扩展
• SQL Server 2014 可更新聚集列存储索引
• SQL Server 2014新特性：IO资源调控
• SQL Server 2014新特性：原生备份加密
• SQL Server 2014云特性：无缝集成公有云