Em 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;
EDITAR
Como Martin apontou em um comentário, isso não encontraria transações ativas que ocupam espaço no tempdb, ele encontrará apenas consultas ativas que atualmente estão utilizando espaço lá (e provavelmente culpados pelo uso atual do log). Portanto, pode haver uma transação aberta, mas a consulta real que causa o problema não está mais sendo executada.
Você pode alterar para inner joinon sys.dm_exec_requestse left outer join, em seguida, retornará linhas para sessões que não estão atualmente executando consultas ativamente.
A consulta que Martin postou ...
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;
... identificaria session_ids com transações ativas que ocupam espaço de log, mas você não seria capaz de determinar necessariamente a consulta real que causou o problema, pois, se não estiver em execução agora, não será capturada na consulta acima para solicitações ativas. Você pode verificar reativamente a consulta mais recente usando, DBCC INPUTBUFFERmas ela pode não lhe dizer o que você deseja ouvir. Você pode ingressar externamente de maneira semelhante para capturar os que estão ativamente executando, por exemplo:
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;
Você também pode usar o DMV sys.dm_db_session_space_usagepara ver a utilização geral do espaço por sessão (mas, novamente, pode não receber resultados válidos para a consulta; se a consulta não estiver ativa, o que você recupera pode não ser o culpado).
;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;
Com todas essas consultas à sua disposição, você poderá restringir quem está usando o tempdb e como, especialmente se você as capturar em flagrante.
algumas dicas para minimizar a utilização do tempdb
- use menos tabelas #temp e variáveis @table
- minimizar a manutenção simultânea do índice e evitar a
SORT_IN_TEMPDBopção se não for necessária
- evite cursores desnecessários; evite cursores estáticos se você acha que isso pode ser um gargalo, pois os cursores estáticos usam tabelas de trabalho no tempdb - embora esse seja o tipo de cursor que eu sempre recomendo se o tempdb não for um gargalo
- tente evitar spools (por exemplo, CTEs grandes que são referenciadas várias vezes na consulta)
- não use MARS
- teste minuciosamente o uso dos níveis de isolamento de snapshot / RCSI - não ative-o em todos os bancos de dados, já que lhe disseram que é melhor que o NOLOCK (é, mas não é gratuito)
- em alguns casos, pode parecer pouco intuitivo, mas use mais tabelas temporárias. por exemplo, dividir uma consulta enorme em partes pode ser um pouco menos eficiente, mas se puder evitar um grande derramamento de memória para o tempdb, porque a consulta única e maior exige uma concessão de memória muito grande ...
- evite ativar gatilhos para operações em massa
- evitar o uso excessivo de tipos de LOB (tipos máximos, XML, etc) como variáveis locais
- mantenha as transações curtas e agradáveis
- não defina tempdb como o banco de dados padrão de todos -
Você também pode considerar que o uso do log tempdb pode ser causado por processos internos sobre os quais você tem pouco ou nenhum controle - por exemplo, correio do banco de dados, notificações de eventos, notificações de consulta e intermediário de serviço, todos usam o tempdb de alguma forma. Você pode parar de usar esses recursos, mas se os estiver usando, não poderá determinar como e quando eles usam o tempdb.
