SQL Server - Wie viele Arten von Zeitüberschreitungen können auftreten und wie?

Bei der Arbeit mit SQL Server können mehrere Anwendungshosts darauf zugreifen, und jede Anwendung kann eine oder mehrere Verbindungen haben. Jede Verbindung kann möglicherweise mehrere Transaktionen haben (bitte korrigieren Sie mich, wenn ich falsch liege). Jede Transaktion kann SQL abfragen oder nicht abfragen.

Nach meiner Erfahrung kann es leicht zu einer Zeitüberschreitung kommen, wenn ich eine Tabelle abfrage, die ausschließlich gesperrt ist. Ich habe auch gesehen, dass SQL Server eine Deadlock-Ausnahme anstelle eines Timeouts erkennt und auslöst, wenn zwei verschiedene Anwendungen dieselbe Ressource sperren. Ich zeige auch das Zeitlimit für die Neuerstellung des Index, das möglich ist, weil noch jemand eine Verbindung zur Tabelle hat.

Ich stoße jedoch auch auf eine Art Deadlock, bei dem SQL Server ihn nicht erkennt oder keine Zeitüberschreitung aufweist. In dieser Anwendung wurden zwei Verbindungen geöffnet, zwei separate Transaktionen, bei denen die erste Transaktion eine Ressource gesperrt hat und die zweite Transaktion versucht, auf dieselbe Ressource zuzugreifen, die erste Transaktion jedoch nicht geschlossen wurde.

Würde jemand eine Liste mit Arten von Zeitüberschreitungen und / oder Deadlocks bereitstellen, würde es mir helfen, diese Art von Fällen bei der Arbeit an der Anwendung zu vermeiden.

Nun, aus Sicht der Anwendung gibt es:

• Verbindungszeitlimit (wie lange die App bereit ist zu warten, um eine Verbindung zu SQL Server herzustellen)
• Befehlszeitlimit (wie lange die App bereit ist, auf den Abschluss eines Befehls zu warten, einschließlich des Abrufs der Ergebnisse von SQL Server)

In meinen klassischen ASP-Tagen waren die Standardeinstellungen für diese 15 bzw. 30 Sekunden . Ich habe keine Ahnung, was sie heute in .NET standardmäßig sind.

SQL Server verfügt über eigene Zeitüberschreitungen, z. B.:

• Zeitlimit für Remote-Abfrage. Die Standardeinstellung ist 600 Sekunden (10 Minuten).
• Zeitlimit für Remote-Anmeldung. Die Standardeinstellung ist 10 Sekunden.
• Abfrage warten. Die Standardeinstellung ist -1 (25 x Abfragekosten).
• Zeitlimit für Volltextprotokoll-Handler. Die Standardeinstellung ist 60 Sekunden.

Sie können diese Werte für Ihr System hier sehen:

SELECT * FROM sys.configurations
WHERE configuration_id IN (1519,1520,1541,1557);

Es gibt auch @@LOCK_TIMEOUT(standardmäßig -1 (unendlich)). So lange wartet SQL Server auf eine blockierte Ressource. Sie können dies für eine bestimmte Sitzung mit überschreiben SET LOCK_TIMEOUT. Weitere Details hier .

Deadlocks könnten wohl auch in diese Kategorie fallen. Das System sucht alle 5 Sekunden nach Deadlock-Situationen, und es gibt keine Zauberformel, um zu bestimmen, wann der Deadlock in Bezug auf den Zeitpunkt des Starts einer der beteiligten Anforderungen auftritt. Dies liegt daran, dass SQL Server die älteste Transaktion nicht gewinnen lässt. Das Opfer wird basierend auf DEADLOCK_PRIORITY und der geschätzten Menge an Ressourcen ausgewählt, die zum Zurücksetzen des Opfers erforderlich sind. Weitere Details hier .

Es gibt auch ein Zeitlimit für die Speichergewährung (das mithilfe von Resource Governor angepasst werden kann). Abhängig von der Parallelität schlägt eine Abfrage nicht unbedingt fehl, wenn sie das Zeitlimit erreicht, bevor der gesamte angeforderte Speicher abgerufen wird. Sie wird nur mit dem zugewiesenen Betrag ausgeführt (und ist daher möglicherweise weniger effizient). Wenn dies fehlschlägt, wird wahrscheinlich Msg 8645 angezeigt.

Sie können sich ein Bild von anderen möglichen Timeout-Szenarien machen, die in SQL Server auftreten können, indem Sie die folgenden Fehlermeldungen überprüfen:

SELECT message_id, [text]
  FROM sys.messages 
  WHERE language_id = 1033 
  AND ([text] LIKE '%timeout%' OR [text] LIKE '%time out%')

Ich halte es jedoch nicht für praktisch, machbar oder produktiv, wenn jemand versucht, Ihnen eine vollständige und vollständige Liste aller möglichen möglichen Timeout-Situationen zur Verfügung zu stellen. Lösen Sie die Probleme, die Sie haben, anstatt eine ganze Reihe von Problemen vorzeitig zu lösen, die Sie wahrscheinlich nie werden ...

Hier werden drei verschiedene Konzepte angesprochen. Hoffentlich gibt dies eine gute Erklärung dafür, was sie sind, und von dort aus können Sie herausfinden, wie Sie sie vermeiden können.

Blockieren (auch als Live-Sperre bezeichnet) Das
Blockieren tritt auf, wenn eine Abfrage versucht, eine Sperre zu erhalten, jedoch in der Sperrwarteschlange warten muss, bevor die Sperre gewährt wird. Von außen kann es so aussehen, als würde die Abfrage nichts tun, da sie darauf wartet, dass die anderen Prozesse die Sperre (n) davor in der Warteschlange freigeben. Das Blockieren kann zu Deadlocks führen, wenn die Sperren in einer bestimmten Reihenfolge erworben werden (ich beschreibe dies unten).

Zeitüberschreitungen
Zeitüberschreitungen treten auf, wenn ein Client eine Anforderung für eine Ressource stellt und auf eine Antwort wartet. Wenn innerhalb eines bestimmten Zeitraums keine Antwort eingeht, wird vom Client ein Fehler ausgelöst, anstatt ewig zu warten. Zeitüberschreitungen können aus verschiedenen Gründen auftreten (Blockierung oder eine Abfrage, die eine Menge Arbeit erledigt, oder das Netzwerk war sehr langsam oder ...), aber letztendlich alles, weil der Client gewartet hat und entschieden hat, dass er nicht wollte noch mehr warten.

Deadlocks
Deadlocks treten auf, wenn zwei oder mehr Prozesse Ressourcen sperren und versuchen, Ressourcen zu sperren, die von den anderen Prozessen gehalten werden. Dies führt zu einer Situation, in der keine Abfrage fortgesetzt werden kann, es sei denn, eine von ihnen wird beendet / zurückgesetzt. Wie das funktioniert, habe ich hier in einem Demo-Video gezeigt .