Диагностика конкуренции и использования места в tempdb

Команда

-- 1) Current tempdb page latch waits (2:1:1 PFS, 2:1:2 GAM, 2:1:3 SGAM):
SELECT wt.session_id, wt.wait_type, wt.wait_duration_ms, wt.resource_description
FROM   sys.dm_os_waiting_tasks wt
WHERE  wt.wait_type LIKE N'PAGELATCH[_]%'
  AND  wt.resource_description LIKE N'2:%';

-- 2) Sessions using the most tempdb (MB):
SELECT TOP (20) su.session_id, s.login_name, s.program_name,
       (su.user_objects_alloc_page_count - su.user_objects_dealloc_page_count) * 8 / 1024         AS user_obj_mb,
       (su.internal_objects_alloc_page_count - su.internal_objects_dealloc_page_count) * 8 / 1024 AS internal_obj_mb
FROM   sys.dm_db_session_space_usage su
  JOIN sys.dm_exec_sessions s ON s.session_id = su.session_id
WHERE  s.is_user_process = 1
ORDER BY su.user_objects_alloc_page_count + su.internal_objects_alloc_page_count
       - su.user_objects_dealloc_page_count - su.internal_objects_dealloc_page_count DESC;

-- 3) Overall breakdown and version store:
SELECT SUM(unallocated_extent_page_count) * 8 / 1024       AS free_mb,
       SUM(user_object_reserved_page_count) * 8 / 1024     AS user_obj_mb,
       SUM(internal_object_reserved_page_count) * 8 / 1024 AS internal_obj_mb,
       SUM(version_store_reserved_page_count) * 8 / 1024   AS version_store_mb
FROM   tempdb.sys.dm_db_file_space_usage;

SELECT DB_NAME(database_id) AS db, reserved_page_count * 8 / 1024 AS version_store_mb
FROM   sys.dm_tran_version_store_space_usage
ORDER BY reserved_page_count DESC;

-- 4) File count / equal sizing and memory-optimized metadata:
SELECT name, type_desc, size * 8 / 1024 AS size_mb, growth * 8 / 1024 AS growth_mb, is_percent_growth
FROM   tempdb.sys.database_files;
SELECT SERVERPROPERTY('IsTempdbMetadataMemoryOptimized') AS tempdb_metadata_memopt;

Что делает

Показывает ожидания PAGELATCH на страницах выделения tempdb (PFS/GAM/SGAM) и системных таблицах, сессии, больше всего использующие tempdb (временные таблицы vs. сбросы sort/hash), какая база раздувает хранилище версий, и конфигурацию файлов.

Когда использовать

Когда растут ожидания PAGELATCH_UP/EX при интенсивной работе с временными таблицами, tempdb заполняется (1105/9002) или растёт хранилище версий.

Внимание

Страницы 2:1:1, 2:1:2, 2:1:3 и страницы PFS с номерами, кратными 8088, означают конкуренцию за выделение: решение — несколько файлов данных одинакового размера с одинаковым ростом (по одному на ядро до 8, затем добавлять по 4). При конкуренции на страницах системных таблиц в 2019+ есть memory-optimized метаданные tempdb (требуется перезапуск). Если растёт хранилище версий, найдите самую старую открытую snapshot-транзакцию; сжатие tempdb — не решение. Запрос только на чтение; безопасно.