ALTER WORKLOAD GROUP （Transact-SQL）

选择产品

在下一行中，选择感兴趣的产品名称，仅显示该产品的信息。

* SQL Server *  

SQL 托管实例

Azure Synapse
数据

 

SQL Server 和 SQL 托管实例

更改现有的资源调控器工作负荷组配置，并选择性地将其分配给其他资源调控器资源池。

注意

若要修改 Azure SQL 托管实例中的资源调控器配置，必须在主副本的 master 数据库上下文中。

Transact-SQL 语法约定。

语法

ALTER WORKLOAD GROUP { group_name | [ default ] }
[ WITH
    ( [ IMPORTANCE = { LOW | MEDIUM | HIGH } ]
      [ [ , ] REQUEST_MAX_MEMORY_GRANT_PERCENT = value ]
      [ [ , ] REQUEST_MAX_CPU_TIME_SEC = value ]
      [ [ , ] REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value ]
      [ [ , ] MAX_DOP = value ]
      [ [ , ] GROUP_MAX_REQUESTS = value ]
      [ [ , ] GROUP_MAX_TEMPDB_DATA_MB = value ]
      [ [ , ] GROUP_MAX_TEMPDB_DATA_PERCENT = value ] )
]
[ USING { pool_name | [default] } ]
[ ; ]

参数

group_name |[default]

现有用户定义的工作负荷组或资源调控器内置 default 工作负荷组的名称。

当与 default 一起使用时，[] 必须位于括号（""）或引号（ALTER WORKLOAD GROUP），以避免与系统保留字 DEFAULT冲突。 有关详细信息，请参阅 数据库标识符。

内置资源池和工作负荷组使用所有小写名称，例如 default。 在使用区分大小写的排序规则的服务器上使用小写 default。 不区分大小写的排序规则的服务器将 default、Default和 DEFAULT 视为相同的值。

IMPORTANCE = { LOW |MEDIUM |HIGH }

指定工作负荷组中请求的相对重要性。 默认值为 MEDIUM。

IMPORTANCE 是包含工作负荷组的资源池的本地。 同一资源池内具有不同重要性的工作负荷组相互影响，但不会影响其他资源池中的工作负荷组。

REQUEST_MAX_MEMORY_GRANT_PERCENT = 值

指定单个请求可从池获取的最大查询工作区内存量。 值 是 MAX_MEMORY_PERCENT定义的资源池大小的百分比。 默认值为 25。

在 SQL Server 2017（14.x）及更早版本中，值 为整数，允许的范围从 1 到 100。

从 SQL Server 2019 （15.x）开始，该值可以使用 float 数据类型的小数部分。 允许的范围从 0 到 100。

重要

指定的金额仅指通过查询内存授予获得的查询工作区内存。

不建议设置 值 过大（例如大于 70），因为服务器可能无法为其他并发查询留出足够的可用内存。 这可能会导致内存授予超时 错误 8645。

将 值 设置为 0 或小值可能会阻止使用需要工作区内存（如 sort 和 hash）的运算符的查询在用户定义的工作负荷组中运行。 如果查询内存要求超出此参数定义的限制，则会发生以下行为：

• 对于用户定义的工作负荷组，服务器会尝试减少请求（DOP）的并行度（查询），直到内存要求低于限制，或直到 DOP 等于 1。 如果查询内存要求仍大于限制，则会发生错误 8657，并且查询失败。
• 对于 internal 和 default 工作负荷组，服务器允许查询获取所需的内存。

在任一情况下，如果服务器的物理内存不足，则可能会出现 错误 8645。

REQUEST_MAX_CPU_TIME_SEC = 值

指定批处理请求可以使用的最大 CPU 时间（以秒为单位）。 值 必须为 0 或正整数。 值 的默认设置为 0，这意味着无限制。

超过最大 CPU 时间时，将生成 cpu_threshold_exceeded 扩展事件和跟踪事件。 有关详细信息，请参阅 CPU 阈值超出事件类。

