AlwaysON: Log_Send_Queue_Size está aumentando, mas o log_send_rate continua diminuindo?

Pergunta

1. Por que, apesar do log_send_queue_size aumentar para esses dois bancos de dados, o log_send_rate continuou diminuindo?
2. Não houve problemas de largura de banda na rede neste momento e nenhum outro banco de dados apresentou esse problema. Se isso acontecer novamente , existe uma correção recomendada, além de ter que restaurar manualmente o banco de dados primário no secundário para ressincronizar o par?

Meio Ambiente :

SQL 2012, SP1 CU7 (Compilação 3393)

Windows Server 2012 Standard (Compilação 9200)

Grupo de Disponibilidade de 10 bancos de dados (PRDDB1-AG1)

2 réplicas AG, uma em Londres e outra em Nova York (LDSERVER1 & NYSERVER1), primária em NY, secundária em Londres.

2 bancos de dados no AG1, E-DB1(arquivo de log de 50 GB) e T-DB2(arquivo de log de 250 GB)

O T-DB2banco de dados importa arquivos de clientes, os processa (muita atividade de log) e, em seguida, gera/atualiza os dados no banco de E-DB1dados.

Esse processo gera muita rotatividade de dados e atividade de log em ambos os bancos de dados. Temos picos ocasionais de latência entre as réplicas de banco de dados de Londres e Nova York, talvez uma ou duas vezes por semana, no máximo, mas sempre desaparecem em algumas horas.

Questão :

Na semana passada, vimos um log_send_queue_size crescente e um log_send_rate decrescente. Isso começou na segunda-feira e continuou até a noite de sexta-feira, quando foi resolvido manualmente (consulte a seção Corrigir abaixo) . Em seu nível mais baixo, o log_send_rate do banco de dados E-DB1 era de pouco mais de 100 KB/s com um log_send_queue de mais de 40 GB. O banco de dados T-DB2 tinha um log_send_rate de 2.000 KB/s diminuindo para 300 KB/s, com um log_send_queue de mais de 300 GB.

Isso levou a uma quantidade crescente de latência entre as réplicas primária e secundária desses dois bancos de dados no grupo de disponibilidade. Isso foi caracterizado por um acúmulo de atividade de log dentro do log de transações para cada banco de dados afetado, o que é esperado. Devido a essa latência, os logs de cada banco de dados afetado se expandiam a ponto de a unidade de log correr o risco de ficar sem espaço.

Essa latência ocorreu apenas nesses dois bancos de dados, apesar de alguns picos bastante grandes na atividade transacional em todos os bancos de dados do grupo de disponibilidade, como é normal.

Ao longo desse problema, não houve acúmulo na fila de redo no secundário e o redo_rate permaneceu alto. Isso implicaria que o problema era devido à baixa taxa de envio para ambos os bancos de dados afetados.

Etapas tentadas

1. Suspenda a movimentação de dados do banco de dados T-DB2. Eu esperava que isso liberasse largura de banda de rede para o banco de dados prioritário, E-DB1. Sem efeito.

2. Reinicializou o nó secundário (LDPRDENTDB1). Sem efeito.

Fixar

3. As etapas a seguir resolveram o problema. Como os arquivos de log cresceram para mais de 300 GB, precisei limpá-los e reduzi-los antes que ficássemos sem espaço em disco.

   uma. Bancos de dados removidos do grupo de disponibilidade.

   b. Bancos de dados descartados no secundário.

   c. Bancos de dados adicionados novamente ao grupo de disponibilidade no primário (NYSERVER1, opção de sincronização manual).

   d. Backup dos bancos de dados no primário e restaurado no secundário (70 GB copiados de NY para LD, em pouco menos de 24 horas)

   e. Bancos de dados adicionados novamente ao grupo de disponibilidade no secundário.