2016-05-05 5 views
-1

Im Dezember 2015 habe ich eine kleine azurblaue Webanwendung (Webapi, 1 Controller, 2 REST-Endpunkte) zusammen mit einer Azure SQL-Datenbank (1 Tabelle, 1,7 Mio. Zeilen, 3 gespeicherte Prozeduren) bereitgestellt.Was hat sich bei Azure geändert, um meinen SQL-Sproc auf einen Crawl zu verlangsamen?

Ich konnte meine Ruheendpunkte aufrufen und Daten innerhalb weniger Sekunden zurückbekommen. Glückliche Tage.

Jetzt mache ich den gleichen Anruf und meine App löst einen 500 Fehler. Eine nähere Untersuchung zeigt, dass der SQL-Zugriff abgelaufen ist.

Ich kann die db (mit Visual Studio Data Tools) öffnen und die Abfragen ausführen und die gespeicherten Prozeduren aufrufen. Für meine Haupt-Sproc-Ausführung beträgt die Zeit ungefähr 50 Sekunden - viel zu lange, bis die App wartet.

Die Daten in der Tabelle haben sich seit der Bereitstellung nicht geändert, und die App und db wurden in den letzten Monaten nicht geändert. Wie kommt es, dass es im Dezember OK lief, aber jetzt kläglich versagt?

Alle Hilfe sehr geschätzt.

+0

Statistiken veraltet? Gonna muss einige weitere Leistungsdetails auf dem Sproc bereitstellen (was tut es, Einfügungen, temporäre Tabellen, etc.) –

+0

Parameter Schnüffeln verursacht nicht optimalen Plan, um den besseren Plan zu ersetzen? Ohne Details ist es nicht möglich zu erraten, was passiert ist. –

+0

könnte es wert sein, die Antwort hier zu versuchen? http: // Stapelüberlauf.com/questions/35934009/azure-sql-abfrage-ist-langsam-wenn-eine-indizierte-spalte-used-in-where-satz-hat-a-partic/35935703 # 35935703 –

Antwort

0

Der Abfragespeicher ist in SQL Server 2016 und Azure SQL-Datenbank verfügbar. Es ist eine Art "Flugschreiber", der eine Historie von Abfrageausführungen aufzeichnet.

Sein Zweck ist es, festzustellen, was schief gelaufen ist, wenn ein Abfrageausführungsplan plötzlich langsam wird. Im Gegensatz zu DMVs werden die Daten des Abfragespeichers in Tabellen beibehalten, sodass sie beim Neustart von SQL Server nicht verloren gehen und monatelang beibehalten werden können.

Es hat vier Berichte in SSMS. Dieses Bild zeigt die häufigsten Ressourcen verbrauchenden Abfragen. Im oberen linken Bereich wird ein Balkendiagramm angezeigt, in dem jeder Balken eine Abfrage darstellt, geordnet nach absteigender Ressourcennutzung.

Sie können eine bestimmte Abfrage von Interesse auswählen, dann zeigt das obere rechte Fenster eine Zeitleiste mit Punkten für jede Ausführung. In diesem Beispiel können Sie sehen, dass die Abfrage viel schlechter geworden ist, da der zweite Punkt eine viel höhere Ressourcenauslastung anzeigt. (Tatsächlich erzwang ich dies, indem ich absichtlich einen Deckungsindex fallen ließ.)

Dann können Sie auf einen bestimmten Punkt klicken und der grafische Ausführungsplan wird im unteren Fenster angezeigt. In diesem Beispiel kann ich die beiden Pläne vergleichen, um zu sehen, was sich geändert hat. Der grafische Ausführungsplan sagt mir, dass ein Index fehlt (diese Funktion selbst ist nicht neu), und wenn ich auf den vorherigen Punkt geklickt hätte, würde diese Nachricht nicht erscheinen. Das ist ein ziemlich guter Hinweis darauf, was falsch gelaufen ist!

enter image description here

Der regressiert Abfragen Bericht hat das gleiche Format, aber es zeigt nur Abfragen, die „regrediert“ haben oder noch schlimmer. So ist es ideal für die Fehlersuche.

Ich weiß, dass dies Ihre derzeitige Situation nicht löst, es sei denn, Sie haben Query Store aktiviert. Es könnte jedoch für die Zukunft und für andere Menschen, die dies lesen, sehr nützlich sein.

Siehe MSDN> Leistungsbewertung durch den Speicher-Abfrage verwenden: https://msdn.microsoft.com/en-GB/library/dn817826.aspx

+0

Ich habe dies als die Antwort akzeptiert, obwohl ich verspätete, um den vollen Nutzen daraus zu ziehen. Der Abfrageshop zeigte mir jedoch, dass meine benutzerdefinierte Funktion OK war, aber der Sproc, der sie anrief, machte unnötige Arbeit. Dank dem, was ich hier gelernt habe, konnte ich meinen Sproc optimieren. Vielen Dank. –

Verwandte Themen