Was wäre, wenn Sie sich all die Mühe machen würden, einen neuen SQL Server zu implementieren oder auf einen neuen SQL Server zu aktualisieren, um Ihren Kunden ein besseres Erlebnis zu bieten – und sie sich darüber beschwerten, dass die Dinge tatsächlich schlechter waren?
Würden Sie sich nicht ärgern, wenn Sie all diese geschäftlichen und technischen Hürden überwinden würden, um eine bessere SQL Server-Leistung zu erzielen, und es dann nicht getan haben?
Vielleicht hätten Sie einige SQL Server-Leistungstests durchführen sollen, bevor Sie in die Produktion gegangen sind. Dann hätten Sie gewusst, ob sich Ihre Leistung verbessern, gleich bleiben oder, was am schlimmsten ist, abnehmen würde.
Aber wenigstens wärst du nicht unangenehm überrascht worden.
Die SQL Server-Leistungsbrücke, die wir alle überqueren
Egal, ob Sie von einer anderen Datenbank zu SQL Server wechseln oder von einer älteren Version von SQL Server auf eine neuere aktualisieren, Sie mussten irgendwann die Leistungsbrücke überschreiten.
„Läuft es wirklich besser als vorher?“ Ihr Chef hat gefragt.
„Oh, sicher“, sagtest du. „Mit der Datenvirtualisierung in SQL Server 2019 können wir Abfragen ausführen, ohne Daten zu verschieben oder zu replizieren. Und es gibt automatisches Tuning mit Intelligence Query Processing, um Abfragen zu skalieren. Die Daten werden von den Servern FLIEGEN.“ Sie waren so selbstbewusst, dass Sie „FLY“ großgeschrieben haben.
Wie hätten Sie Ihre Leistung also besser testen können?
4 Möglichkeiten zum Testen der Leistung . . .
Brent Ozar, SQL Server Experte der Extraklasse, erklärt Ihnen, wie Sie die Leistung auf einem neuen SQL Server überprüfen:
- der einfache Weg, Vorher-Nachher-Zeiten auf einem vollständigen Backup und CHECKDB vergleichen
- der einfache, aber falsche Weg, mit einem synthetischen Workload und TPC-C in HammerDB
- der schwierigere Weg, einzelne Abfragen mit sp_BlitzCache, seinem Plan-Cache-Analyseskript, zu testen
- der wirklich harte Weg, dieselben Abfragen auszuführen, die Sie in der Produktion ausführen
Aber wie Brent klarstellt, ist die Überwachung Ihrer SQL-Serverleistung und die Feststellung, dass sie um X Prozent gesunken ist, nur der Anfang; Sie müssen noch herausfinden, woher der Treffer kommt.
Das bedeutet, nach Trends in den Leistungsdaten über ganze Wochen und Monate zu suchen, nicht nur über die letzten paar Stunden.
Je mehr Datenpunkte und Verlauf Sie haben, desto besser können Sie sich ein Bild davon machen, was in, unter und um Ihre SQL Server-Umgebung vor sich geht.
Und je mehr Rechenleistung Sie auf all diese Daten werfen können, desto schneller können Sie sie analysieren.
Leistungsüberwachung von SQL Server:Klingt nach einem Job für die Cloud
Ja. Es ist eine Aufgabe für die Cloud, der einzige Ort, an dem Sie weit genug skalieren können, um all diese Daten zu sammeln und zu analysieren, um ein umfassendes, tiefes Bild davon zu erhalten, wie SQL Server Ressourcen verbraucht. Und wie es diese Ressourcen im Laufe der Zeit verbraucht hat. Zum Beispiel:
- Zu bestimmten Tages- oder Monatszeiten müssen häufig ausgeführte Abfragen von der Festplatte statt aus dem Puffer-Cache lesen, der die In-Memory-Kopie kürzlich verwendeter Datenbankseiten ist. Müssen Sie Ihrem Puffercache mehr Speicher zuweisen? Können Sie dafür noch mehr Speicherplatz erübrigen?
- Gleiches gilt für die Lebenserwartung von Seiten. Wenn es niedrig ist, liegt es wahrscheinlich daran, dass SQL Server zu häufig Seiten aus dem Puffercache entfernt und Suchen aus dem Speicher statt aus dem Arbeitsspeicher ausführen muss. Das beeinträchtigt die Leistung.
- Wird die maximale E/A-Wartezeit zu hoch? Wie ist es im Trend? Das ist ein Hinweis darauf, dass das E/A-Gerät möglicherweise gesättigt ist.
- Wie lang ist die Prozessorwarteschlange jetzt? Wie lange ist es normalerweise? Zu viele ständig wartende Threads können auf eine Prozessorüberlastung hindeuten.
- Läuft die CPU an den Grenzen, die Ihr Server bewältigen kann? Was ist, wenn Sie den Server nicht mehr hochskalieren können? Wenn Sie sicher sind, dass Ihre Abfragen gut abgestimmt sind und Ihre anderen Systemressourcen ausreichend sind, müssen Sie Ihren VMs möglicherweise einen Sockel für physische Hardware oder vCPUs hinzufügen.
- Fragmentierte Indizes sind langsame Indizes, aber Sie wissen nicht, dass sie der Übeltäter sind, bis Sie die Fragmentierungsgrade überprüfen. Die Auswirkungen der Reorganisation und des Wiederaufbaus im Laufe der Zeit zu sehen, kann Ihnen dabei helfen, einen zuverlässigen Indexpflegeprozess einzurichten.
Das Auffinden von Problemen wie diesen in all Ihren lokalen und Cloud-Datenbanken wird einfacher und schneller, wenn Sie die Leistung Ihres SQL-Servers von der Cloud aus überwachen können. Das Beste ist, dass Sie von jedem Ort in der bekannten Galaxie aus überwachen können, wenn sich die gesamte Datenverarbeitung, Speicherung und Analyse in der Cloud befindet und Sie in jedem Browser nur ein paar Klicks entfernt sind.
Beginnen Sie mit dem Testen Ihrer SQL Server-Leistung in der Cloud
Bei Quest muss uns niemand zweimal sagen, dass unsere Kunden Cloud-basierte Tools wollen, sei es für die Cloud-Migration, die Leistungsüberwachung oder Office 365. Wir machen mehr unserer Produkte als Cloud-Angebote verfügbar, weil Technologien und Märkte sie dorthin ziehen.
Wie führen Sie also Leistungstests auf Ihren neuen oder aktualisierten SQL Servern durch?
- Ich führe CHECKDB aus.
- Ich verwende HammerDB.
- Ich verwende die Tools von Brent Ozar.
- Ich teste mit Produktionsworkloads.
- Ich würfele und warte, bis sich die Nutzer beschweren.
- Ich habe Leute, die das für mich tun.
- Ich verwende Spotlight Cloud von Quest. Das sollten Sie auch.