在 Azure SQL 托管实例中，超过最大 CPU 时间时，资源调控器会中止请求并出现错误 10961。

在 SQL Server 中，资源调控器默认不会中止请求。 但是，从 SQL Server 2016 （13.x） SP2 和 SQL Server 2017 （14.x） CU3 开始，资源调控器会在启用跟踪标志 2422 时中止错误 10961 的请求，并超出最大 CPU 时间。

REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 值

指定查询可以等待查询工作区内存中的内存授予可用的最大时间（以秒为单位）。 值 必须为 0 或正整数。 值0 的默认设置使用基于查询成本的内部计算来确定最长时间。

达到内存授予超时时，查询并不总是失败。 仅当运行过多并发查询时，查询才会失败。 否则，查询可能只获得最小内存授予，从而导致查询性能降低。

MAX_DOP = 值

指定并行查询执行的最大并行度（MAXDOP）。 值的允许范围为 0 到 64。 值0 的默认设置使用全局设置。

有关详细信息，请参阅 MAXDOP。

GROUP_MAX_REQUESTS = 值

指定允许在工作负荷组中执行的最大同时请求数。 值 必须为 0 或正整数。 值 的默认设置为 0，并允许无限制的请求。 达到最大并发请求时，可以创建该组中的会话，但会处于等待状态，直到并发请求数低于指定的值。

GROUP_MAX_TEMPDB_DATA_MB = 值

指定工作负荷组在数据文件中 tempdb 可以使用的最大空间量（以兆字节为单位）。 值 必须为0、正数或NULL。 允许小数部分值。

如果值为 0， tempdb 则不允许工作负荷组中的会话分配空间。 如果未设置值，资源调控器不会限制 tempdb 工作负荷组的空间消耗。

此限制适用于工作负荷组中所有会话占用 tempdb 的总空间。

当在工作负荷组中运行的请求尝试增加 tempdb 工作负荷组超出所设置 GROUP_MAX_TEMPDB_DATA_MB的限制的数据空间消耗时，资源调控器会中止请求并显示错误 1138。 有关详细信息，请参阅 Tempdb 空间资源治理。

GROUP_MAX_TEMPDB_DATA_PERCENT = 值

指定工作负荷组在数据文件中 tempdb 可以使用的最大空间量（以最大 tempdb 大小百分比为单位）。 有关最大 tempdb 大小的定义，请参阅 百分比限制配置。 值 必须在0到100之间，或者为NULL。 允许小数部分值。

如果值为 0， tempdb 则不允许工作负荷组中的会话分配空间。 如果未设置值，资源调控器不会限制 tempdb 工作负荷组的空间消耗。 设置时间 GROUP_MAX_TEMPDB_DATA_MB 或未定义最大大小时 tempdb ， GROUP_MAX_TEMPDB_DATA_PERCENT 不起作用。

此限制适用于工作负荷组中所有会话占用 tempdb 的总空间。

当在工作负荷组中运行的请求尝试增加 tempdb 工作负荷组超出所设置 GROUP_MAX_TEMPDB_DATA_PERCENT的限制的数据空间消耗时，资源调控器会中止请求并显示错误 1138。 有关详细信息，请参阅 Tempdb 空间资源治理。

USING { pool_name |[ default ] }

将工作负荷组与由 pool_name标识的用户定义资源池或 default 资源池相关联。 如果未提供 pool_name，或者未指定 USING 参数，则工作负荷组与内置 default 池相关联。

default 是保留字，在 USING中指定时，必须用括号（[]）或引号（""）括起来。

内置资源池和工作负荷组使用所有小写名称，例如 default。 在使用区分大小写的排序规则的服务器上使用小写 default。 不区分大小写的排序规则的服务器将 default、Default和 DEFAULT 视为相同的值。

言论

ALTER WORKLOAD GROUP 允许在 default 工作负荷组中，但不允许在 internal 组中使用。

