Warum ist die SQL-Leistungsoptimierung für die Datenbankverwaltung so wichtig?
Weil es Ihnen viel Geld sparen kann. Geduld mit mir und du wirst sehen wie.
SQL-Leistungsoptimierung und Datenbankverwaltung – die Verbindung der Punkte
Die meisten Datenbankprofis verbringen ihre Zeit damit, das Licht anzuschalten. Sie investieren den größten Teil ihrer Bemühungen in die Sicherstellung der Betriebszeit, indem sie Ressourcen wie Speicher, Speicher und Netzwerkdurchsatz im Auge behalten. Das ist ein großer Teil der Datenbankverwaltung, aber je mehr Unternehmen ihre Datenbanken auf nahezu unbegrenzte Cloud-Ressourcen wie AWS und Azure verlagern, desto wichtiger werden andere Aspekte.
Die SQL-Leistungsoptimierung ist einer dieser Aspekte. Sobald die Lichter sicher an bleiben und Sie in der Hierarchie der Anforderungen in der Datenbankverwaltung nach oben steigen, ist das nächste, was Sie wollen, eine bessere Leistung, und das erfordert eine Optimierung.
Erste Fragen zur Leistungsoptimierung in SQL
Viele Datenbankprofis stehen früher oder später vor einem SQL Server, den sie nicht selbst gebaut haben. Es gibt nicht viele Anleitungen für diese Situation. Die SQL-Leistungsoptimierung ist eine Übung, in der Sie sich einarbeiten, herausfinden, was falsch ist, und es dann iterativ beheben.
Bei Ihren ersten Korrekturen berühren Sie SQL-Anweisungen möglicherweise überhaupt nicht. Einige Datenbankprofis beginnen auf Nutzer-/Sitzungsebene. Sie gehen dorthin, wo die Nutzer unzufrieden sind, hören sich ihre Beschwerden an und stellen Fragen.
- Welche Bildschirme oder Seiten brauchen zu lange zum Rendern?
- Ist die Anwendung langsamer, wenn sie ein neues Ticket erstellen oder ein vorhandenes öffnen?
- Dauert es lange, einen Datensatz zu speichern?
- Wie lange ist „eine lange Zeit“?
Sobald sie diese Antworten haben, sehen sie in der Datenbank nach, was sie verursacht.
Das ist besser, als sich am ersten Tag hinzusetzen und zu entscheiden, sich mit etwas wie Fragmentierung zu befassen, die die Nutzer möglicherweise überhaupt nicht betrifft. Der Punkt ist, mit dem zu beginnen, was den Benutzern wichtig ist.
Denken Sie auch an die Instanz-/Datenbankebene. In der Microsoft-Welt sind zum Beispiel SQL Server-Agent-Jobs ein guter Ausgangspunkt. Sie sind eine Reihe von Aktionen, die normalerweise eine Verwaltungsaufgabe definieren, die Sie auf Erfolg oder Misserfolg überwachen können. Sie sollen bequem sein, aber wie viele Dinge in der Datenbankverwaltung neigen sie dazu, sich anzusammeln, wenn die Leute vergessen, wie sie entstanden sind und was sie tun.
Möglicherweise finden Sie mehrere Jobs, die dasselbe tun, z. B. das Ausführen verschiedener Versionen eines Indexskripts oder, noch schlimmer, das Arbeiten gegeneinander. Untersuchen Sie die bereits konfigurierten Jobs im Hinblick auf zwei Fragen:„Was macht dieser Job?“ und, was noch wichtiger ist:„Wenn ich diesen Job beende, wird dann etwas Schlimmes passieren?“
Auf welche Faktoren sollten Sie achten?
Sobald Sie die Ebene der Leistungsoptimierung von SQL erreicht haben, nimmt es seine Hinweise für das Verhalten von mehreren Faktoren. Wie in unserem Webcast „Ask the Experts:Database Performance Roundtable“ beschrieben, können Sie weniger Zeit damit verbringen, die SQL selbst zu optimieren, wenn Sie Faktoren wie die folgenden finden und richtig interpretieren:
- Blockieren – Wenn der Server blockiert, ist das wie eine tickende Zeitbombe. Angenommen, ein Skript startet eine Transaktion und schließt sie nicht; das könnte zu einer Protokolldatei führen, die einfach wächst und wächst, bis der Speicherplatz erschöpft ist. Das Blockieren ist eine schlechte Nachricht für die Leistung, also suchen Sie gleich danach.
- Agenten – Apropos SQL Server Agent-Jobs:Administratoren sind dafür bekannt, leistungsbeeinträchtigende Aufgaben versehentlich in Jobs zu verpacken. Sie können Transaktionen ausführen oder Indexe in einem Job neu erstellen oder die Datenbank in einer Transaktion verkleinern. Ziehen Sie in einem solchen Fall in Erwägung, den Agenten vorübergehend zu deaktivieren, um alle zugehörigen Jobs zu beenden. Es ist eine aggressive Technik, aber wenn sie die Leistung verbessert, wissen Sie warum.
- Wartestatistik – Fragen Sie sich:„Worauf wartet der Server gerade?“ Metriken wie die Lebenserwartung von Seiten und die Länge der Festplattenwarteschlange haben einige Antworten, aber sie bieten nur eine eingeschränkte Sicht. Wartestatistiken zeigen Ihnen alles durch die Linse von Wartetypen und Wartekategorien, sodass Sie sich auf die fünf Warteereignisse konzentrieren können, die die meiste Zeit in Anspruch nehmen. sp_BlitzFirst von Brent Ozar ist eine bewährte gespeicherte Prozedur, mit der Sie herausfinden können, worauf Ihre SQL Server-Abfragen gerade warten. Wenn Sie dann langfristige Muster in den Wartestatistiken für Ihren Server untersuchen möchten, schauen Sie sich ein Leistungsüberwachungstool an.
- Administratoraktivität – Dies wird auch als „Pilotenfehler“ bezeichnet, da einige Leistungsprobleme durch das entstehen, was Sie selbst tun. Angenommen, Sie führen sowohl den SQL Server-Aktivitätsmonitor als auch den SQL Server Profiler gleichzeitig aus und versuchen, den Abfragespeicher zu lernen. Sie können dem Beobachtereffekt nicht entkommen; Wenn Sie alles so verfolgen, bitten Sie nur darum, dass die Datenbank langsamer wird.
- Indizes – Für etwas, das nützlich sein soll, können Indizes Ihnen sicher Kopfschmerzen bereiten. Tatsächlich verdienen sie mehr als nur eine Kugel. Lesen Sie weiter.
SQL-Leistungsoptimierung bedeutet, Indizes genau unter die Lupe zu nehmen
Die SQL-Leistungsoptimierung läuft größtenteils auf die Indexoptimierung hinaus. Wenn Sie dies für die lokale Datenbankverwaltung beherrschen, sind Ihre Fähigkeiten glücklicherweise leicht auf die Datenbankverwaltung in der Cloud übertragbar.
Die Indexoptimierung gewinnt aufgrund der sich entwickelnden Vielfalt von Indizes an Bedeutung:geclusterte, nicht geclusterte, eindeutige, gefilterte, Columnstore-, Hash-, speicheroptimierte, nicht geclusterte, XML-, räumliche und Volltext-Indizes, um nur einige zu nennen. Aber eine Sache, die sich nie geändert hat, ist die erste Spalte des Index, die die von der Datenbank-Engine getroffenen Indexentscheidungen beeinflusst.
Viele Anbieter verkaufen und implementieren Anwendungen mit vielen gut gemeinten Indizes, die am Ende nie verwendet werden oder, noch schlimmer, die Leistung beeinträchtigen. Wenn Sie die ungenutzten Indexskripte oder Indexverbrauchsskripte in einigen Softwareprodukten untersuchen, werden Sie eine Fülle von Indizes auf einem Fremdschlüssel finden. Wenn das Produkt beispielsweise 20 Fremdschlüssel verwendet, können die Anbieter bis zu 20 Indizes liefern, plus zehn Einzelspalten-Indizes, plus weitere zehn Indizes für einen eindeutigen gruppierten Index und so weiter.
Wann immer Sie die Möglichkeit haben, ist die bessere Herangehensweise an die Datenbankarchitektur, mit einem gruppierten Index zu beginnen, von dem Sie glauben, dass er die Tabelle am besten darstellt. Lassen Sie das System dann eine Weile laufen. Wenn Sie weitere Indizes benötigen, erstellen Sie diese. Das Hinzufügen von Indizes ist eine Übung, um hier eine bessere Leistung gegen Probleme wie das Auffüllen von Speicherplatz und das Sperren dort einzutauschen. Es wird schwer zu erkennen, wie sich jeder zusätzliche Index auf das System insgesamt auswirkt.
Erwägen Sie in diesem Zusammenhang, Indizes zu eliminieren – so wie eine Person mit Allergien Lebensmittelgruppen eliminieren würde – um zu sehen, wie sich die Leistung ändert. Versuchen Sie, jeden Index auf Ihrer Entwicklungsinstanz zu löschen und zu sehen, welche sich auf Ihre fünf wichtigsten Abfragen auswirken.
Leistungsoptimierung in SQL Server – mitgelieferte Tools
Beachten Sie, dass Sie bei diesem Unterfangen nicht allein sind. SQL Server enthält Funktionen zur Verbesserung der Leistung.
Mit Planhinweislisten können Sie ändern, wie SQL Server eine bestimmte Abfrage ausführt, und obwohl es sich nicht um eine reine SQL-Leistungsoptimierung handelt, wirkt sich dies auf die Leistung aus. Viele Anwendungen enthalten SQL-Abfragen, die von einem externen Anbieter geschrieben wurden, und selbst wenn diese Abfragen zu einer schlechten Leistung führen, zögern einige Datenbankexperten verständlicherweise, sie zu ändern. Mit Planhinweislisten können Sie einen Abfragehinweis oder einen festen Plan an die Abfrage anhängen und deren Ausführung beeinflussen.
Der Nachteil von Planleitfäden besteht jedoch darin, dass sie sich im Laufe der Zeit zwar nicht ändern, die Umgebung um sie herum jedoch. Wie eine gedruckte Roadmap können sie kurzfristig gut funktionieren und bald veraltet sein. Wenn Sie sich also auf sie verlassen wollen, sollten Sie sie besser gelegentlich überdenken.
Im Zusammenhang mit Planleitfäden steht der Abfragespeicher, eine Funktion von SQL Server, mit der Sie die Abfragen identifizieren und optimieren können, die die meisten Ressourcen in Ihrem System verbrauchen. Der Abfragespeicher ist für neue SQL Server- und Azure Synapse Analytics (SQL DW)-Datenbanken nicht standardmäßig aktiviert. In neuen Azure SQL-Datenbanken ist es jedoch standardmäßig aktiviert.
Generell ist es nicht schwierig, den Query Store zu aktivieren, aber nicht jeder SQL Server benötigt ihn von Anfang an. Manche Admins kennen den Query Store nicht, andere kennen ihn, haben sich aber noch nicht die Zeit genommen, ihn angemessen zu erkunden; Sie sind besser dran, es deaktiviert zu lassen. Später, wenn sie verstehen, wie der Abfragespeicher funktioniert, können sie ihn verwenden, um Leistungsunterschiede zu finden, die durch Änderungen des Abfrageplans verursacht wurden.
Schließlich analysiert der Database Engine Tuning Advisor Arbeitslasten und empfiehlt Indizes oder Partitionierungsstrategien, um die Abfrageleistung zu verbessern. Es ist eine gute Idee, Tuning Advisor auf Ihrer Datenbank auszuführen; lass es einfach nicht zu früh laufen. Stellen Sie sicher, dass Ihre Datenbank genügend Daten enthält, damit die Indexempfehlungen gültig sind. Wenn Sie Ihre Anwendung zum ersten Mal erstellen, haben Sie möglicherweise nur tausend Zeilen in jeder Tabelle. Die Empfehlungen von Tuning Advisor sind nützlicher, sobald die Datenbank gewachsen ist.
Zeig mir das Geld
Wie ich eingangs erwähnt habe, ist die SQL-Leistungsoptimierung für das Datenbankmanagement wichtig, weil Sie damit Geld sparen können. Wie?
Insbesondere in der Cloud, wo die Skalierung per Kreditkarte beliebt ist, finden IT-Teams heraus, wie teuer monatlicher Speicherplatz wirklich sein kann. Darüber hinaus beginnen sie zu verstehen, dass die Ausführung schlecht geschriebener Abfragen und die Verwaltung ihrer Indizes durch AWS und Azure ihre Cloud-Computing-Kosten erhöhen. Langsame Abfragen und schlechte Indizes kosten Geld.
Bei der SQL-Leistungsoptimierung geht es darum, all diese Dinge richtig zu machen. Auf diese Weise behalten Sie die Kontrolle über Ihre Ausgaben, egal ob Sie in der Welt der On-Premises-OpEx bleiben oder in die CapEx-Welt der Cloud migrieren.
