Se Tempdb diventa un problema

A volte accade un po’ l’imprevisto. Per esempio oggi un bel job notturno che funziona da almeno tre anni senza mai segnalare un problema è fallito.

Il problema? Tendenzialmente quello che più o meno sempre è “il problema”: lo spazio disco.

Nello specifico il tempdb è andato oltre i 140GB che è lo spazio a lui assegnato; 140GB sono una bella botta di spazio, anche se parliamo di un processo notturno di datawarehousing, così è naturale chiedersi “ma chi mangia così tanto spazio”?

Questa è la select che può sicuramente aiutare:


WITH task_space_usage AS (
SELECT session_id,
request_id,
SUM(internal_objects_alloc_page_count) AS alloc_pages,
SUM(internal_objects_dealloc_page_count) AS dealloc_pages
FROM sys.dm_db_task_space_usage WITH (NOLOCK)
WHERE session_id <> @@SPID
GROUP BY session_id, request_id
)
SELECT TSU.session_id,
TSU.alloc_pages * 1.0 / 128 AS [internal object MB space],
TSU.dealloc_pages * 1.0 / 128 AS [internal object dealloc MB space],
EST.text,
ISNULL(
NULLIF(
SUBSTRING(
EST.text,
ERQ.statement_start_offset / 2,
CASE WHEN ERQ.statement_end_offset < ERQ.statement_start_offset
THEN 0
ELSE( ERQ.statement_end_offset - ERQ.statement_start_offset ) / 2 END
), ''
), EST.text
) AS [statement text],
EQP.query_plan
FROM task_space_usage AS TSU
INNER JOIN sys.dm_exec_requests ERQ WITH (NOLOCK)
ON TSU.session_id = ERQ.session_id
AND TSU.request_id = ERQ.request_id
OUTER APPLY sys.dm_exec_sql_text(ERQ.sql_handle) AS EST
OUTER APPLY sys.dm_exec_query_plan(ERQ.plan_handle) AS EQP
WHERE EST.text IS NOT NULL OR EQP.query_plan IS NOT NULL
ORDER BY 3 DESC;