Konstante FlushCache-Nachrichten für SQL-Fehlerprotokolle
Ein Server, der Teil einer SQL 2017 Always on Availability Group (BAG) ist. Ich habe eine Zunahme dieser Nachrichten festgestellt. Ich verstehe, dass dies Nachrichten sind, die seit 2012 standardmäßig im Protokoll angezeigt werden (Ablaufverfolgungsflag vor 2012), aber in den letzten 2 Tagen werden sie alle paar Minuten angezeigt. Derzeit werden keine Sicherungen ausgeführt oder Wartungsarbeiten ausgeführt
Der Server fungiert als sekundärer nicht lesbarer Failover-Partner, und der primäre Server zeigt nicht dasselbe Verhalten.
09/04/2020 10: 52: 24, spid82s, Unknown, FlushCache: 2303 Bufs mit 1881 Schreibvorgängen in 81090 ms (vermieden 11 neue schmutzige Bufs) für db 7: 0 bereinigt 09/04/2020 10:52:07, spid52s, Unbekannt, letztes Ziel ausstehend: 2 avgWriteLatency 86 09/04/2020 10: 52: 07, spid52s, Unbekannt, durchschnittliche Schreibvorgänge pro Sekunde: 17,70 Schreibvorgänge / Sek. durchschnittlicher Durchsatz: 0,19 MB / s E / A-Sättigung: 13073 Kontextwechsel 15434
Es gibt auch eine Warnung im Systemfehlerprotokoll über ein Festplattenproblem. Sekunden danach ist die Verfügbarkeitsgruppe ausgefallen, seit die FlushCache-Nachrichten zugenommen haben.
Hat jemand etwas Ähnliches erlebt oder hat er einen Rat? Mein Systemadministrator untersucht auch das SAN- und VMware-Anwesen.
Hatte ein plötzlicher Gedanke, dass diese durch Autogrowth-Aktivitäten verursacht werden könnten?
Antworten
Wechseln Sie zu indirekten Prüfpunkten (stellen Sie die Wiederherstellungsintervallzeit im Allgemeinen auf 60 Sekunden ein, zumindest für Benutzerdatenbanken).
Ich habe hier und hier über dieses Problem geschrieben , und Sie sollten diese Beiträge vollständig lesen, bevor Sie die Änderung vornehmen, obwohl es meiner Meinung nach so ziemlich ein Kinderspiel ist.
Die Auswirkungen auf unsere Umwelt waren drastisch und unmittelbar, und es war einfach zu beweisen, dass die Änderung verantwortlich war. Jede Datenbank mit dem Symptom ging von 30-60-Sekunden-Prüfpunkten und Fehlerprotokollen mit diesen Meldungen zu Prüfpunkten im Subsekundenbereich und ohne weitere Fehlerprotokolleinträge.
Es gibt wahrscheinlich auch Schadensbegrenzungstechniken für Ihre Arbeitsbelastung. Sehen Sie sich beispielsweise diesen Beitrag von Itzik Ben-Gan an, aber es ist schneller und einfacher, Checkpoints effizienter zu gestalten. Ihre Speicher- und VM-Mitarbeiter sind jedoch nicht vom Haken. Es gibt definitiv ein Festplattenproblem, das behoben werden muss (aber ich bin nicht der Meinung, dass diese FlushCache-Nachrichten die Hauptursache für ein Failover waren; wahrscheinlicher ist, dass sie nur ein anderes Opfer / Symptom sind).
Erkundigen Sie sich bei Ihrem Speicheradministrator, ob kürzlich Firmware-Updates vorliegen oder ob Ihr Speichersubsystem ein neueres Firmware-Update benötigt. Ich habe diese Meldungen in einer SQL-Umgebung mehrmals gesehen und eine Sache, die Sie sich ansehen können, ist die Konfiguration der Speicherebene (dies ist die häufigste Ursache). Eine Sache, um die Leistung Ihrer Festplatte mit perfmon zu überwachen. Plattenzähler müssen Sie konzentrieren sich auf: avg disk sec/Read, avg disk sec/Write, avg disk sec/Transfer.
Sie können den folgenden Link überprüfen, den Sie unten sehen können:
- So funktioniert es: Wann wird die FlushCache-Nachricht zum SQL Server-Fehlerprotokoll hinzugefügt?
- https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-when-is-the-flushcache-message-added-to-sql-server/ba-p/317038
Wenn ich Speicherschicht sage, überprüfen Sie Folgendes: HBA / CNA, Glasfaserkabel, FC-Switch, Anschlüsse, Speichercontroller, Software (MPIO-Treiber) - alle Konfigurationen
Schließlich würde ich dringend empfehlen, Warnungen / Fehlermeldungen in Ihren Ereignisprotokollen immer zu überprüfen und zu untersuchen. Lassen Sie es NICHT passieren, da diese Art von Nachrichten langfristige Konsequenzen hat.