Eu tenho uma pilha de bancos de dados SQL 2005 que existem há muito tempo e, por vários motivos, experimentaram o crescimento automático do log de transações. Os backups regulares agora mantêm o uso do log de transações sob controle, mas os arquivos ainda são grandes e fragmentados.
Eu gostaria de recuperar um pouco desse espaço e aumentar o desempenho reduzindo o número de VLFs. No entanto, também prefiro não interromper nossos backups agendados. Como o DBCC SHRINKFILE() afeta a cadeia de backup do log de transações? Ou não? Isso muda se eu adicionar TRUNCATEONLY ao comando?
Observe que essa é uma correção única. Estou ciente de que diminuir regularmente os arquivos de log é uma coisa ruim - se esses bancos de dados tivessem sido configurados com tamanhos iniciais racionais e configurações de crescimento automático e os backups fossem executados perfeitamente todos os dias de seu histórico, isso não seria um problema.
De acordo com o suporte da Microsoft http://support.microsoft.com/kb/272318 , o SQL Server reduz o arquivo de log removendo o máximo de VLFs possível. Ele faz isso enquanto tenta atingir um tamanho de destino sem atrapalhar sua cadeia de backup.
No entanto, se você usar TRUNCATE_ONLY, a sequência ficará confusa, então você precisará fazer isso logo antes do backup agendado ou fazer o backup completo logo depois disso.
A abordagem recomendada é escolher um horário relativamente silencioso (ou seja, atividade mínima de registro) e fazer o seguinte:
O tamanho apropriado para o log obviamente depende de suas observações de uso de log para cada banco de dados.