sys.dm_xtp_gc_queue_stats （Transact-SQL）
適用於：
SQL Server Azure SQL 資料庫 Azure SQL 受控執行個體
輸出伺服器上每個垃圾收集背景工作佇列的相關信息，以及每個佇列的各種統計數據。 每個邏輯 CPU 有一個佇列。
主要垃圾收集線程 （Idle thread） 會追蹤自上次叫用主要垃圾收集線程之後完成之所有交易的更新、刪除和插入數據列。 當垃圾收集線程喚醒時，它會判斷最舊作用中交易的時間戳是否已變更。 如果最舊的使用中交易已變更，則不再需要寫入集的交易，閑置線程會將工作專案加入佇列（以 16 個數據列的區塊為單位）。 例如，如果您刪除 1,024 個數據列，您最終會看到 64 個已排入佇列的垃圾收集工作專案，每個專案都包含 16 個已刪除的數據列。 在使用者交易認可之後，它會在其排程器上選取所有加入佇列的專案。 如果排程器上沒有加入佇列的專案，則使用者交易會在目前 NUMA 節點的任何佇列上搜尋。
您可以執行sys.dm_xtp_gc_queue_stats來判斷垃圾收集是否會釋放已刪除數據列的記憶體，以查看是否正在處理加入佇列的工作。 如果未處理current_queue_depth中的專案，或未將任何新的工作專案新增至current_queue_depth，表示垃圾收集不會釋放記憶體。 例如，如果有長時間執行的交易，就無法進行垃圾收集。
如需詳細資訊，請參閱 In-Memory OLTP (記憶體中最佳化)。
| 資料行名稱 | 類型 | 描述 |
|---|---|---|
| queue_id | int | 佇列的唯一標識碼。 |
| total_enqueues | bigint | 自伺服器啟動后加入佇列的垃圾收集工作項目總數。 |
| total_dequeues | bigint | 自伺服器啟動后，從這個佇列清除佇列的垃圾收集工作項目總數。 |
| current_queue_depth | bigint | 此佇列上目前存在的垃圾收集工作項目數目。 此專案可能暗示要進行一或多個垃圾收集。 |
| maximum_queue_depth | bigint | 此佇列所見的最大深度。 |
| last_service_ticks | bigint | 佇列上次服務時 CPU 刻度。 |
權限
需要 VIEW SERVER STATE 權限。
SQL Server 2022 和更新版本的權限
需要伺服器上的 VIEW SERVER PERFORMANCE STATE 權限。
使用者案例
此輸出顯示 SQL Server 是在 4 個核心上執行，或 SQL Server 實例已親和化為 4 個核心：
此輸出顯示佇列中沒有要處理的工作專案。 針對佇列 0，自 SQL 啟動為 15625 之後，已取消排入佇列的工作項目總數，且佇列深度上限為 15625。
queue_id total_enqueues total_dequeues current_queue_depth maximum_queue_depth last_service_ticks
----------------------------------------------------------------------------------------------------
0 15625 15625 0 15625 1233573168347
1 15625 15625 0 15625 1234123295566
2 15625 15625 0 15625 1233569418146
3 15625 15625 0 15625 1233571605761