sys.dm_exec_query_memory_grants (Transact-SQL)

適用対象: はいSQL Server (サポートされているすべてのバージョン) はいAzure SQL データベース はいAzure Synapse Analytics はいParallel Data Warehouse

要求され、メモリ許可を待機している、またはメモリ許可が与えられたすべてのクエリに関する情報を返します。 メモリ許可を必要としないクエリは、このビューには表示されません。 たとえば、並べ替え操作とハッシュ結合操作にはクエリ実行用のメモリ許可があります。一方、 句のないクエリにはメモリ許可 ORDER BY は与えされません。

Azure SQL データベース では、動的管理ビューは、データベースの包含に影響する情報を公開することも、ユーザーがアクセスできる他のデータベースに関する情報を公開することもできません。 この情報が公開されるのを避けるために、接続されているテナントに属していないデータを含むすべての行がフィルター処理されます。さらに、列 、 の値はフィルター処理され、列の値 scheduler_id wait_order は NULL pool_id group_id に設定されます。

注意

または からこれを呼び出 Azure Synapse Analytics す Analytics Platform System (PDW) 場合は、 という名前を使用します sys.dm_pdw_nodes_exec_query_memory_grants 。 この構文は、Azure Synapse Analytics のサーバーレス SQL プールでサポートされていません。

列名 データの種類 説明
session_id smallint このクエリを実行中のセッションの ID (SPID)。
request_id int 要求の ID。 セッションのコンテキスト内で一意です。
scheduler_id int このクエリのスケジュールを設定しているスケジューラの ID。
Dop smallint このクエリの並行処理の程度。
request_time datetime このクエリがメモリ許可を要求した日付と時刻。
grant_time datetime このクエリにメモリが許可された日付と時刻。 メモリがまだ許可されていない場合は NULL です。
requested_memory_kb bigint メモリの要求量の合計 (KB 単位)。
granted_memory_kb bigint 実際に許可されたメモリの総量 (KB 単位)。 メモリがまだ許可されていない場合、NULL になることがあります。 一般的な状況では、この値は と同じになります requested_memory_kb 。 インデックス作成では、最初に許可されたメモリ量を超えて、追加のオンデマンド メモリが許可される場合があります。
required_memory_kb bigint このクエリを実行するために必要な最小メモリ (KB 単位)。 requested_memory_kb は、この量と同じかそれより大きい値です。
used_memory_kb bigint この時点で使用されている物理メモリ (KB 単位)。
max_used_memory_kb bigint この時点までに使用された最大物理メモリ (KB 単位)。
query_cost float 推定クエリ コスト。
timeout_sec int このクエリがメモリ許可要求をやめるまでのタイムアウト (秒単位)。
resource_semaphore_id smallint このクエリが待機しているリソース セマフォの非一意の ID。

注: この ID は、 より前の バージョン SQL Server の で一意です SQL Server 2008 。 この変更は、クエリの実行のトラブルシューティングに影響する可能性があります。 詳細については、この記事の後半の「解説」セクションを参照してください。
queue_id smallint このクエリがメモリ許可を待機している待機キューの ID。 メモリが既に許可されている場合は NULL です。
wait_order int 指定した 内の待機中のクエリの順番 queue_id 。 この値は、他のクエリがメモリ許可またはタイム アウトを取得した場合に、特定のクエリに対して変更される可能性があります。メモリが既に許可されている場合は NULL。
is_next_candidate bit 次のメモリ許可の候補。

1 = はい

0 = いいえ

NULL = メモリが既に許可されている
wait_time_ms bigint 待機時間 (ミリ秒単位)。 メモリが既に許可されている場合は NULL です。
plan_handle varbinary(64) このクエリ プランの識別子。 を sys.dm_exec_query_plan 使用して、実際の XML プランを抽出します。
sql_handle varbinary(64) このクエリの Transact-SQL テキストの識別子。 を sys.dm_exec_sql_text 使用して、実際のテキストを Transact-SQL 取得します。
group_id int このクエリが実行されているワークロード グループの ID。
pool_id int このワークロード グループが属するリソース プールの ID。
is_small tinyint 1 に設定すると、この許可で小さなリソース セマフォが使用されます。 0 に設定すると、通常のセマフォが使用されます。
ideal_memory_kb bigint 物理メモリ内にすべてを収めるために必要なメモリ許可のサイズ (KB 単位)。 これはカーディナリティの推定値に基づいています。
pdw_node_id int このディストリビューションが配置されているノードの識別子。

適用対象: Azure Synapse Analytics 、 Analytics Platform System (PDW)
reserved_worker_count bigint 予約済み ワーカースレッドの数。

