Não foi possível truncar o log de transações, log_reuse_wait_desc - AVAILABILITY_REPLICA

Esta manhã, fui acordado por um alerta completo do log de transações em um de nosso banco de dados. Este servidor é um cluster sempre ativo e também um assinante de replicação transacional. Eu verifiquei log_reuse_wait_desc e ele mostrou logbackup. Alguém acidentalmente desabilitou os trabalhos de backup 4 dias antes, reativei o trabalho de backup e o registro foi limpo. Como eram quatro horas da manhã, pensei em ir ao escritório mais tarde naquela manhã e fugir do log, pois ele cresceu para 400 GB.

10:00 - Estou no escritório e verifico o uso do log antes de encolher e foi de cerca de 16%. Fiquei surpreso e verifique o log_reuse_wait_desc, que mostrou replicação. Fiquei confuso porque este era um assinante de replicação. Vimos então que o banco de dados estava ativado para o CDC e pensamos que poderia ser a causa; portanto, o CDC desativado e agora o log_reuse_wait_desc mostra AVAILABILITY_REPLICA.

Enquanto isso, o uso de logs ainda cresce constantemente e agora está em 17%. Verifico o painel do alwayson, verifico a fila de envio e refazer e ambas são praticamente zero. Não sei por que a reutilização do log está sendo exibida como AVAILABILITY_REPLICA e não é possível limpar o log.

Alguma idéia de por que isso está acontecendo?

Se você fizer isto:

SELECT * FROM sys.databases

E o log_reuse_wait_desc mostra AVAILABILITY_REPLICA, o que significa que o SQL Server está aguardando para enviar dados de log para uma das réplicas do Always On Availability Group. Uma das réplicas pode estar atrasada devido a uma rede lenta ou pode estar totalmente inativa.

Se você verificar o painel do AG e ele não mostrar filas, você pode ter sido vítima de esgotamento do encadeamento. É um problema conhecido que o painel da AG pára de atualizar após o esgotamento do encadeamento do trabalhador. Você precisará verificar o status de cada réplica diretamente, em vez de confiar na principal. A observação de Nick nesse item do Connect diz que você pode alterar as propriedades de uma réplica para reiniciar a replicação, mas isso nem sempre funciona (especialmente se você tiver centenas de bancos de dados em uma réplica com uma grande quantidade de dados que precisam ser enviados e reiniciar a replicação pode causar o esgotamento do encadeamento do trabalhador novamente.)

Se o último cara configurou uma réplica de AG e não deve mais existir, é hora de remover esse AG e / ou réplica. Apenas tome cuidado para que os aplicativos não estejam apontando para o nome do ouvinte para conectar-se ao seu SQL Server.