Bei der Abfrage tritt in der Web-App eine Zeitüberschreitung auf, in Management Studio läuft sie jedoch einwandfrei

StackOverflow https://stackoverflow.com/questions/9974

  •  08-06-2019
  •  | 
  •  

Frage

Dies ist eine Frage, die ich in einem anderen Forum gestellt habe und auf die einige gute Antworten erhalten wurden, aber ich wollte sehen, ob hier jemand mehr Einblick hat.

Das Problem besteht darin, dass eine Ihrer Seiten in einer Webanwendung eine Zeitüberschreitung aufweist, wenn sie zu einem Aufruf einer gespeicherten Prozedur gelangt. Daher verwenden Sie SQL Profiler oder Ihre Anwendungsablaufverfolgungsprotokolle, um die Abfrage zu finden, und fügen sie zur Berechnung in Management Studio ein Unser Grund, warum es langsam läuft.Aber wenn man es von dort aus startet, läuft es einfach weiter und kehrt jedes Mal in weniger als einer Sekunde zurück.

Mein spezieller Fall war die Verwendung von ASP.NET 2.0 und SQL Server 2005, aber ich denke, das Problem könnte auf jedes RDBMS-System zutreffen.

War es hilfreich?

Lösung

Das ist es, was ich bisher aus meiner Forschung gelernt habe.

.NET sendet Verbindungseinstellungen, die nicht mit denen übereinstimmen, die Sie erhalten, wenn Sie sich bei Management Studio anmelden.Folgendes sehen Sie, wenn Sie die Verbindung mit Sql Profiler schnüffeln:

-- network protocol: TCP/IP  
set quoted_identifier off  
set arithabort off  
set numeric_roundabort off  
set ansi_warnings on  
set ansi_padding on  
set ansi_nulls off  
set concat_null_yields_null on  
set cursor_close_on_commit off  
set implicit_transactions off  
set language us_english  
set dateformat mdy  
set datefirst 7  
set transaction isolation level read committed

Ich füge diese Einstellungen jetzt über jeder Abfrage ein, die ich ausführe, wenn ich beim SQL Server angemeldet bin, um sicherzustellen, dass die Einstellungen gleich sind.

In diesem Fall habe ich jede Einstellung einzeln ausprobiert, nachdem ich die Verbindung getrennt und wieder hergestellt hatte, und festgestellt, dass die Änderung von „arithabort“ von „off“ auf „on“ die Problemabfrage von 90 Sekunden auf 1 Sekunde reduzierte.

Die wahrscheinlichste Erklärung hängt mit dem Parameter-Sniffing zusammen, einer Technik, die SQL Server verwendet, um den seiner Meinung nach effektivsten Abfrageplan auszuwählen.Wenn Sie eine der Verbindungseinstellungen ändern, wählt das Abfrageoptimierungsprogramm möglicherweise einen anderen Plan aus, und in diesem Fall hat es offenbar einen schlechten Plan ausgewählt.

Aber davon bin ich nicht ganz überzeugt.Ich habe versucht, die tatsächlichen Abfragepläne zu vergleichen, nachdem ich diese Einstellung geändert habe, und habe bisher noch keine Änderungen im Diff gesehen.

Gibt es noch etwas anderes an der Arithabort-Einstellung, das in manchen Fällen dazu führen kann, dass eine Abfrage langsam ausgeführt wird?

Die Lösung schien einfach:Fügen Sie einfach „set arithabort on“ oben in die gespeicherte Prozedur ein.Dies könnte jedoch zum gegenteiligen Problem führen:Ändern Sie die Abfrageparameter und plötzlich läuft es mit „Aus“ schneller als mit „Ein“.

Im Moment führe ich die Prozedur „mit Neukompilierung“ aus, um sicherzustellen, dass der Plan jedes Mal neu generiert wird.Für diesen speziellen Bericht ist das in Ordnung, da die Neukompilierung vielleicht eine Sekunde dauert, und das fällt bei einem Bericht, dessen Rückgabe 1–10 Sekunden dauert, nicht allzu sehr auf (es ist ein Monster).