適用対象:SQL Server (開始値 SQL Server 2016 (13.x)) および Azure SQL データベース
used_worker_count bigint 現時点で使用されている ワーカースレッド の数。

適用対象:SQL Server (開始値 SQL Server 2016 (13.x)) および Azure SQL データベース
max_used_worker_count bigint この時点までに使用された ワーカースレッド の最大数。

適用対象:SQL Server (開始値 SQL Server 2016 (13.x)) および Azure SQL データベース
reserved_node_bitmap bigint ワーカースレッドが予約されている NUMA ノードのビットマップ。

適用対象:SQL Server (開始値 SQL Server 2016 (13.x)) および Azure SQL データベース

アクセス許可

で SQL Server は、 VIEW SERVER STATE 権限が必要です。
Azure SQL データベース 上では、データベース内の VIEW DATABASE STATE アクセス許可が必要です。

注釈

または集計を含む動的管理ビューを使用するクエリで ORDER BY は、メモリ使用量が増加し、トラブルシューティングの問題に寄与する場合があります。

データベース管理者は、リソース ガバナー機能を使用することで、サーバー リソースを最大 64 個までのリソース プールに分散できます。 以降 SQL Server 2008 では、各プールは小規模の独立したサーバーインスタンスのように動作し、2つのセマフォが必要です。 から返される行の数は、 sys.dm_exec_query_resource_semaphores で返された行より最大で20倍になることがあり SQL Server 2005 (9.x) ます。

クエリタイムアウトの一般的なデバッグシナリオでは、次のことを調べることができます。

  • sys.dm_os_memory_clerkssys.dm_os_sys_info、およびさまざまなパフォーマンス カウンターを使用して、全体的なシステム メモリ状態を調べます。

  • クエリ実行のメモリ予約の場所を sys.dm_os_memory_clerks 確認 type = 'MEMORYCLERK_SQLQERESERVATIONS' します。

  • 次を使用して1 件 の許可を待機しているクエリを確認する sys.dm_exec_query_memory_grants :

    --Find all queries waiting in the memory queue  
    SELECT * FROM sys.dm_exec_query_memory_grants WHERE grant_time IS NULL;
    

    1 このシナリオの場合、待機の種類は一般的に RESOURCE_SEMAPHORE になります。 詳細については、「sys.dm_os_wait_stats (Transact-SQL)」を参照してください。

  • sys.dm_exec_cached_plans (transact-sql SQLを使用したメモリ許可を持つクエリのキャッシュの検索)およびsys.dm_exec_query_plan (transact-sql SQL

    -- retrieve every query plan from the plan cache  
    USE master;  
    GO  
    SELECT * FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle);  
    GO  
    
  • ランナウェイクエリの疑いがある場合は、sys.dm_exec_query_plan から列のプラン表示を調べ、 query_plan sys.dm_exec_sql_text からバッチをクエリし text ます。 Sys.dm_exec_requestsを使用して、現在実行中のメモリ集中型のクエリをさらに確認します。

    --Active requests with memory grants
    SELECT
    --Session data 
      s.[session_id], s.open_transaction_count
    --Memory usage
    , r.granted_query_memory, mg.grant_time, mg.requested_memory_kb, mg.granted_memory_kb, mg.required_memory_kb, mg.used_memory_kb, mg.max_used_memory_kb     
    --Query 
    , query_text = t.text, input_buffer = ib.event_info, query_plan_xml = qp.query_plan, request_row_count = r.row_count, session_row_count = s.row_count
    --Session history and status
    , s.last_request_start_time, s.last_request_end_time, s.reads, s.writes, s.logical_reads, session_status = s.[status], request_status = r.status
    --Session connection information
    , s.host_name, s.program_name, s.login_name, s.client_interface_name, s.is_user_process
    FROM sys.dm_exec_sessions s 
    LEFT OUTER JOIN sys.dm_exec_requests AS r 
        ON r.[session_id] = s.[session_id]
    LEFT OUTER JOIN sys.dm_exec_query_memory_grants AS mg 
        ON mg.[session_id] = s.[session_id]
    OUTER APPLY sys.dm_exec_sql_text (r.[sql_handle]) AS t
    OUTER APPLY sys.dm_exec_input_buffer(s.[session_id], NULL) AS ib 
    OUTER APPLY sys.dm_exec_query_plan (r.[plan_handle]) AS qp 
    WHERE mg.granted_memory_kb > 0
    ORDER BY mg.granted_memory_kb desc, mg.requested_memory_kb desc;
    GO
    

関連項目