Benutzer mit den meisten Antworten
Anfrage daueren wesentlich länger

Frage
-
Guten Tag,
wir haben seit dem Wochenende mit unserm SQL-Server ein großes Problem.
Anfragen die mit anderen Tabellen verjoint worden sind, laufen seitdem erheblich langsamer. Als Beispiel gibt es ein Query das vor dem Sonntag (bzw. seit Montag 31.08.) ungefähr einen Abfragedauer von ca. 2 Sekunden gebraucht hat. Gestern hat die gleiche Query 43 Sekunden benötigt.
Der SQL-Server ist auf WIN Server 2016 installiert. Alle aktuellen Updates sowohl für den SQL-Server als auch für den Windowsserver sind installiert. Weder im Windows Eventviewer noch im den Server-Logs haben wir Fehlermeldungen gefunden.
In den Logs die wir mitschreiben lassen können wir nachvollziehen das SQL- Stored Proceduen die täglich laufen vor Montag in ca. 2 Min abgearbeitet wurden nun bis zu 13 Minuten brauchen.
Beim Nachvollziehen der Schritte konnten wir feststellen das bei Abfragen mit Join's die erheblichen Zeitverluste auftraten bzw auftreten.
MS-SQL Server Standard(64-bit)
WIN Server 2016 Standard (10.0)
Version 14.0.3335.7
Arbeitsspeicher 391874 MB
Prozessoren 12
Weder in der Auslastung der CPU'S noch beim SQL-Server konnten wir hohe Auslastungen erkennen.
die SP sp_updatestate wurde ebenfalls durchgeführt ohne eine erkennbare Verbesserung.
Die Erneuerung der Indizes wurde ebenfalls durchgeführt ohne Erfolg.
Auf die PrüfungDBCC CHECKDB war ohne Verbesserung.
Die oben beschriebe Symtomatik können wir bei vielen System nachvollziehen die sich Daten vom SQL-Server laden wollen.
Hier kommt es immer wieder zu Timeouts. LAN Problem ziehen wir nicht in Betracht. SP werden zwar über LAN gestärtet, laufen aber innerhalb des SQL-Servers.
Die Abfragen die heriverwendet sind vom auf Aufbau gleich
SELECT t1.id ,t1.artNr ,t1.artBez ,t1.artZugangDate ,t1.aktiv ,t2.verkauftQty ,t2.verkauftDate ,t2.verkauftRegionId from artikel as t1 left join artikelVerkauf on t1.artNr = t2.artNr where t1.artNr between 5000 and 6000 and t1.aktiv = 1 and t2.verkaufRegionID in (10,12,13)
Laufzeit vorher ca. 3 Sekunden - Laufzeit jetzt 45 Sekunden
Wir haben versucht nach zu vollziehen was sich von Sonntag auf Montag geändert hat. HAben aber keinerlei Ansatz gefunden.
es wurden weder neu Anwendungen noch weitere neu Aufgaben hinzugefügt.
Vielleicht weiß jemand wo wir ansetzen könnten.
Vielen Dank im Voraus für die Hilfe.
Wolfgang
PS: Grundsätzliche Dinge wie Platz auf dem Datenträger, Größe der DB, RAM usw. haben wir geprüft.
Antworten
-
Hallo Wolfgang,
in Deiner Beispielabfrage fehlt bei der gejointen Tabelle der Alias t2
Ich nehme an, dies ist nicht die Ursache vom Problem, sondern nur ein Schreibfehler beim Übertragen.
Sind das eigentlich statische Werte in den Bedingungen? Oder werden die zur Laufzeit eingefügt?
Ich würde es auch mal mit RECOMPILE versuchen, ansonsten auch mal Deine Beispielabfrage modifizieren (Filter ändern oder entfernen, TOP x) etc. und schauen, ob sich etwas verändert.
Auch den Datenbankoptimierungsratgeber würde ich mal ausprobieren.
Im SSMS gibt es übrigens die Möglichkeit den Ausführungsplan der Abfrage anzuzeigen. Da kann man sehr gut sehen wo "getrödelt" wird. Die Experten können das auch analysieren, und Dir damit häufig das Problem benennen und eine Lösung vorschlagen.
Schönen Abend.
- Bearbeitet Joerg_x Freitag, 4. September 2020 19:09
- Als Antwort vorgeschlagen Ivan DragovMicrosoft contingent staff, Moderator Freitag, 11. September 2020 14:03
- Als Antwort markiert Ivan DragovMicrosoft contingent staff, Moderator Freitag, 18. September 2020 12:03
-
Schon mal mit diesem Thema beschäftigt?
https://docs.microsoft.com/de-de/sql/relational-databases/performance/analyze-an-actual-execution-plan?view=sql-server-ver15Query Optimierungen war schon immer eine Wissenschaft für sich. Was bei geringen Datenmengen nicht auffällt kann bei steigenden Datenmengen zu einem Problem werden.
Warum auch optimieren, die Abfrage dauert heute doch sowieso nur 0,2 Sekunden. In wenigen Jahren kann sich das aber je nach Datenvolumen auch schnell zu 20 Sekunden vervielfältigen.- Als Antwort vorgeschlagen Ivan DragovMicrosoft contingent staff, Moderator Freitag, 11. September 2020 14:03
- Als Antwort markiert Ivan DragovMicrosoft contingent staff, Moderator Freitag, 18. September 2020 12:02
Alle Antworten
-
Ggf. sind vorhandene Index-Statistiken nicht mehr aktualisiert worden.
https://docs.microsoft.com/de-de/sql/relational-databases/maintenance-plans/update-statistics-task-maintenance-plan?view=sql-server-ver15Je mehr Daten in die DB kommen, desto wichtiger werden Indizes und deren Statistiken.
Über diese ermittelt der Optimizer die beste Zugriffsstrategie.
Doch je mehr Daten in den Tabellen stehen, desto kritischer wird dies.https://www.zuehlke.com/de/insights/sql-server-performance-optimierung#
Siehe dort nach:
SET STATISTICS IO ON
SET STATISTICS TIME ON -
-
Das kann schon mal von heute auf morgen passieren, da der Optimizer statistische Grenzwerte verwendet um in Abhängigkeit der Anzahl Zeilen einer DB dann schon mal seine Strategie zu ändern.
Ich kenne das auch von anderen DBM's (DB2, Firebird, Oracle), die bis zu einem Punkt schnelle Abfragen durchführen und dann plötzlich langsamer werden.Ein weiterer Grund kann dann auch durchaus der verfügbare Hauptspiecher sein. Je mehr verfügbar ist, desto besser. Hier passiert ständig ein Verdrängungswettbewerb. Kleine und häufig gebrauchte Tabellen können schon mal komplett im Speicher liegen, da interessieren Indizes nicht. Hier werden eher Hashtables o.ä. verwendet.
Erst bei größeren Tabellen sind Indizes für das schnelle finden und laden erforderlich.
Dabei muss man auch seine Abfragen ins besonders bei Joins erst mal selber optimieren und ggf. umdrehen, also Join-Folge anpassen.Unsere BI-Lösung z.B. analysiert SQL's, optimiert diese und legt ggf. fehlende Indizes an. Die Trefferquote (also meine Indexstrategie vs. DB-Strategie die ja nicht wirklich offengelegt ist) beträgt ca. 90%.
-
Hallo Wolfgang,
in Deiner Beispielabfrage fehlt bei der gejointen Tabelle der Alias t2
Ich nehme an, dies ist nicht die Ursache vom Problem, sondern nur ein Schreibfehler beim Übertragen.
Sind das eigentlich statische Werte in den Bedingungen? Oder werden die zur Laufzeit eingefügt?
Ich würde es auch mal mit RECOMPILE versuchen, ansonsten auch mal Deine Beispielabfrage modifizieren (Filter ändern oder entfernen, TOP x) etc. und schauen, ob sich etwas verändert.
Auch den Datenbankoptimierungsratgeber würde ich mal ausprobieren.
Im SSMS gibt es übrigens die Möglichkeit den Ausführungsplan der Abfrage anzuzeigen. Da kann man sehr gut sehen wo "getrödelt" wird. Die Experten können das auch analysieren, und Dir damit häufig das Problem benennen und eine Lösung vorschlagen.
Schönen Abend.
- Bearbeitet Joerg_x Freitag, 4. September 2020 19:09
- Als Antwort vorgeschlagen Ivan DragovMicrosoft contingent staff, Moderator Freitag, 11. September 2020 14:03
- Als Antwort markiert Ivan DragovMicrosoft contingent staff, Moderator Freitag, 18. September 2020 12:03
-
Schon mal mit diesem Thema beschäftigt?
https://docs.microsoft.com/de-de/sql/relational-databases/performance/analyze-an-actual-execution-plan?view=sql-server-ver15Query Optimierungen war schon immer eine Wissenschaft für sich. Was bei geringen Datenmengen nicht auffällt kann bei steigenden Datenmengen zu einem Problem werden.
Warum auch optimieren, die Abfrage dauert heute doch sowieso nur 0,2 Sekunden. In wenigen Jahren kann sich das aber je nach Datenvolumen auch schnell zu 20 Sekunden vervielfältigen.- Als Antwort vorgeschlagen Ivan DragovMicrosoft contingent staff, Moderator Freitag, 11. September 2020 14:03
- Als Antwort markiert Ivan DragovMicrosoft contingent staff, Moderator Freitag, 18. September 2020 12:02