Início / dba / Perguntas / 175039
Accepted
Peter
Asked: 2017-06-01 06:32:52 +0800 CST

Diagnosticando commits Always On lentos

  • 772

Grupo de disponibilidade Always On de dois nós, uma réplica síncrona.

Minha réplica síncrona fica fora de sincronia com muita regularidade. Vejo um padrão em que, quando ocorre um backup de log na réplica secundária, ocorrerá um curto período de atraso durante o qual o redo_queue_size é preenchido rapidamente, assim:

insira a descrição da imagem aqui

[1]: https://i.sta

Observando a orientação no link a seguir, parece que meu problema se deve principalmente à contenção que o thread de redo experimenta ao tentar proteger as transações:

https://technet.microsoft.com/en-us/library/dn135335(v=sql.110).aspx

A réplica fica ainda mais fora de sincronia quando um backup de log de transações é executado e esse problema é agravado pelos relatórios executados na réplica secundária também.

O tempo todo, meus backups de log de transações são enormes - em média 1,2 GB, mas podem ser maiores.

Até onde sei, meus backups de log serão grandes porque tenho o TDE habilitado no banco de dados, mas realmente não esperava que fossem tão grandes. Suspeito que isso seja o que mais contribui para as confirmações lentas na réplica secundária.

Existem contadores de desempenho recomendados para diagnosticar confirmações lentas em uma réplica síncrona? O que mais posso fazer para validar minha teoria?

Meu problema parece ser o mesmo descrito aqui: https://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

Posso apenas habilitar esse sinalizador de rastreamento na réplica secundária ou ele precisa ser aplicado a ambos os nós?

EDIT: verifiquei a fila de refazer às 6 da manhã e encontrei um número enorme, com um tempo de recuperação de 15 a 20 minutos e aumentando um pouco o tempo todo. Em seguida, apliquei o traceflag DBCC TRACEON (3459, -1)e descobri que, após alguns minutos, o número de comandos de refazer caiu extremamente rapidamente. Até agora, o problema parece ter sido mitigado por esse sinalizador de rastreamento, mas presumivelmente isso colocará todas as transações protegidas no log da réplica secundária no modo de thread único, como o SQL Server 2014 e, portanto, ainda há potencial para a réplica secundária ficar para trás como resultado do encadeamento não paralelo, quando o primário está sob carga de gravação pesada.

performance availability-groups

1 respostas

  1. Best Answer

    Os problemas que eu estava enfrentando:

    1. Réplica secundária síncrona ficando para trás semipermanentemente
    2. Grandes backups de log

    Isso foi resolvido habilitando o sinalizador de rastreamento 3459. No meu caso foi extremamente fácil ver que o sinalizador corrigiu imediatamente o tipo de espera parallel_redo_flow_control dirty_page_table_lock parallel_drain_redo_workere mostrou uma rápida diminuição no tamanho da fila de redo.

    Eu me pergunto por que, no relatório de bug, a Microsoft chama isso de "asserção": https://support.microsoft.com/en-us/help/3200975/fix-assertion-occurs-when-you-use-parallel-redo- em uma réplica secundária

    Crédito para Jason AKA CirqueDeSQLeil de SQLServerCentral.com https://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

    • 3

relate perguntas