So kann eine effektive Überwachung von SQL-Abfragen Blockaden verhindern
1/8/2024
Tomasz Chwasewicz
In einem komplexen SQL Server-Ökosystem können Leistungsprobleme manchmal einer Detektivarbeit ähneln, insbesondere wenn es darum geht, die schwer fassbaren Schuldigen von Systemabstürzen ausfindig zu machen. Dieses Mal werden wir untersuchen, wie ineffiziente Abfragen (und eine schlecht durchgeführte Abfrageüberwachung) Betriebsabläufe zum Erliegen bringen können. Wir werden auch das „Wie“ und „Warum“ hinter dem Stopp herausfinden und Ihnen zeigen, wie eine effektive Überwachung von SQL-Abfragen Blockaden verhindern kann.
Von der Analyse von Lasttrends über die Analyse von Absturzverläufen bis hin zur Verfeinerung von Ausführungsplänen stellen wir sicher, dass kein Stein — oder besser gesagt, kein Datenblock — auf dem anderen bleibt, um SQL Server schnell wie ein Sportwagen und nicht wie ein riesiges Maultier am Laufen zu halten.
Bildschirm „Trends laden“ DBPLUS Performance Monitor ist ein Ort, der für jeden etwas bietet, der SQL-Abfragen auf den Grund gehen möchte. Dies ist ein gründlicher Überblick über die Leistungsstatistiken für SQL Server-Instanzabfragen. Wir gruppieren die Statistiken vom 4. bis 11. April nach Stunden und konzentrieren uns zunächst auf die CPU-Auslastung der ausgeführten Abfragen. Der Grund für das Drama, das unser Kunde miterlebte, waren schwerwiegende Blockierungsvorfälle:
Um der Sache auf den Grund zu gehen und SQL-Abfragen zu überwachen, besuchten wir den Tab „Blockverlauf“. Er dient als unsere Zeitmaschine und bietet Einblicke in Scharmützel mit Blockaden. Hier wird jede Art von Blockade aus einzelnen Tagen ihren Moment unter die Lupe genommen. Ein anschauliches interaktives Diagramm zeigt die Höhen und Tiefen des Datenbankdramas. Es zeigt uns die Anzahl der Sperr- und Wartesitzungen sowie deren Dauer.
Ein einfacher Klick auf das Diagramm zeigt die Schuldigen der einzelnen Blockaden. Trennt Initiatoren (blockierende Sitzungen) von Opfern (wartende Sitzungen).
Interessanterweise ergab unsere Untersuchung einen berüchtigten Täter. Dieselbe Sitzung mit unterschiedlichen Nummern wurde auf frischer Tat ertappt, als sie die Abfrage, die die Sperren ausgelöst hatte, konsequent ausführte.
Wenn wir den Bildschirm mit den SQL-Details besuchen, können wir die Possen der Abfrage vom 11. bis 20. April verfolgen und feststellen, dass es sich um ein Performance-Chamäleon handelt. Am 11. April wurde beschlossen, den Ausführungsplan auszuprobieren, der, gelinde gesagt, keine Eile hatte. Seine Hinrichtung wurde jedes Mal fortgesetzt. Dieses langsame Tempo war im Vergleich zu seinen späteren Auftritten eine ziemlich gute Show.
An helleren Tagen entschied sich unsere Anfrage für einen schnelleren Ausführungsplan. Sie durchlief die Daten mit einer fünfmal schnelleren Geschwindigkeit. Diese Änderung des Tempos zeigt nicht nur, dass die Abfrage ihre Balken ändern kann. Es zeigt auch, welche dramatischen Auswirkungen die Wahl des richtigen Plans hat.
Der Vergleich der beiden Ausführungspläne verdeutlichte den weiteren Weg: das Hinzufügen eines Indexes zur Produkt-ID-Spalte. Dieser Fix erwies sich als Hit, da er die Abfragegeschwindigkeit erhöhte und die lästigen Blockierungsprobleme beseitigte. Dies war ein klassischer Fall von strategischer Indexierung, bei der Muskeln gespielt wurden, um die Leistung von SQL Server zu steigern.
Diese Episode unterstreicht die Bedeutung einer wachsamen Überwachung und zeitnaher Korrekturen — Kennzeichen von DB Plus Performance Monitor. Solche Tools sind unerlässlich, um Leistungsengpässe zu erkennen und zu beheben und sicherzustellen, dass SQL Server wie eine gut geölte Maschine läuft.
