Da http://www.sqlservercentral.com/scripts/tempdb/72007/
;WITH task_space_usage AS (
-- SUM alloc/delloc pages
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,
-- Extract statement from sql 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;
MODIFICARE
Come ha sottolineato Martin in un commento, questo non troverà transazioni attive che occupano spazio in tempdb, ma troverà solo query attive che attualmente stanno utilizzando lo spazio (e probabilmente i colpevoli per l'utilizzo del registro corrente). Quindi potrebbe esserci una transazione aperta ma la query effettiva che causa il problema non è più in esecuzione.
È possibile modificare l' inner joinon sys.dm_exec_requestsin a left outer join, quindi si restituiranno le righe per le sessioni che non eseguono attualmente query attive.
La query Martin ha pubblicato ...
SELECT database_transaction_log_bytes_reserved,session_id
FROM sys.dm_tran_database_transactions AS tdt
INNER JOIN sys.dm_tran_session_transactions AS tst
ON tdt.transaction_id = tst.transaction_id
WHERE database_id = 2;
... identificherebbe le session_idtransazioni attive che occupano spazio nel registro, ma non sarebbe necessariamente in grado di determinare la query effettiva che ha causato il problema, poiché se non è in esecuzione ora non verrà acquisita nella query precedente per richieste attive. Potresti essere in grado di controllare in modo reattivo la query più recente utilizzando DBCC INPUTBUFFERma potrebbe non dirti cosa vuoi ascoltare. Puoi unire all'esterno in modo simile per catturare quelli attivi, ad esempio:
SELECT tdt.database_transaction_log_bytes_reserved,tst.session_id,
t.[text], [statement] = COALESCE(NULLIF(
SUBSTRING(
t.[text],
r.statement_start_offset / 2,
CASE WHEN r.statement_end_offset < r.statement_start_offset
THEN 0
ELSE( r.statement_end_offset - r.statement_start_offset ) / 2 END
), ''
), t.[text])
FROM sys.dm_tran_database_transactions AS tdt
INNER JOIN sys.dm_tran_session_transactions AS tst
ON tdt.transaction_id = tst.transaction_id
LEFT OUTER JOIN sys.dm_exec_requests AS r
ON tst.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(r.plan_handle) AS t
WHERE tdt.database_id = 2;
È inoltre possibile utilizzare DMV sys.dm_db_session_space_usageper visualizzare l'utilizzo dello spazio complessivo per sessione (ma potrebbe non essere possibile ottenere risultati validi per la query; se la query non è attiva, ciò che si ottiene potrebbe non essere il vero colpevole).
;WITH s AS
(
SELECT
s.session_id,
[pages] = SUM(s.user_objects_alloc_page_count
+ s.internal_objects_alloc_page_count)
FROM sys.dm_db_session_space_usage AS s
GROUP BY s.session_id
HAVING SUM(s.user_objects_alloc_page_count
+ s.internal_objects_alloc_page_count) > 0
)
SELECT s.session_id, s.[pages], t.[text],
[statement] = COALESCE(NULLIF(
SUBSTRING(
t.[text],
r.statement_start_offset / 2,
CASE WHEN r.statement_end_offset < r.statement_start_offset
THEN 0
ELSE( r.statement_end_offset - r.statement_start_offset ) / 2 END
), ''
), t.[text])
FROM s
LEFT OUTER JOIN
sys.dm_exec_requests AS r
ON s.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(r.plan_handle) AS t
ORDER BY s.[pages] DESC;
Con tutte queste domande a tua disposizione, dovresti essere in grado di restringere chi sta usando tempdb e come, specialmente se le prendi nell'atto.
alcuni suggerimenti per ridurre al minimo l'utilizzo di tempdb
- usa meno tabelle #temp e variabili @table
- minimizzare la manutenzione simultanea dell'indice ed evitare l'
SORT_IN_TEMPDBopzione se non è necessaria
- evitare cursori inutili; evitare i cursori statici se si ritiene che questo possa essere un collo di bottiglia, poiché i cursori statici utilizzano le tabelle di lavoro in tempdb - sebbene questo sia il tipo di cursore che consiglio sempre se tempdb non è un collo di bottiglia
- cerca di evitare gli spool (es. CTE di grandi dimensioni a cui si fa riferimento più volte nella query)
- non usare MARTE
- testare accuratamente l'uso dei livelli di isolamento snapshot / RCSI - non accenderlo per tutti i database poiché ti è stato detto che è meglio di NOLOCK (lo è, ma non è gratuito)
- in alcuni casi, potrebbe sembrare poco intuitivo, ma utilizzare più tabelle temporanee. es. suddividere una gigantesca query in parti può essere leggermente meno efficiente, ma se può evitare un enorme sversamento di memoria in tempdb perché la singola query più grande richiede una concessione di memoria troppo grande ...
- evitare di abilitare i trigger per operazioni in blocco
- evitare l'uso eccessivo di tipi LOB (tipi massimi, XML, ecc.) come variabili locali
- mantenere le transazioni brevi e dolci
- non impostare tempdb come database predefinito di tutti -
È inoltre possibile considerare che l'utilizzo del registro tempdb potrebbe essere causato da processi interni su cui si ha un controllo scarso o nullo, ad esempio posta elettronica del database, notifiche di eventi, notifiche di query e broker di servizi utilizzano tutti in qualche modo tempdb. Puoi smettere di usare queste funzionalità, ma se le stai usando non puoi dettare come e quando usano tempdb.