在执行 ALTER RESOURCE GOVERNOR RECONFIGURE 之后，对工作负荷组配置的更改才会生效。

有关详细信息，请参阅 资源调控器 和 资源调控器工作负荷组。

MAXDOP

对于给定的查询，将按如下所示确定有效的 MAXDOP：

• 只要查询提示不超过工作负荷组 MAXDOP 设置，就 MAX_DOP 作为查询提示。
• MAXDOP 作为查询提示始终替代 max degree of parallelism 服务器配置。 有关详细信息，请参阅 服务器配置：最大并行度。
• 工作负荷组 MAX_DOP 替代 max degree of parallelism 服务器配置和 MAXDOP数据库范围的配置。

每个 MAXDOP设置 限制。 它不是每个 请求 或每个查询限制。 在执行并行查询期间，单个请求可以生成分配给 计划程序的多个任务。 有关详细信息，请参阅 线程和任务体系结构指南。

当查询在编译时（MAXDOP = 1）标记为串行时，无论工作负荷组或服务器配置设置如何，它都不能在运行时以并行方式执行。 为查询确定 MAXDOP 后，由于内存压力，只能降低该查询。 工作负荷组重新配置不会影响在内存授予队列中等待的查询。

缓存的计划

更改影响 MAX_DOP等设置的计划时，新设置仅在执行 DBCC FREEPROCCACHE (<pool_name>)后才会在以前缓存的计划中生效，其中 <pool_name> 是当前工作负荷组使用的资源调控器资源池的名称。

• 如果将 MAX_DOP 更改为 1，则不需要执行 DBCC FREEPROCCACHE，因为并行计划可以在串行模式下运行。 但是，此类计划的效率可能低于编译为串行计划的计划。
• 如果将 MAX_DOP 从 1 更改为 0 或值大于 1，则不需要执行 DBCC FREEPROCCACHE。 但是，串行计划无法并行运行，因此清除相应的缓存允许使用并行度编译新计划。

警告

从与多个工作负荷组关联的资源池中清除缓存的计划会影响使用由 <pool_name>标识的用户定义资源池的所有工作负荷组。

索引创建

出于性能原因，允许索引创建使用比最初授予的更多内存工作区。 资源调控器支持这种特殊处理。 但是，初始授予和任何其他内存授予受工作负荷组和资源池设置的限制。

在分区表上创建非对齐索引所消耗的内存与所涉及的分区数成正比。 如果所需内存总量超过 REQUEST_MAX_MEMORY_GRANT_PERCENT 工作负荷组设置强制实施的每个查询限制，则创建索引可能会失败。 由于 default 工作负荷组允许查询超出每个查询的限制，且所需的最小内存才能开始向后兼容，因此，如果 default 资源池有足够的总内存，则可以使用 default 工作负荷组创建相同的索引。

权限

需要 CONTROL SERVER 权限。

例子

以下示例演示如何将默认组中请求的重要性从 MEDIUM 更改为 LOW。

ALTER WORKLOAD GROUP [default]
WITH (IMPORTANCE = LOW);

ALTER RESOURCE GOVERNOR RECONFIGURE;

以下示例演示如何将工作负荷组从当前已进入 default 池的池中移动。

ALTER WORKLOAD GROUP adHoc
USING [default];

ALTER RESOURCE GOVERNOR RECONFIGURE;

相关内容

• 资源调控器
• 资源调控器工作负荷组
• 创建工作负荷组
• 移动工作负荷组
• CREATE WORKLOAD GROUP （Transact-SQL）
• DROP WORKLOAD GROUP （Transact-SQL）
• CREATE RESOURCE POOL （Transact-SQL）
• ALTER RESOURCE POOL （Transact-SQL）
• DROP RESOURCE POOL （Transact-SQL）
• ALTER RESOURCE GOVERNOR （Transact-SQL）
• sys.resource_governor_workload_groups资源管理器工作负载组
• sys.dm_resource_governor_workload_groups