Für andere Abfragen, die viel häufiger ausgeführt werden und so schnell wie möglich, in nur wenigen Millisekunden, eine Antwort liefern müssen, ist dies jedoch keine Option.

Andere Tipps

Ich hatte ähnliche Probleme.Versuchen Sie, die Option „WITH RECOMPILE“ beim Sproc-Erstellen zu setzen, um das System zu zwingen, den Ausführungsplan bei jedem Aufruf neu zu berechnen.Manchmal gerät der Abfrageprozessor in komplexen gespeicherten Prozeduren mit vielen Verzweigungen oder Case-Anweisungen durcheinander und zieht einfach einen wirklich suboptimalen Ausführungsplan.Wenn das Problem dadurch zu „beheben“ scheint, müssen Sie wahrscheinlich überprüfen, ob die Statistiken auf dem neuesten Stand sind, und/oder den Sproc aufschlüsseln.

Sie können dies auch bestätigen, indem Sie den Sproc profilieren.Wie verhält sich die E/A, wenn Sie sie über SQL Managment Studio ausführen, mit der Profilierung über die ASP.NET-Anwendung?Wenn sie sehr häufig vorkommen, unterstreicht dies nur, dass es sich um einen schlechten Ausführungsplan handelt.

Haben Sie die ASP.NET-Ablaufverfolgung bereits aktiviert?Ich hatte einen Fall, in dem nicht die gespeicherte SQL-Prozedur selbst das Problem war, sondern die Tatsache, dass die Prozedur 5.000 Zeilen zurückgab und die App versuchte, datengebundene ListItems mit diesen 5.000 Elementen zu erstellen, was das Problem verursachte.

Mithilfe der Ablaufverfolgung können Sie sich auch die Ausführungszeiten zwischen den Web-App-Funktionen ansehen, um das Aufspüren von Problemen zu erleichtern.

Testen Sie dies zunächst auf einer Staging-Box und ändern Sie es auf Serverebene für SQL Server

deklariere @option int

setze @option = @@ options | 64

exec sp_configure 'Benutzeroptionen', @option

NEU KONFIGURIEREN

Das gleiche Problem hatte ich mit SQL-Berichtsdiensten.Versuchen Sie, die Art von Variablen zu überprüfen. Ich habe unterschiedliche Variablentypen an SQL gesendet, als würde ich Varchar an Ort und Stelle senden, wo es ganzzahlig sein sollte, oder so ähnlich.Nachdem ich die Variablentypen im Reporting Service und in der gespeicherten Prozedur in SQL synchronisiert hatte, konnte ich das Problem lösen.

Sie könnten versuchen, den Befehl sp_who2 zu verwenden, um zu sehen, welchen Prozess der betreffende Prozess ausführt.Dies zeigt Ihnen, ob es von einem anderen Prozess blockiert wird oder übermäßig viel CPU- und/oder IO-Zeit beansprucht.

Wir hatten das gleiche Problem und hier ist, was wir herausgefunden haben.

Die Größe unseres Datenbankprotokolls wurde auf dem Standardwert (814 MB) belassen und das automatische Wachstum betrug 10 %.Auch auf dem Server wurde der maximale Serverspeicher auf der Standardeinstellung (2147483647 MB) belassen.

Als unser Protokoll voll war und wachsen musste, verbrauchte es den gesamten Speicher des Servers und es war nichts mehr für die Codeausführung übrig, sodass es zu einer Zeitüberschreitung kam.Am Ende haben wir die anfängliche Größe der Datenbankprotokolldatei auf 1 MB und den maximalen Serverspeicher auf 2048 MB festgelegt.Dadurch wurde unser Problem sofort behoben.Natürlich können Sie diese beiden Eigenschaften entsprechend Ihren Anforderungen ändern, aber das ist eine Idee für jemanden, der beim Ausführen einer gespeicherten Prozedur per Code auf ein Zeitüberschreitungsproblem stößt, aber in SSMS sehr schnell läuft und die oben genannten Lösungen nicht helfen.

Versuchen Sie, den SelectCommand-Timeout-Wert zu ändern:

DataAdapter.SelectCommand.CommandTimeout = 120;
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top