Por que meu tempdb estava cheio e o que estava tentando encolher?

Question

Após meses de uso de disco perfeitamente plano, meu arquivo tempdb cresceu de repente em vários shows durante o final de semana. Ninguém na empresa sabe de nada que possa ter mudado.

Quando eu verifiquei o banco de dados tempdb, ele tinha apenas algumas tabelas muito pequenas, cujos nomes eram strings de dígitos hexadecimais.

Ao procurar a causa, achei a seguinte mensagem repetida a cada alguns minutos por vários dias no log de eventos:

DBCC SHRINKDATABASE for database ID 2 is waiting for the snapshot transaction 
with timestamp 51743762409 and other snapshot transactions linked to timestamp 
51743762409 or with timestamps older than 51801253540 to finish.

Não consigo encontrar nenhuma maneira possível de o DBCC SHRINKDATABASE ter sido executado por ninguém no tempdb (que é o ID do banco de dados 2). A própria documentação da Microsoft diz que o SHRINKDATABASE nunca deve ser executado em tempdb enquanto estiver on-line, então não posso imaginar que o SQL Server esteja executando ele mesmo.

Estou tentando descobrir:

• O que poderia ter causado um crescimento rápido tão repentino no arquivo tempdb? Não estou ciente de nenhum código que use tabelas temporárias ou declare variáveis de tabela neste servidor. O que mais usa o arquivo tempdb?
• Por que o DBCC SHRINKDATABASE está sendo executado no tempdb, e por que está falhando?

Answer 1

Primeiro, eu verificaria o rastreamento padrão se alguém estivesse executando manualmente o comando DBCC SHRINKDATABASE. O código a seguir irá ajudá-lo como DBCC stmt é auditado no rastreamento padrão.  você pode compartilhar seu SELECT @@ VERSION?

DECLARE @filename VARCHAR(255) 
SELECT @FileName = SUBSTRING(path, 0, LEN(path)-CHARINDEX('\', REVERSE(path))+1) + '\Log.trc'  
FROM sys.traces   
WHERE is_default = 1;  

SELECT gt.HostName, 
       gt.ApplicationName, 
       gt.NTUserName, 
       gt.NTDomainName, 
       gt.LoginName, 
       gt.SPID, 
       gt.EventClass, 
       te.Name AS EventName,
       gt.EventSubClass,      
       gt.TEXTData, 
       gt.StartTime, 
       gt.EndTime, 
       gt.ObjectName, 
       gt.DatabaseName, 
       gt.FileName, 
       gt.IsSystem
FROM [fn_trace_gettable](@filename, DEFAULT) gt 
JOIN sys.trace_events te ON gt.EventClass = te.trace_event_id 
WHERE EventClass in (116) --AND gt.EventSubClass = 2
ORDER BY StartTime DESC; 

O texto a seguir mostra se os arquivos de dados e log cresceram recentemente e podem ajudar a identificar por quê?

DECLARE @filename VARCHAR(255) 
SELECT @FileName = SUBSTRING(path, 0, LEN(path)-CHARINDEX('\', REVERSE(path))+1) + '\Log.trc'  
FROM sys.traces   
WHERE is_default = 1;  

--Check if the data and log files auto-growed. Look for tempdb, log files etc.
SELECT 
    gt.ServerName
    , gt.DatabaseName
    , gt.TextData
    , gt.StartTime
    , gt.Success
    , gt.HostName
    , gt.NTUserName
    , gt.NTDomainName
    , gt.ApplicationName
    , gt.LoginName
FROM [fn_trace_gettable](@filename, DEFAULT) gt 
JOIN sys.trace_events te ON gt.EventClass = te.trace_event_id 
WHERE EventClass in ( 92, 93 ) --'Data File Auto Grow', 'Log File Auto Grow'
ORDER BY StartTime; 
--

    

Answer 2

Verifique seus planos de manutenção. Alguém pode ter alterado ou adicionado manualmente um ao servidor. Verifique também se o modo de recuperação do seu banco de dados foi alterado recentemente.