"Sperreneskalation " So handhabt SQL Sperren für große Aktualisierungen. Wenn SQL viele Zeilen ändern wird, ist es für die Datenbank-Engine effizienter, weniger, größere Sperren (z. B. ganze Tabellen) zu nehmen, anstatt viele kleinere Dinge (z. B. Zeilensperren) zu sperren. .
Dies kann jedoch problematisch sein, wenn Sie eine große Tabelle haben, da das Sperren der gesamten Tabelle andere Abfragen für lange Zeit sperren kann. Das ist der Kompromiss:Viele Sperren mit kleiner Granularität sind langsamer als weniger (oder eine) grobkörnige Sperren, und wenn mehrere Abfragen verschiedene Teile einer Tabelle sperren, besteht die Möglichkeit eines Deadlocks, wenn ein Prozess auf einen anderen wartet.
Es gibt eine Option auf Tabellenebene, LOCK_ESCALATION , neu in SQL 2008, ermöglicht die Steuerung der Sperrenausweitung. Der Standardwert „TABLE“ ermöglicht es, dass Sperren bis auf die Tabellenebene eskalieren. DISABLE verhindert in den meisten Fällen eine Sperrenausweitung auf die gesamte Tabelle. AUTO erlaubt Tabellensperren, es sei denn, die Tabelle ist partitioniert, in diesem Fall werden Sperren nur bis zur Partitionsebene vorgenommen. Siehe diesen Blogbeitrag für weitere Informationen.
Ich vermute, dass die IDE diese Einstellung hinzufügt, wenn eine Tabelle neu erstellt wird, da TABLE die Standardeinstellung in SQL 2008 ist. Beachten Sie, dass LOCK_ESCALATION in SQL 2005 nicht unterstützt wird, also müssen Sie es entfernen, wenn Sie versuchen, das Skript auf a auszuführen Instanz aus dem Jahr 2005. Da TABLE der Standardwert ist, können Sie diese Zeile auch sicher entfernen, wenn Sie Ihr Skript erneut ausführen.
Beachten Sie auch, dass in SQL 2005, bevor diese Einstellung vorhanden war, alle Sperren auf Tabellenebene eskalieren konnten – mit anderen Worten, „TABLE“ war die einzige Einstellung in SQL 2005.
