Um servidor que faz parte de um grupo de disponibilidade (BAG) do SQL 2017 Always on, notei um aumento dessas mensagens. Entendo que essas são mensagens que aparecem no log como padrão desde 2012 (sinalizador de rastreamento anterior a 2012), mas nos últimos 2 dias elas estão aparecendo a cada poucos minutos, não há backups em execução ou trabalhos de manutenção nesses horários
O servidor está agindo como o parceiro de failover secundário não legível e o servidor primário não está exibindo o mesmo comportamento.
09/04/2020 10:52:24,spid82s,Desconhecido,FlushCache: limpou 2303 bufs com 1881 gravações em 81090 ms (evitou 11 novos bufs sujos) para db 7:0 09/04/2020 10:52:07, spid52s,desconhecido,último destino pendente: 2 avgWriteLatency 86 09/04/2020 10:52:07,spid52s,desconhecido,gravações médias por segundo: 17,70 gravações/s taxa de transferência média: 0,19 MB/s saturação de E/S: 13073 alternâncias de contexto 15434
Há também um aviso no log de erros do sistema sobre o problema do disco, segundos depois disso, o grupo de disponibilidade falhou desde que as mensagens do FlushCache aumentaram.
Alguém já experimentou algo semelhante ou tem algum conselho, meu administrador de sistema também está analisando a propriedade SAN e VMware.
Teve um pensamento repentino que isso poderia ser causado por atividades de autocrescimento?
Alterne para pontos de verificação indiretos (geralmente, defina o tempo de intervalo de recuperação para 60 segundos, pelo menos para bancos de dados de usuários).
Eu escrevi sobre esse problema aqui e aqui , e você deve ler essas postagens na íntegra antes de fazer a alteração, embora seja praticamente um IMHO acéfalo.
O impacto em nosso ambiente foi drástico e imediato, e foi simples provar que a mudança foi responsável. Cada banco de dados com o sintoma passou de pontos de verificação de 30 a 60 segundos e logs de erros cheios dessas mensagens, para pontos de verificação de menos de um segundo e sem mais entradas de log de erros.
Provavelmente também existem técnicas de mitigação para sua carga de trabalho, por exemplo, veja este post de Itzik Ben-Gan, mas tornar os pontos de verificação mais eficientes é um caminho mais rápido e fácil. Seu pessoal de armazenamento e VM não está fora do gancho, no entanto; há definitivamente um problema de disco que eles precisam resolver (mas eu discordo que essas mensagens do FlushCache foram a causa raiz de qualquer failover; mais provavelmente elas são apenas uma vítima/sintoma diferente).
Verifique com seu administrador de armazenamento se há alguma atualização de firmware recentemente ou se seu subsistema de armazenamento precisa de uma atualização de firmware mais recente. Eu vi essas mensagens no ambiente SQL várias vezes e uma coisa que você pode observar é a configuração da camada de armazenamento (essa é a causa comum). Além disso, uma coisa para monitorar o desempenho do disco usando perfmon. contadores de disco nos quais você precisa se concentrar:
avg disk sec/Read,avg disk sec/Write,avg disk sec/Transfer.Você pode verificar o seguinte link que você pode olhar abaixo:
Quando digo camada de armazenamento, verifique o seguinte: HBA/CNA, Fiber Cable, FC Switch, Ports, Storage controller, Software (drivers MPIO) - toda a sua configuração
Finalmente, eu recomendo sempre verificar e investigar mensagens de avisos/erros em seus logs de eventos. NÃO deixe passar porque esse tipo de mensagem tem consequências a longo prazo.