"Wow, es scheint alles viel schneller zu gehen. Was hat sich geändert?"
Ehrlich gesagt, ist das nicht die Art von Anruf, die ich als DBA oft erwarte. Es ist jedoch die Art von Anruf, die wir uns alle für unsere Arbeit wünschen, und hin und wieder passiert das auch.
In diesem Fall hatten wir im Betriebsteam gemeinsam mit den Entwicklern an der letzten Runde von Datenbankänderungen gearbeitet, nachdem wir festgestellt hatten, dass sich die Leistung einer unserer Datenbanken im Laufe der Zeit verschlechtert hatte, und Vorschläge gemacht, die unserer Meinung nach zu einer Verbesserung der Leistung beitragen und die Bereitstellung der Änderungen erleichtern würden.
Entscheidend war, dass wir vor der Implementierung der Änderungen in den vorangegangenen Wochen Basisdaten für mehrere wichtige SQL-Server-Leistungskennzahlen erfasst hatten. Das bedeutete, dass wir genau wussten, wie die Ressourcennutzung auf dem Server vor den Änderungen aussah, und wir konnten eine ähnliche Messung nach der Implementierung durchführen und so die genauen Auswirkungen unserer Arbeit auf die Ressourcenauslastung des Servers genau einschätzen.
Als Ergebnis erhielten wir nicht nur einen anekdotischen Beweis für das positive Ergebnis in Form eines Anrufs eines zufriedenen Nutzers, sondern wir hatten auch harte Kennzahlen, die wir unserem Manager vorlegen konnten, und wir waren in der Lage, zumindest einen Teil der Anerkennung dafür als Team zu bekommen.
Erin Stellato beschreibt eine Baseline sehr prägnant als "einen Bezugspunkt, von dem aus Veränderungen gemessen werden können". Angenommen, ein Benutzer meldet, dass die Leistung seiner Anwendung oder seines Berichts an diesem Morgen langsamer als normal war. Stimmt das? Und wenn ja, was hat sich geändert? War die Anzahl der Benutzerverbindungen in diesem Zeitraum ungewöhnlich hoch? Gab es ungewöhnliche Muster bei der CPU-, IO- oder Speichernutzung? Oder hat jemand im Betrieb eine Servereinstellung geändert? All diese Fragen sind nur schwer zu beantworten, wenn Sie keine Basiswerte haben, mit denen Sie vergleichen können. Um zu wissen, ob beispielsweise die CPU-Nutzung in einem bestimmten Zeitraum ungewöhnlich war, müssen Sie wissen, wie "normal" aussieht. Mit anderen Worten: Sie müssen irgendwo eine Basismessung der CPU-Nutzung über einen vergleichbaren Zeitraum unter Ihrer normalen Serverauslastung gespeichert haben.
Wir können Baselines für eine ganze Reihe von Leistungskennzahlen sowie für andere Bedingungen erfassen. Zum Beispiel könnten wir regelmäßige Basislinienmessungen durchführen für:
sys.dm_os_performance_counters gespeichert sind, in regelmäßigen, bekannten Abständen, so dass wir die Werte verschiedener Zählerwerte über verschiedene Zeiträume hinweg vergleichen können.sys.dm_os_wait_stats DMV täglich, um nach Änderungen bei den häufigsten Gründen zu suchen, warum SQL Server-Sitzungen warten mussten, bevor sie Zugriff auf eine Ressource erhieltensys.database_files oder sys.master_files oder dem DMV sys.dm_db_file_space_usage (SQL 2012 und später) erfassen.sys.configurations) sowie die Werte der Datenbank (sys.databases) und der Servereigenschaften (serverproperty), damit wir genau feststellen können, wann Konfigurationsänderungen aufgetreten sind, und diese mit Veränderungen im Verhalten oder in der Leistung in Beziehung setzen können.Zur einfachen Veranschaulichung betrachten wir die folgenden zwei "Schnappschüsse" der Wartestatistiken für eine SQL Server-Instanz, die jeweils durch Abfrage der DMV sys.dm_os_wait_stats gewonnen wurden (die Statistiken wurden am Ende jedes Tages gelöscht).
Abbildung 1 - Ergebnisse der Abfrage der sys.dm_os_wait_stats DMV
Betrachtet man einen der beiden "Schnappschüsse" isoliert, könnten einige der Wartetypen, die wir sehen, beunruhigend sein, aber wir haben keine Möglichkeit zu wissen, ob dies für diesen Server abnormal ist. Nur wenn wir die beiden Schnappschüsse miteinander vergleichen, können wir klar erkennen, dass an Tag 2 eine anormale Aktivität stattfand. Viele der gleichen Wartetypen tauchen in beiden Snapshots auf, aber alle Wartezeiten sind an Tag 2 höher, und insbesondere diejenigen, die mit E/A-Latenzen zusammenhängen, wie WRITELOG, ASYNC_IO_COMPLETION, und die mit der Sicherung zusammenhängenden Wartezeiten sind deutlich erhöht.
Der DBA sollte die geplanten Sicherungsaufträge überprüfen und herausfinden, welche Sicherung in diesem Zeitraum lief und warum sie längere Wartezeiten als normal verursachte. Es wäre auch sinnvoll, die E/A-Leistung des Sicherungsortes auf der Festplatte zu untersuchen. In diesem Fall war eine regelmäßige, geplante Sicherung aufgrund eines umfangreichen Datenimports plötzlich sehr groß geworden.
Das ist das Wesentliche an Baselines. Durch das Sammeln von Basisdaten für die Leistung und andere Metriken können wir Trends im Laufe der Zeit erkennen und nach besorgniserregenden Änderungen in den Verhaltensmustern Ausschau halten. Wir können auch plötzliche Änderungen abbilden, z. B. bei der Einführung eines neuen Codes oder bei Änderungen der Hardwarekonfiguration usw.
Der Anruf unseres angenehm überraschten Benutzers, mit dem wir diese Geschichte begonnen haben, bezog sich auf die verbesserte Leistung einer ERP-Anwendung eines Drittanbieters, für die unsere SQL Server-Instanz die Backend-Datenbankdienste bereitstellte. Der Anbieter ließ nur begrenzte Änderungen zu, aber es war möglich, die Funktionalität der Datenbank zu erweitern, und die Entwickler hatten dies im Laufe der Zeit getan, indem sie dem Backend verschiedene Objekte hinzufügten. Das Betriebsteam hatte bisher wenig Einfluss auf diese Änderungen, und im Laufe der aufeinander folgenden Aktualisierungen hatte sich die Leistung der Datenbank allmählich verschlechtert. Monatelang hatten sich die Benutzer darüber beschwert, dass verschiedene von der ERP-Anwendung ausgeführte Batch-Funktionen sehr lange brauchten, um abgeschlossen zu werden. Wir mussten anfangen, Dinge anders zu machen.
Zunächst einmal mussten wir damit beginnen, die Werte verschiedener wichtiger Leistungskennzahlen regelmäßig zu erfassen, damit wir über Basismessungen verfügten und die Muster der Serverressourcennutzung genauer verfolgen und Spitzen oder gefährliche Trends erkennen konnten.
Auf dieser Grundlage wollten wir bei der nächsten Bereitstellung mit der Entwicklung zusammenarbeiten und versuchen, einige Verbesserungen vorzunehmen.
Die Erfassung von Basisdaten für alle erforderlichen Metriken ist theoretisch einfach. Wir schreiben eine Abfrage, um die entsprechende Systemansicht in regelmäßigen Abständen abzufragen, und geben die Daten zur Analyse und Berichterstellung in eine Tabelle ein. Sicherlich kann zum Beispiel der full scans/sec PerfMon Zählerwert, eine der Metriken, die wir verfolgen wollten, mit einer einfachen Abfrage erfasst werden, und Erin Stellato hat eine Serie auf SQLServerCentral, die zeigt, wie man dies für PerfMon-Daten, Konfigurationseigenschaften, Wartestatistiken und Plattenplatz.
Die Erfassung, Speicherung, Abfrage und Pflege aller erforderlichen Basisdaten ist jedoch mit einem erheblichen Verwaltungsaufwand verbunden. Wir müssen uns überlegen, wie oft wir die einzelnen Messgrößen erfassen, wie lange wir die Basisdaten aufbewahren und dann Jobs einrichten, um die Daten zu löschen, wenn sie nicht mehr nützlich sind. Wir können uns dafür entscheiden, Jobs einzurichten, um die Daten in DMVs, die aggregierte Daten speichern, regelmäßig zu löschen, so dass wir immer Basisdaten vergleichen, die über denselben Zeitraum erfasst wurden (z. B. einen Tag, wenn wir die Daten der DMVs für Wartestatistiken z. B. jede Nacht löschen)
Wir müssen auch die Abfragen entwickeln und pflegen, um nützliche Berichte über diese Daten zu erstellen, z. B. um die Werte für eine Reihe von Metriken über einen bestimmten Zeitraum von Tagen, Wochen oder Monaten zu vergleichen, damit wir nach Trends oder plötzlichen Verhaltensänderungen suchen können.
Einer der Vorzüge von Redgate Monitor ist, dass es automatisch eine große Anzahl dieser nützlichen Leistungsdaten erfasst. So wird z. B. die CPU-Auslastung erfasst, und dies ergab eine Reihe von CPU-Spitzen in der Produktionsdatenbank, von denen eine in Abbildung 2 zu sehen ist.
Abbildung 2 - ein Anstieg der CPU-Nutzung
Als wir die Abfragen untersuchten, die um diese CPU-Spitze herum liefen, stellte sich heraus, dass sie durch einen geplanten Job verursacht wurde, der einen Kundenverkaufsbericht erstellte, der eine skalare Funktion namens dbo.udfProperCase aufrief, um Kundennamen richtig zu schreiben. Diese UDF wurde jedoch auch im Laufe des Tages jedes Mal aufgerufen, wenn ein Vertriebsmitarbeiter den Bericht ad hoc ausführte.
Um dieses Verhalten mit früheren geplanten Ausführungen dieses Berichts zu vergleichen, haben wir die Schaltfläche Basislinie vergleichen verwendet, um dem Diagramm einen zweiten Satz von Werten für dieselbe Kennzahl über den vorangegangenen 24-Stunden-Zeitraum hinzuzufügen und so eine Basislinie für den Vergleich zu erhalten. Diese Basislinie wurde dann um eine bestimmte Anzahl früherer Zeiträume erweitert. Da wir beispielsweise ursprünglich einen 24-Stunden-Zeitbereich verglichen haben, wurde die Basislinie um 7 Zeitbereiche erweitert und dem Diagramm der gleiche 24-Stunden-Bereich für die letzten 7 Tage hinzugefügt.
Abbildung 3 - CPU-Nutzungsspitzen, zusammen mit einer Basislinie, die die erwartete CPU-Nutzung zeigt
Um ein noch deutlicheres Bild zu erhalten, können wir gemittelte Regionen für die Grundlinien anzeigen, indem wir einfach auf die Schaltfläche Regionen oben im Diagramm klicken. Redgate Monitor zeigt immer noch die aktuellen Daten als Linie an, wobei der Rest der Daten gemittelt wurde. Dabei wurde die Löß-Glättung angewandt und der Bereich zwischen dem 1. und 3. Quartil (die Werte im mittleren Bereich) dunkelblau und der Bereich zwischen dem 0. und 1. und dem 3. und 4. Quartil (die Werte im unteren und oberen Bereich) heller blau schattiert.
Abbildung 4 - CPU-Nutzungsspitzen in der Basisregion
Wir können sehen, dass die CPU-Spitze gegen 7 Uhr morgens völlig normal ist und jedes Mal auftritt, wenn der Bericht ausgeführt wird. Es ist bekannt, dass Skalar-Funktionen viele Leistungsprobleme verursachen, und es sah so aus, als ob eine davon auch hier Probleme verursachen könnte.
Dies war nicht das einzige Problem, das wir gefunden haben. Wir sahen auch wiederholte Spitzen in der full scans/sec-Metrik.
Abbildung 5 - Spikes und Basislinien für volle Scans/Sek.
Bei der Untersuchung dieser Daten korrelierten die DBAs die Leistungsmetriken mit einer Reihe von Abfragewarnungen mit niedriger Priorität, die lange laufen. Diese Alarme wurden immer dann ausgelöst, wenn eine Abfrage mehr als 1 Minute dauerte. Eine genauere Untersuchung dieser Abfragen zeigte, dass sie häufig vollständige Tabellendurchsuchungen großer Tabellen mit mehreren Millionen Zeilen erforderten, obwohl die endgültige Ergebnismenge nur Dutzende von Zeilen enthielt.
Abbildung 6 - eine Reihe von lang andauernden Abfragewarnungen
Es stellte sich heraus, dass viele der Abfragen, die diese Warnungen auslösten, Datumsparameter verwendeten, um die abgerufenen Daten einzuschränken, aber keine der Datumsspalten in den Tabellen indiziert waren.
Wir schlugen dem Entwicklungsteam vor, dass das Betriebsteam bei der Entwicklung der nächsten Runde von vorgeschlagenen Datenbankänderungen mit ihnen zusammenarbeitet und dass wir unsere erste Bereitstellung im DevOps-Stil ausprobieren.
Basierend auf den Erkenntnissen aus unserer Überwachung und den Baselines schlugen wir vor, die vom Verkaufsbericht verwendete UDF zu entfernen. Da nur die ERP-Anwendung die Funktion benötigte, schlugen wir vor, sie in C# neu zu schreiben und in die Anwendung zu verschieben. Diese Änderung war einfach zu bewerkstelligen, auch wenn sie sich auf viele verschiedene Klassen im Code auswirkte. Die ersten Testergebnisse mit der neuen C#-Funktion sahen jedoch vielversprechend aus und zeigten, dass die Umsatzberichte zwischen 200 und 400 % schneller liefen als bei Verwendung der T-SQL-UDF-Funktion.
In einer Reihe von Gesprächen mit dem Third-Level-Support des Anbieters erhielten die Operations-DBAs die Erlaubnis, nicht geclusterte Indizes hinzuzufügen, um die Abfragen, die die Datumsspalte verwendeten, abzudecken, vorausgesetzt, sie könnten im Falle eines Anrufs bei der Supportabteilung des Anbieters leicht aus dem System entfernt werden.
Diese Änderungen wurden der Entwicklungsgruppe vorgelegt, getestet und zusammen mit der Änderung, die UDF für den korrekten Fall zu entfernen, bereitgestellt. Diese Änderungen führten zu einer viel besseren wahrgenommenen Leistung von Seiten der Kunden, was den angenehmen Anruf auslöste, mit dem diese Geschichte begann, und zu nachweisbaren Verbesserungen bei den Mustern der Ressourcennutzung auf unseren Servern.
Nach dem Telefonat und dem Sammeln einiger Daten erstellten wir einen Bericht, der die Auswirkungen verschiedener täglich ausgeführter Verkaufsberichte zeigte. Aus der Sicht der Kunden hatte sich die Arbeitslast nicht nennenswert verändert, aber Abbildung 7 zeigt die dramatischen Unterschiede bei der CPU.
Abbildung 7 - reduzierte CPU-Nutzung, mit Basislinien
Mit unseren neuen Indizes konnten wir auch die Anzahl der Tabellenscans für diese Datenbank erheblich reduzieren.
Das gesamte DevOps-Team war mit den Änderungen zufrieden, da die Kunden zufrieden waren und es weniger Tickets wegen langsamer Leistung gab. Es sind bereits neue Arbeiten im Gange, bei denen dasselbe Verfahren angewandt wird, um sicherzustellen, dass Änderungen problemlos und zeitnah bereitgestellt werden, wobei die Auswirkungen auf die Benutzer auf zwei Arten gemessen werden. Erstens wird die Zufriedenheit mit dem System anhand von Zitaten tatsächlicher Benutzer erfasst und eine Stichprobe von Kommentaren in gemeinsamen Entwicklungs-/Betriebssitzungen vorgelesen.
In einem wissenschaftlicheren und pragmatischeren Sinne ermöglichen die Daten von Redgate Monitor sowohl den Entwicklern als auch dem Betriebspersonal, die Auswirkungen von Änderungen auf das System zu messen. Es werden sowohl allgemeine Leistungskennzahlen als auch benutzerdefinierte Leistungs- und Geschäftszähler erfasst, die objektiv analysieren, ob Änderungen die Leistung fördern oder beeinträchtigen. Es werden keine Eindrücke mehr verwendet, um zu bestimmen, was "normal" oder "langsam" ist.
Darüber hinaus werden Berichte über die Einsätze, die die Leistung vor und nach dem Einsatz zeigen, an jeden Entwickler und Betriebs-DBA verteilt, die sie für ihre halbjährlichen Arbeitsüberprüfungen aufbewahren. Nichts spricht so sehr für eine Gehaltserhöhung wie objektive Daten in einem Bericht von Redgate Monitor.
Für weitere Informationen über Redgate Monitor, eine Demo oder Best Practices nehmen Sie gern Kontakt mit uns auf.
Seit mehr als 25 Jahren entwickelt Redgate spezialisierte Software für Datenbanken. 92 % der Fortune-100-Unternehmen setzen auf unsere Lösungen. Insgesamt vertrauen uns über 200.000 Kunden weltweit.
Redgate bietet eine umfassende Dokumentation und ein kompetentes, engagiertes Support-Team. Im Schnitt bewerten 87 % unserer Kundinnen und Kunden unseren Support mit „Ausgezeichnet“.