Em um servidor sql dedicado a um banco de dados do Dynamics CRM, tenho visto alguns comportamentos estranhos.
Ao monitorar o crescimento usando a seguinte consulta como base, notei que o tempdb cresceu com bastante frequência nas últimas horas:
DECLARE @path NVARCHAR(1000)
SELECT @path = Substring(PATH, 1, Len(PATH) - Charindex('\', Reverse(PATH))) +
'\log.trc'
FROM sys.traces
WHERE id = 1
SELECT databasename,
e.name AS eventname,
cat.name AS [CategoryName],
starttime,
e.category_id,
loginname,
loginsid,
spid,
hostname,
applicationname,
servername,
textdata,
objectname,
eventclass,
eventsubclass
FROM ::fn_trace_gettable(@path, 0)
INNER JOIN sys.trace_events e
ON eventclass = trace_event_id
INNER JOIN sys.trace_categories AS cat
ON e.category_id = cat.category_id
WHERE e.name IN( 'Data File Auto Grow', 'Log File Auto Grow' )
ORDER BY starttime DESC
Dá várias linhas de crescimento dos arquivos de dados:
tempdb Data File Auto Grow Database 2015-03-02 09:50:33.187 2
No entanto, quando olho para o espaço ocupado pelo tempdb, não vejo onde está a crise de espaço:
USE tempdb
GO
SELECT DB_NAME() AS DbName,
name AS FileName,
size/128.0 AS CurrentSizeMB,
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB
FROM sys.database_files;
Dá a seguinte saída:
DbName FileName CurrentSizeMB FreeSpaceMB
tempdb tempdev 7500.000000 7492.625000
tempdb templog 156.132812 93.820312
tempdb tempdev2 7250.000000 7245.625000
tempdb tempdev3 7250.000000 7245.312500
tempdb tempdev4 7366.500000 7360.875000
A pessoa que mantém o CRM nos pediu para reduzir o tempdb.
Meu colega, no passado, obrigado. No entanto, não estou disposto a fazê-lo sem uma explicação. Especialmente considerando que o encolhimento se tornou uma ocorrência quase semanal.
Alguém pode me dar uma indicação de por que o tempdb tem tantos eventos de crescimento e como lidar com isso corretamente?
No momento, estou pensando em pedir mais armazenamento e aumentar a unidade tempdb em 50%.
No entanto, isso parece tratar o sintoma, não a causa.
Esta é uma pergunta antiga, mas parece que merece uma resposta mais geral.
O conselho padrão em relação ao dimensionamento do tempdb no servidor SQL é torná-lo grande o suficiente para lidar com qualquer atividade de rotina que seu servidor lance nele e interromper o crescimento e a redução do microgerenciamento .
O SQL usa o tempdb para várias coisas : classificações na memória, reindexação de tabelas, tabelas temporárias explicitamente criadas, instantâneos do banco de dados, etc. O SQL deve usar o espaço no tempdb conforme necessário e liberá-lo internamente quando concluído. Os tamanhos gerais de arquivo não precisam mudar o tempo todo. Não há motivo para continuar recuperando esse espaço de volta ao sistema operacional, o SQL provavelmente precisará dele novamente em breve. A única maneira de determinar se a quantidade de uso do tempdb é "normal" é monitorá-la ao longo do tempo.
Como um DBA de produção, eu recusaria uma solicitação como essa de uma equipe de aplicativos para reduzir o tempdb , pelo menos sem muita discussão adicional. Isso também vale para "recomendações de fornecedores"; mesmo que o fornecedor seja a Microsoft - a equipe do MS CRM (e a equipe do SharePoint, a equipe do System Center, etc.) não é a equipe do produto Microsoft SQL.
Sua postagem não diz o tamanho dos bancos de dados de usuários, mas, em minha experiência como DBA de produção, 30 GB de arquivos de dados tempdb não é nada grande. Na verdade, se você ainda está vendo crescimentos de arquivos de dados tempdb mesmo em 30 GB, então, ao contrário do pedido deles, você precisa torná-lo maior , não menor. Tamanhos de Tempdb de 100 GB ou mais não são incomuns se os dbs do usuário forem muito grandes (100 GB ou TB).
Dê ao SQL o espaço em disco de que ele precisa para fazer seu trabalho.
Seu arquivo de log tempdb , por outro lado, é extremamente subdimensionado. No seu caso, provavelmente faria 25% do tamanho total dos arquivos de dados ou mais.
Dito isso, no seu caso eu provavelmente tentaria algo como:
Continue monitorando, veja se é um tamanho suficiente ou se eles continuam a crescer.
Existem algumas atividades (consultas mal escritas, reindexação de tabelas enormes, etc.) que podem explodir o log e exigiriam uma atenção mais direcionada ao que exatamente causou o problema.
Qual é o modelo de crescimento automático para os arquivos TempDB? Pequenos incrementos incorrerão em muitos pequenos autocrescimentos, enquanto grandes incrementos incorrerão em menos rotinas de crescimento, porém mais intensivas.
Presumivelmente, o TempDB está crescendo porque as consultas em execução no servidor estão construindo muitas tabelas temporárias, variáveis de tabela ou cursores e assim por diante?
Sabe-se quais consultas estão sendo executadas e você tem uma linha de base histórica para comparar os crescimentos automáticos e tamanhos?
Se as coisas mudaram repentinamente e a organização não aumentou significativamente a quantidade de dados reais que usa, eu diria que um desenvolvedor ou usuário de relatório mudou a maneira como executa suas consultas.
Acho que precisamos de um pouco mais de informação de vocês, sobre o que foi dito acima.
Embora eu tivesse o mesmo problema, encontrei uma solução diferente.
O problema: arquivos de dados tempdb com 99% de espaço não utilizado. O espaço em disco está próximo de zero. Eu libero algum espaço no disco e, em 24 horas, os arquivos de dados cresceram para consumir todo o espaço do disco novamente. Eles ainda relatam 99% de espaço não utilizado.
Solução: Tínhamos o checkDB em execução em um trabalho durante a noite em uma programação diária. checkDB criou um instantâneo no tempdb que era muito grande para o tempdb manipular e continuava falhando (o que também estávamos tentando resolver por que o trabalho estava falhando separadamente). Acontece que ambos os problemas foram vinculados, os arquivos de dados tempdb preenchidos e o crescimento automático com o trabalho checkDB, que falharia quando ficasse sem espaço em disco. O banco de dados que está sendo verificado estava acima de um TB.
Espero que isso acrescente à solução acima para futuros Googlers.