none
Gespeicherte Prozeduren nach Statistik-Aktualisierung immer langsam RRS feed

  • Frage

  • Guten Tag zusammen !

    System betrifft bei meiner Frage den SQL Server 2012 mit aktuellstem Update-Stand.
    Es wurde eine Statistik-Aktualisierung mit Fullscan über einen Wartungsplan ausgeführt.
    Ergebnis: Abfragen über benutzerdefinierte gespeicherte Prozeduren wurden um bis zu 10 Sekunden langsamer als mit uralten Statistiken. Leider nicht nur beim ersten Aufruf, sondern immer. Ersichtlich war das es auch völlig andere Ausführungspläne waren die verarbeitet wurden. Ich habe verschiedene Dinge wie: Neustart, Caches gelöscht, sp_recompile und drop mit recreate für die Prozeduren ausprobiert, aber das hat alles nichts gebracht.
    Was kann hier die Ursache sein und wie geht Ihr mit solch einem Problem um, bzw. ist dies ein häufiges Problem ?

    Freue mich auf eine Antwort und weitere Fragen ;-)
    Vielen Dank und viele Grüße !

    Samstag, 18. April 2015 17:40

Alle Antworten

  • Hallo,

    die Aussagen sind etwas wage, von daher kann ich da auch nichts konkretes zu sagen. Die beste Herangehensweise ist z.B. auf Missing Indexes zu prüfen, vielleicht sind die derzeitigen nicht optimal: Missing indexes with CREATE statement for it

    Dann sollte man auf jeden Fall die Ausführungspläne sichten, welche Indizes dort verwendet warden oder eben nicht. Wenn es die Möglichkeit gibt und es für Dich erlaubt ist, könntest Du einen solchen mal als XML bereit stellen (z.B. auf OneDrive), damit wir ihn uns mal ansehen können.

    Wenn in den Stored Procedures viel mit berechneten Variable für Filter gearbeitet wird, könnte das Problem am "Parameter Sniffing" liegen, das tritt gerne mal auf, siehe
    What is Parameter Sniffing ?
    Parameter Sniffing Problem and Possible Workarounds
    The Elephant and the Mouse, or, Parameter Sniffing in SQL Server

    Im Ausführungsplan gibt es in solchen Fallen meist eine große Differenz zwischen "Estimated Row Count" und "Row Count", darauf sollte man achten.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    Sonntag, 19. April 2015 07:44
  • Hallo Olaf,

    vielen Dank für Deine Antwort. Ich werde mir die Informationen anschauen.
    Wenn es für Dich in Ordnung ist würde ich Dir die Informationen bereitstellen und in einer privaten Nachricht senden. Die Details und die Auflösung stelle ich selbstverständlich dann wieder hier bereit. Wäre das OK ?

    Ich habe Dir mal eine Xing-Anfrage gestellt...

    Im Falle der schnellen Ausführung, vor der "Optimierung" liegen die Werte "Estimated Row Count" und "Row Count" weit auseinander. Im Falle der langsamen Ausführung liegen die Werte ""Estimated Row Count" und "Row Count" ganz nahe beieinander. Somit kommt es zu 2 ganz verschiedenen Ausführungsplänen.

    Sonntag, 19. April 2015 09:13
  • Hallo Matthias,

    lag vorher der "Estimated Row Count" (weit) unterhalb von "Row Count", ich vermute es mal? Dann kann es jetzt sein, das nun der Tipping Point überschritten ist und manche Indizes deshalb nicht mehr verwendet werden => http://www.sqlskills.com/blogs/kimberly/category/the-tipping-point/

    Da wäre eben die Ausführungspläne hilfreich.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Sonntag, 26. April 2015 05:13