SQL Server资源调节器的作用
如果有5个业务都很繁忙的数据库需要部署在一台服务器上，为了避免相互的资源抢占，我们通常会在服务器上安装5个SQL Server实例来分别承载这5个数据库，然后分别设置每个实例的最大和最小内存、CPU掩码等，用以s控制这5个业务数据库的资源分配。
笔者的公司曾经就有这样的案例。这种方式的缺点显而易见：首先是授权，在上述例子中，5个SQL Server实例的费用应该是比1个要高；其次是管理成本提高，DBA不得不安装和维护5个实例。那么，有没有更好的方法呢？
其实从SQL Server2008（企业版）开始，微软就已经考虑过这种情况，并提出解决方案——“SQL Server的资源调节器”。SQL Server的资源调节器引入了一种多租户的理念，它将一个SQL Server实例的资源“出租”给不同的客户端负载，每个客户端负载所分配到的资源彼此隔离，互不影响。
下面我们看看SQL Server的资源调节器的原理和一个实例的来了解下SQL Server的资源调节器：
SQL Server的资源调节器的原理
在SQL Server的资源调节器有三个重要的概念：
1. 资源池
在上文多租户的理念中，不同的客户端负载之所以能够分配彼此隔离的资源，其原因就是他们拥有各自独立的资源池。
在资源池里面，DBA可以设置最大、最小内存和CPU资源，也就是说，资源池实际上就是内存和CPU资源的集合，DBA根据业务的需要，可以为重要业务设置较大的资源池，而SLA较低的业务设置小的资源池。
2. 工作组的负载
工作组负载是一些具有共同特征的客户端请求的集合。SQL Server将客户端请求按照一定的规则分类后，形成多个工作组负载。
工作组负载是资源池利用的主体。将不同的资源池绑定到不同的工作组负载，从而实现了各个工作组负载的资源隔离。
3. 分类器
分类器提供一套划分工作组负载的规则，在此规则基础上，SQL Server将客户端的请求进行分类形成多个工作组。
举个例子：把SQL Server的用户名作为一个分类器，来自A用户的所有请求划分到工作组负载1，来自B用户的所有请求划分到工作组负载2。然后工作组负载1和2分别对应不同的资源池。
原理图如下：
用资源调节器来分配两个数据库的CPU资源
假设有市场和销售两个部门，各自使用不同的数据库，但两个数据库在同一个SQL Server实例上，为了确保两个部门的数据库彼此不受对方资源使用的影响，我们使用SQL Server的资源调控器来控制两个数据库的资源使用。
1. 创建测试数据库
create database Sales
create database Marketing
2. 配置CPU环境
为了更好的查看CPU资源的争用情况，我们先设置SQL Server的CPU affinity mask，使SQL Server只能使用一个逻辑核心，所有的工作组负载共享同一个CPU核心资源。
sp_configure 'show advanced', 1
GO
RECONFIGURE
GO
sp_configure 'affinity mask', 1
GO
RECONFIGURE
GO
3. 配置资源调控器
1) 创建资源池
CREATE RESOURCE POOL SalesPool
CREATE RESOURCE POOL MarketingPool
2) 创建工作组负载
--创建SalesGroup的工作组，并绑定到SalesPool
CREATE WORKLOAD GROUP SalesGroup
USING SalesPool
--创建MarketingGroup的工作组，并绑定到MarketingPool
CREATE WORKLOAD GROUP MarketingGroup
USING MarketingPool
GO
3) 创建分类器（分类函数）
--创建自定义的二分类函数，按照客户端连接字符串中的数据库分类并返回数据库的名字
CREATE FUNCTION CLASSIFIER_DbName()
RETURNS SYSNAME WITH SCHEMABINDING
BEGIN
DECLARE @val varchar(32)
SET @val = 'default';
IF 'Sales' = ORIGINAL_DB_NAME()
SET @val = 'SalesGroup';
ELSE IF 'Marketing' = ORIGINAL_DB_NAME()
SET @val = 'MarketingGroup';
RETURN @val;
END
GO
--将分类函数绑定到资源调节器中
ALTER RESOURCE GOVERNOR
WITH (CLASSIFIER_FUNCTION = dbo.CLASSIFIER_DbName)
GO
4) 启用资源调控器
ALTER RESOURCE GOVERNOR RECONFIGURE
GO
4. 测试sales数据库的负载
Ø 创建如下测试SQL语句，并保存到workload.sql文件中
SET NOCOUNT ON
DECLARE @i INT
DECLARE @s VARCHAR(100)
SET @i = 100000000
WHILE @i > 0
BEGIN
SELECT @s = @@version;
SET @i = @i - 1;
END
Ø 以管理员身份运行cmd
Ø 然后以sqlcmd的方式加载workload.sql语句
sqlcmd -S localhostsql2014 -U sa -P 95938 -d Sales –I "d:workload.sql"
这条语句的意思是在sales数据库中执行workload.sql，
Ø 打开性能计数器
SQLServer:Resource Pool Stats->CPU usage
可以看到salespool的CPU资源占用情况如下图：
下图中，salespool CPU资源的使用率为25%，（相当于完全使用了使用了笔者电脑4核CPU中1核资源（前面设置了SQL Server的affinity mask为1））。因为我们在前面的分类器的中把sales数据库绑定到了资源池salespool上了，sales数据库的CPU资源占用情况就是25%。
5. 再测试下sales库和marketing库的资源争用情况
Ø 新开一个cmd窗口，执行如下语句：
sqlcmd -S localhostsql2014 -U sa -P 95938 -d Marketing -i "d:workload.sql"
这条语句的意思是在Marketing数据库中执行workload.sql，
此时出现如下结果：
salespool和marketingPool共享25%的CPU资源（且两者占用的资源量相同（接近），这是因为他们都是采用默认的资源分配权重）。这里的marketingPool同上文中介绍的salespool一样，它也是绑定到了一个数据库，不同的是这里绑定了marketing数据库。
因此，这两个资源池的CPU资源争用反映的就是sales数据库和Marketing数据库的资源争用。
备注：红色的曲线代表sales pool
绿色曲线代表marketingPool
Ø 现在，我们更改销售系统的资源池的CPU资源的权重为70
ALTER RESOURCE POOL SalesPool
WITH (MIN_CPU_PERCENT = 70)
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO
结果如下：
此时salesPool占用的资源将增加到70%，而marketingPool的CPU资源降低到30%，两者按照7:3进行分配。
这样就相当于给sales数据库分配了更多的CPU资源，而削减了marketing的CPU资源。
6. 最后，我们来看一个设置最大CPU资源权重的例子
--设置MarketingPool的最大CPU占用
ALTER RESOURCE POOL MarketingPool
WITH (MAX_CPU_PERCENT = 5)
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO
此时，在marketingPool占用的资源如下图：
如果此时在sales数据库中执行的workload.sql已经执行完毕，则marketing数据库会突破之前设置的MAX_CPU_PERCENT = 5的限制，使用到全部CPU资源，这样的好处就是可以充分利用资源，避免资源浪费。如下图的蓝色框中的曲线。
当然，如果你一定要限制Marketing数据库的CPU资源必须在5%以内，可以通过如下语句实现：
ALTER RESOURCE POOL MarketingPool
WITH (CAP_CPU_PERCENT=5)
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO
总结
SQL Server资源调节器通过资源池、工作组负载、分类器等机制可以为不同的数据库、不同的请求、不同的用户分配彼此独立的CPU、内存、IO等资源，起到资源调节和隔离的作用。通过该技术，我们可以在确保每个数据库分配到合理的资源的前提下，合并多个数据库到同一个实例，也可以为某些SQL代码预定义服务器资源及避免某些SQL语句占用过多资源，还可以按照业务的优先级分配资源等。总之，使用SQL Server资源调节器可以更为细腻的分配服务器资源，是DBA的必杀技之一。
2015.1.8补充：
我在样例中使用的创建资源池的方法非常简单，其实，详细的语法如下：
CREATE RESOURCE POOL pool_name
[ WITH
(
[ MIN_CPU_PERCENT = value ]
[ [ , ] MAX_CPU_PERCENT = value ]
[ [ , ] CAP_CPU_PERCENT = value ]
[ [ , ] AFFINITY {SCHEDULER =
AUTO | ( <scheduler_range_spec> )
| NUMANODE = ( <NUMA_node_range_spec> )} ]
[ [ , ] MIN_MEMORY_PERCENT = value ]
[ [ , ] MAX_MEMORY_PERCENT = value ]
[ [ , ] MIN_IOPS_PER_VOLUME = value ]
[ [ , ] MAX_IOPS_PER_VOLUME = value ]
)
]
[;]