Início / dba / Perguntas / 172390
Accepted
jesijesi
Asked: 2017-05-01 17:12:35 +0800 CST

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

  • 772

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

10AM- Estou no escritório e verifico o uso do log antes de encolher e estava em torno de 16%. Fiquei surpreso e verifiquei o log_reuse_wait_desc, que mostrava a replicação. Fiquei confuso porque este era um assinante de replicação. Vimos então que o db estava habilitado para CDC e pensamos que poderia ser a causa, então desabilitamos o CDC e agora o log_reuse_wait_desc mostra AVAILABILITY_REPLICA.

Enquanto isso, o uso de logs continua crescendo e está em 17% agora. Eu verifico o painel Alwayson e verifico a fila de envio e refazer e ambos 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 ideia de por que isso está acontecendo?

sql-server sql-server-2014

4 respostas

  1. Best Answer

    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 de suas 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 de thread. É um problema conhecido que o painel AG para de atualizar após a exaustão do thread de trabalho. Você precisará verificar o status em cada réplica diretamente, em vez de confiar no primário. A nota de Nick nesse item do Connect diz que você pode apenas 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 apenas causar a exaustão do thread de trabalho novamente.)

    Se o último cara configurou uma réplica de AG e não deveria existir mais, então é 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 se conectar ao seu SQL Server.

    • 8

  2. Antes tarde do que nunca: temos casos semelhantes, mesmos sintomas.

    Verificar:

    SELECT log_reuse_wait_desc  FROM sys.databases  where name = '..'

    em todas as suas instâncias secundárias do AlwaysOn.

    se log_reuse_wait_descestiver REPLICATIONem um deles, alterne o primário para a instância e desative a replicação nele. Se ainda não houver replicação, use sp_removedbreplication.

    • 0

  3. No nosso caso, parece algum tipo de bug quando o log é preenchido em sistemas com cdc/replication e AlwaysON. Esse problema aconteceu novamente e a solução foi habilitar e desabilitar o CDC novamente. Os eventos foram como abaixo

    1. Log de transações do banco de dados publicado cheio devido ao banco de dados do distribuidor ficar sem espaço e falha no leitor de log. log_reuse_wait_desc mostra a replicação, que é precisa.
    2. Replicação desabilitada completamente, log_reuse_wait_desc ainda replicação, pois o db possui CDC.
    3. CDC desabilitado, log_reuse_wait_desc alterado para AVAILABILITY_REPLICA, mesmo que o AG estivesse funcionando e enviando dados e nenhuma fila de envio de log.
    4. Habilitado e desabilitado o CDC novamente no db, log_reuse_wait_desc voltou a nada.
    • 0

  4. Eu tive o mesmo problema
    O banco de dados foi marcado como sincronizado no primário, mas NÃO sincronizado no secundário
    Cliquei com o botão direito do mouse no banco de dados secundário e selecionei Resume Data Movement
    Atualizei e vi que agora estava marcado como sincronizado no primário, sincronizando no secundário
    . começando a se preocupar, pois não se recuperou após 20 minutos - E então se recuperou!

    Atribuo isso ao volume de dados que teve que ser sincronizado

    • 0

relate perguntas