none
Anfrage daueren wesentlich länger RRS feed

  • 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.

    Donnerstag, 3. September 2020 08:06

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.



    Freitag, 4. September 2020 19:08
  • 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-ver15

    Query 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.

    Dienstag, 8. September 2020 13:48

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-ver15

    Je 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

    Donnerstag, 3. September 2020 08:16
  • Hallo,

    vielen Dank für die schnellen Antwort.

    Könnte darin der Grund liegen für der radikalen Anstieg der Anfragezeit?

    Müsste das dann nicht eher schleichend stattfinden?

    Wir setzen in jedem Fall deinen Ansatz um. Danke!

    Viele Grüße

    Wolfgang

    Donnerstag, 3. September 2020 08:31
  • 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%.

    Donnerstag, 3. September 2020 08:52
  • 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.



    Freitag, 4. September 2020 19:08
  • @Joerg_x

    Hallo Joerg, klar die Abfrage ist nur ein  Beispiel zu verstehen. Leider bestehen die Probleme weiterhin und wir versuchen irgendwie eine Fährte zu finden, die uns zu einer Lösung bringt.

    Vielen Dank

    Wolfgang

    Dienstag, 8. September 2020 13: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-ver15

    Query 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.

    Dienstag, 8. September 2020 13:48