由于Sort 和 Hash (Join 或 Aggregation) Operations需要缓存排序中间表和Hash Table，在执行计划真正运行之前，需要向系统申请一定数量的内存资源（Granted Memory)，如果SQL Server 不能 allocate 申请的内存，那么该执行计划将不会执行，处于RESOURCE_SEMAPHORE 等待。
Resource Semaphore: SQL Server uses a thread synchronization object called a semaphore to keep track of how much memory has been granted. The idea is this: if SQL Server runs out of workspace memory/QE memory, then instead of failing the query execution with an out-of-memory error, it will cause the query to wait for memory to become available. In this context, the Memory Grants Pending Perfmon counter makes sense. And so do wait_time_ms, granted_memory_kb = NULL, timeout_sec in sys.dm_exec_query_memory_grants. BTW, this and compile memory are the only places in SQL Server where a query will actually be made to wait for memory if it is not available; in all other cases, the query will fail outright with a 701 error – out of memory.
There is a Wait type in SQL Server that shows that a query is waiting for a memory grant – RESOURCE_SEMAPHORE. As the documentation states, this “occurs when a query memory request cannot be granted immediately due to other concurrent queries. High waits and wait times may indicate excessive number of concurrent queries, or excessive memory request amounts.” You will observe this wait type in sys.dm_exec_requests for individual sessions.
查看系统内存使用信息
1，在OS级别上，查看SQL Server 能够使用和已经消耗的内存资源
sys.dm_os_sys_info Returns the resources available to and consumed by SQL Server.
cpu_count:Specifies the number of logical CPUs on the system
physical_memory_kb:Specifies the total amount of physical memory on the machine
committed_kb:Represents the committed memory in the memory manager. Does not include reserved memory in the memory manager.
committed_target_kb:Represents the amount of memory that can be consumed by SQL Server memory manager.
If committed_target_kb is larger than committed_kb, the memory manager will try to obtain additional memory. If committed_target_kb is smaller than committed_kb, the memory manager will try to shrink the amount of memory committed. The committed_target_kb always includes stolen and reserved memory.
select cpu_count,
physical_memory_kb,
--virtual_memory_kb,
committed_kb,
committed_target_kb
from sys.dm_os_sys_info
2，使用memory clerk查看内存消耗
在SQL Server中，只有Memory Clerk能够分配内存，Memory Clerk会记录已经分配内存的数量，任何一个需要使用内存的对象，必须创建自己的Memory Clerk，并使用该Memory clerk来分配内存。SQL Server 使用 ‘MEMORYCLERK_SQLQERESERVATIONS’ 来分配执行sort/hash operations 所需要的内存，使用 sys.dm_os_memory_clerks 来查看系统中 sort/hash operations 的总内存分配量。
pages_kb:Specifies the amount of page memory allocated in kilobytes (KB) for this memory clerk.
select type,
pages_kb,
virtual_memory_reserved_kb,
virtual_memory_committed_kb,
shared_memory_reserved_kb,
shared_memory_committed_kb,
page_size_in_bytes
from sys.dm_os_memory_clerks
where type = ‘MEMORYCLERK_SQLQERESERVATIONS‘
and memory_node_id<>64
memory_node_id=64 只在DAC中使用，不是Physical Memory Node，是为了支持DAC而设计的一个Logical Memory Node。
In order to support the Dedicated Admin Connection it is given a logical node with a bit of dedicated memory. The node is not associated with any physical NUMA node or CPU and it is given the memory_node_id of 64.
3，查看等待Granted Memory的query
sys.dm_exec_query_memory_grants
requested_memory_kb：Total requested amount of memory in kilobytes.
granted_memory_kb：Total amount of memory actually granted in kilobytes. Can be NULL if the memory is not granted yet. For a typical situation, this value should be the same as requested_memory_kb. For index creation, the server may allow additional on-demand memory beyond initially granted memory.
required_memory_kb：Minimum memory required to run this query in kilobytes. requested_memory_kb is the same or larger than this amount.
used_memory_kb：Physical memory used at this moment in kilobytes.
max_used_memory_kb：Maximum physical memory used up to this moment in kilobytes.
ideal_memory_kb:Size of the memory grant to fit everything into physical memory. This is based on the cardinality estimate.
select qmg.session_id,
qmg.dop,
qmg.requested_memory_kb,
qmg.granted_memory_kb,
qmg.required_memory_kb,
qmg.used_memory_kb,
qmg.max_used_memory_kb,
qmg.ideal_memory_kb,
qmg.request_time,
qmg.grant_time,
qmg.wait_time_ms,
qmg.pool_id,
qmg.resource_semaphore_id,
st.text,
qp.query_plan
from sys.dm_exec_query_memory_grants qmg
OUTER APPLY sys.dm_exec_sql_text(qmg.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(qmg.plan_handle) as qp
在Query编译时，SQL Server会 Estimate 内存的使用量（ideal_memory_kb），在查询语句执行时，需要向SQL Server 申请内存（requested_memory_kb），SQL Server 根据系统内存的使用情况，分配物理内存（granted_memory_kb）给该查询语句。
4，在 sys.dm_exec_requests 存在 granted_query_memory ，用于表示：Number of pages allocated to the execution of a query on the request
5，查看SQL Server 对Granted Memory的授予统计信息
sys.dm_exec_query_resource_semaphores provides general query-execution memory status and allows you to determine whether the system can access enough memory.
Appendix
引用《Memory Meditation: The mysterious SQL Server memory consumer with Many Names》
Have you ever wondered what Memory grants are? What about QE Reservations? And Query Execution Memory? Workspace memory? How about Memory Reservations?
As with most things in life, complex concepts often reduces to a simple one: all these names refer to the same memory consumer in SQL Server: memory allocated during query execution for Sort and Hash operations (bulk copy and index creation fit into the same category but a lot less common).
Allow me to provide some larger context: during its lifetime a query may request memory from different “buckets” or clerks, depending on what it needs to do. For example, when a query is parsed and compiled initially, it will consume compile or optimizer memory. Once the query is compiled that memory is released and the resulting query plan needs to be stored in cache. For that, the plan will consume procedure cache memory and will stay in that cache until server is restarted or memory pressure occurs. At that point, the query is ready for execution. If the query happens to be doing any sort operations or hash match(join or aggregates), then it will first reserve and later use part or all of the reserved memory to store sorted results or hash buckets. These memory operations during the execution of a query are what all these many names refer to.
Query Execution (QE) Reservations or Memory Reservations: When a query needs memory for sort/hash operations, during execution it will make a reservation request based on the original query plan which contained a sort or a hash operator. Then as the query executes, it requests the memory and SQL Server will grant that request partially or fully depending on memory availability. There is a memory clerk (accountant) named ‘MEMORYCLERK_SQLQERESERVATIONS’ that keep track of these memory allocations (check out DBCC MEMORYSTATUS or sys.dm_os_memory_clerks).
Memory Grants: When SQL Server grants the requested memory to an executing query it is said that a memory grant has occurred. There is a Perfmon counter that keep track of how many queries have been granted the requested memory: Memory Grants Outstanding. Another counter shows how many queries have requested sort/hash memory but have to wait for it because the Query Execution memory has run out (QE Reservation memory clerk has given all of it away): Memory Grants Pending. These two only display the count of memory grants and do not account for size. That is, one query alone could have consumed say 4 GB of memory to perform a sort, but that will not be reflected in either of these.
To view individual requests and the memory size they have requested and been granted you can query the sys.dm_exec_query_memory_grants DMV. This shows information about currently executing queries, not historically.
引用《The DMV sys.dm_os_memory_clerks May Show What Appears To Be Duplicate Entries》
Notice that the clerk addresses are different so they really do belong to different NUMA nodes. The difference is the exposure of the logical memory node id for the DAC node (64).
In order to support the Dedicated Admin Connection it is given a logical node with a bit of dedicated memory. The node is not associated with any physical NUMA node or CPU and it is given the memory_node_id of 64.
To understand this a bit better you have to understand how SQL considers memory nodes. At the SQLOS level a memory node it represented by the physical layout of CPUs to Memory as presented by the operating system. When looking at SQLOS level DMVs the memory nodes often represent this physical alignment. Since DAC is a logical implementation it is just assigned a node id by SQLOS. In SQL 2008 some of the DMVs did not account for DAC and would output the physical memory node association, making it look like you have duplicate clerks on the same node.
There may also be ways you can see what appears to be duplicates in SQL 2008 R2 if you are using SOFT NUMA. Under SOFT NUMA you can split a physical NUMA node into logical NUMA nodes at the scheduling level for SQL Server. However, at the SQLOS memory node level it still works with the physical memory layout presented by the operating system. This allows SQLOS to provide facilities such as node local memory access to one or more logical nodes that may have been configured with SOFT NUMA.
参考doc:
Memory Meditation: The mysterious SQL Server memory consumer with Many Names
The DMV sys.dm_os_memory_clerks May Show What Appears To Be Duplicate Entries
sys.dm_os_sys_info (Transact-SQL)
sys.dm_os_memory_clerks (Transact-SQL)
sys.dm_exec_query_memory_grants (Transact-SQL)
sys.dm_exec_query_resource_semaphores (Transact-SQL)