Primeiro, esta NÃO é uma duplicata desta pergunta . Nessa questão, a pessoa estava sobrescrevendo o arquivo todas as vezes e a solução é usar INIT ou NOINIT.
No meu caso, estamos gerando um nome de arquivo exclusivo com cada backup - um registro de data e hora é anexado ao nome do arquivo.
Temos um trabalho de agente que executa backups completos todas as noites para cerca de 20 bancos de dados. Por cerca de uma semana, 1 banco de dados parece estar aumentando de tamanho significativamente a cada noite.
Executamos um segundo trabalho de agente que executa backups de log a cada 15 minutos, mas para de ser executado entre 23h e 5h. Normalmente, logo pela manhã, os backups de log são grandes e, em seguida, seu tamanho é pequeno até que as pessoas comecem a trabalhar e, em seguida, eles têm vários tamanhos.
Tudo isso está funcionando sem problemas há anos.
Apenas um banco de dados dos 20 está mostrando esse problema - o backup completo de cada noite é significativamente maior do que na noite anterior.
Os backups do arquivo de log estão funcionando para este banco de dados e todos os outros.
Temos um grupo de disponibilidade com três réplicas. Duas são configuradas para failover uma para a outra e a terceira réplica é somente leitura para consultas pesadas, extrações de dados e relatórios. O console AG mostra marcas de seleção verdes em toda a página para todos os servidores.
O banco de dados em questão é o maior dos 20. O backup completo normal tem cerca de 25 GB. Ele aumentou lentamente da seguinte forma: 33, 35, 36, 41, 47, 54, 64, 73 GB.
Por outro lado, para todos os 14 backups anteriores a esse problema, o tamanho do arquivo era bastante estável em torno de 25 GB.
Acabei de pausar todos os backups de log para todos os bancos de dados e emitir um backup completo para o banco de dados afetado e esse último backup completo é de 76 GB.
Este parece ter sido um problema específico onde
sys.databases.log_reuse_waitestava relatandoAVAILABILITY_REPLICAduas réplicas no Grupo de Disponibilidade eACTIVE_TRANSACTIONna terceira réplica.No meu caso, tentar determinar a transação ativa não produziu resultados - leia todo o tópico de comentários sobre a pergunta para obter detalhes.
No final, reiniciei aquela réplica e tudo resolvido.
Resumindo
O arquivo de log estava sendo mantido aberto por uma transação ativa (ou pelo menos o banco de dados pensava assim) e isso de alguma forma estava fluindo para o tamanho do arquivo de backup completo do arquivo de dados crescendo todas as noites.
A identificação da causa raiz veio por meio de verificação
sys.databases.log_reuse_wait- com agradecimentos a @JD nos comentários pela sugestão -E a resolução veio por meio da reinicialização da réplica afetada (porque não consegui encontrar nenhuma transação ativa para
kill, apesar dalog_reuse_waitmensagem dizendoACTIVE_TRANSACTION).