Antes de marcar imediatamente como duplicado , li o artigo Por que o log de transações continua a crescer ou ficar sem espaço? , mas acho que não deu uma resposta para minha situação. Examinei uma dúzia de perguntas semelhantes, mas as mais relevantes apenas disseram "duplicado" e apontaram para a pergunta de Mike.
Detalhes: Eu tenho vários bancos de dados de ~ 500 MB no SQL Server 2008 R2, todos no modo de recuperação SIMPLES (não é minha escolha), backups completos noturnos, com ~ 200 MB de arquivos de dados e ~ 300 MB de arquivos de log. O log não aumenta para 300 MB imediatamente, mas lentamente ao longo de alguns meses. Não há transações abertas em nenhuma delas, pelo menos de acordo com sp_who2 e o monitor de atividades. Se eu clicar com o botão direito do mouse no banco de dados e selecionar propriedades, ele informará que há ~ 50 MB gratuitos. Particularmente logo após um backup, o log inteiro não deve estar livre? No modo SIMPLES, o log não deve estar livre enquanto não houver uma transação aberta?
log_reuse_wait_descfrom sys.databasessays diz "NADA", que com base na pergunta e resposta mencionadas acima, diz que não deve esperar nada para reutilizar o espaço.
Se eu fizer 'DBCC SHRINKFILE', o arquivo de log diminuirá para 1 MB, portanto, ele está disposto a recuperar o espaço. Posso configurar algo que diminua os logs semanalmente e mantenha as coisas fora de controle, mas estou confuso sobre o motivo pelo qual o SQL Server me faria fazer isso.
Eu posso entender se houve alguma transação maluca que precisava de 300 MB para registrá-la, mas não estamos fazendo nada extremo, apenas o OLTP básico. Da pergunta / resposta de Mike:
Modelo de recuperação simples - Portanto, com a introdução acima, é mais fácil falar sobre o modelo de recuperação simples primeiro. Neste modelo, você está dizendo ao SQL Server - eu estou bem com você usando seu arquivo de log de transações para travar e reiniciar a recuperação (você realmente não tem escolha lá. Procure propriedades ACID e isso deve fazer sentido rapidamente), mas quando você não mais precisar para esse fim de recuperação de falha / reinicialização, vá em frente e reutilize o arquivo de log.
O SQL Server escuta essa solicitação na Recuperação Simples e mantém apenas as informações necessárias para travar / reiniciar a recuperação. Quando o SQL Server tiver certeza de que pode se recuperar porque os dados estão protegidos para o arquivo de dados (mais ou menos), os dados que foram protegidos não são mais necessários no log e são marcados para truncamento - o que significa que são reutilizados.
Ele continua dizendo que o espaço de log deve ser reutilizado, mas com esse lento crescimento ao longo de meses, parece que não.
o que estou perdendo? Há algo impedindo o SQL Server de reconhecer os dados como "protegidos" e liberando o log?
(editar) Relatório Após Ação - AKA um pouco de conhecimento é perigoso
Depois de descobrir que essa é uma "questão popular", parecia que eu devia uma explicação sobre o que aconteceu sete meses atrás e o que aprendi para, esperançosamente, salvar outras pessoas de algum sofrimento.
Primeiro, o espaço disponível que você vê no SSMS quando visualiza as propriedades em um banco de dados é o espaço disponível no arquivo de dados. Você pode visualizar isso executando o seguinte em um banco de dados e encontrará o espaço disponível relatado pelo SSMS como a diferença entre o FileSizeMB e o UsedSpaceMB:
SELECT
DB.name,
MF.physical_name,
MF.type_desc AS FileType,
MF.size * 8 / 1024 AS FileSizeMB,
fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
mf.name LogicalName
FROM
sys.master_files MF
JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE DB.name = 'yourdatabasename'Isso confirmou que, em circunstâncias normais, estávamos usando muito pouco espaço de log (20 MB ou menos), mas isso leva ao segundo item ...
Segundo, minha percepção dos troncos crescendo era lentamente ao longo do tempo. No entanto, na realidade, os logs estavam crescendo rapidamente nas noites em que o responsável pela aplicação de patches para esse aplicativo de terceiros estava aplicando patches. O patch foi feito como uma única transação, portanto, dependendo do patch, os dados de 200 MB precisavam de 300 MB de log. A chave para rastrear isso foi a consulta de Aaron Bertrand em https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace
DECLARE @path NVARCHAR(260);
SELECT
@path = REVERSE(SUBSTRING(REVERSE([path]),
CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM sys.traces
WHERE is_default = 1;
SELECT
DatabaseName,
[FileName],
SPID,
Duration,
StartTime,
EndTime,
FileType = CASE EventClass
WHEN 92 THEN 'Data'
WHEN 93 THEN 'Log'
END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
EventClass IN (92,93)
ORDER BY
StartTime DESC;Isso mostrou que o log estava crescendo em determinadas noites, quando o cliente não estava usando o banco de dados. Isso levou à conversa com o cara aplicando os adesivos e a resposta para o mistério.
Mais uma vez obrigado pelas pessoas que forneceram ajuda para me responder.