Messages FlushCache de constante du journal des erreurs SQL

Question

Un serveur qui fait partie d'un groupe de disponibilité SQL 2017 Always On (BAG) J'ai remarqué une augmentation de ces messages. Je comprends que ce sont des messages qui apparaissent dans le journal en standard depuis 2012 (indicateur de trace avant 2012) mais au cours des 2 derniers jours, ils apparaissent toutes les quelques minutes, il n'y a pas de sauvegardes en cours d'exécution ou de travaux de maintenance à ces moments

Le serveur agit en tant que partenaire de basculement secondaire non lisible et le serveur principal ne présente pas le même comportement.

09/04/2020 10: 52: 24, spid82s, Unknown, FlushCache: nettoyé 2303 bufs avec 1881 écritures en 81090 ms (évité 11 nouveaux bufs sales) pour db 7: 0 09/04/2020 10:52:07, spid52s, Inconnu, dernière cible en attente: 2 avgWriteLatency 86 09/04/2020 10: 52: 07, spid52s, Inconnu, écritures moyennes par seconde: 17,70 écritures / s Débit moyen: 0,19 Mo / s Saturation E / S: 13073 commutateurs de contexte 15434

Il y a également un avertissement dans le journal des erreurs système concernant un problème de disque, quelques secondes après cela, le groupe de disponibilité a basculé depuis que les messages FlushCache ont augmenté.

Quelqu'un a-t-il vécu quelque chose de similaire ou a-t-il des conseils, mon administrateur système examine également le domaine SAN et VMware.

Une pensée soudaine pouvait-elle être causée par des activités d'auto-croissance?

Answer 1

Passez aux points de contrôle indirects (en général, définissez l'intervalle de récupération sur 60 secondes, au moins pour les bases de données utilisateur).

J'ai écrit sur ce problème ici et ici , et vous devriez lire ces articles dans leur intégralité avant de faire le changement, bien que ce soit à peu près une évidence à mon humble avis.

L'impact dans notre environnement a été drastique et immédiat, et il était simple de prouver que le changement était responsable. Chaque base de données avec le symptôme est passée de 30 à 60 secondes de points de contrôle, et de journaux d'erreurs pleins de ces messages, à des points de contrôle de moins d'une seconde et plus d'entrées de journal d'erreurs.

Il existe probablement des techniques d'atténuation pour votre charge de travail, par exemple, voir ce post d'Itzik Ben-Gan, mais rendre les points de contrôle plus efficaces est un chemin plus rapide et plus facile. Vos équipes de stockage et de VM ne sont pas décrochées, cependant; il y a certainement un problème de disque à résoudre (mais je ne suis pas d'accord pour dire que ces messages FlushCache étaient la cause première de tout basculement; plus probablement, ils ne sont qu'une victime / symptôme différent).

Answer 2

Vérifiez auprès de votre administrateur de stockage s'il y a des mises à jour du micrologiciel récemment ou si votre sous-système de stockage a besoin d'une mise à jour du micrologiciel plus récente. J'ai vu ces messages sur l'environnement SQL plusieurs fois et une chose que vous pouvez regarder est la configuration de la couche de stockage (c'est la cause commune). Aussi, une chose pour surveiller les performances de votre disque à l'aide de perfmon. compteurs de disque dont vous avez besoin de se concentrer sur: avg disk sec/Read, avg disk sec/Write, avg disk sec/Transfer.

Vous pouvez consulter le lien suivant que vous pouvez regarder ci-dessous:

1. Fonctionnement: quand le message FlushCache est-il ajouté au journal des erreurs SQL Server?
2. https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-when-is-the-flushcache-message-added-to-sql-server/ba-p/317038

Quand je dis couche de stockage, vérifiez les éléments suivants: HBA / CNA, câble à fibre, commutateur FC, ports, contrôleur de stockage, logiciel (pilotes MPIO) - toute sa configuration

Enfin, je recommande vivement de toujours vérifier et examiner les messages d'avertissement / d'erreur sur vos journaux d'événements. NE PAS le laisser passer car ce type de messages a des conséquences à long terme sur la route.