Log de transações cheio: causas e como resolver

Log de transação cheio derruba a disponibilidade do banco inteiro — não é um problema de performance, é indisponibilidade real: nenhuma escrita nova é aceita até haver espaço.

O motivo real está em log_reuse_wait_desc

SELECT name, log_reuse_wait_desc, recovery_model_desc
FROM sys.databases
WHERE name = 'SeuBanco';

Essa coluna diz exatamente por que o espaço já usado do log não está sendo reaproveitado — não adianta simplesmente crescer o arquivo sem entender o motivo, porque ele volta a encher.

Causas mais comuns e a correção de cada uma

• LOG_BACKUP — banco em recovery model FULL sem job de backup de log agendado. Correção: configurar backup de log recorrente (a cada 15-30 min é comum), não só o FULL diário.
• ACTIVE_TRANSACTION — transação aberta há muito tempo segurando o reuso de tudo escrito durante ela. Correção: localizar e fechar (commit ou rollback) a transação, revisar o código que a abriu.
• REPLICATION / AVAILABILITY_REPLICA — um destino de replicação, log shipping ou secundário de Always On está atrasado ou parado, represando o log na origem. Correção: investigar por que o destino parou de processar.
• Autogrowth desabilitado ou disco sem espaço — correção imediata é liberar espaço em disco; correção definitiva é revisar o dimensionamento do log.

Liberando espaço com segurança agora

Se o recovery model é FULL e o log_reuse_wait_desc mostra LOG_BACKUP, um backup de log imediato costuma liberar espaço em segundos — sem precisar mudar recovery model pra SIMPLE (o que quebraria a cadeia de restore point-in-time se isso for um requisito de RPO).