"Verrouiller l'escalade " est la façon dont SQL gère le verrouillage pour les mises à jour volumineuses. Lorsque SQL va modifier un grand nombre de lignes, il est plus efficace pour le moteur de base de données de prendre moins de verrous plus grands (par exemple, une table entière) au lieu de verrouiller de nombreuses petites choses (par exemple, des verrous de ligne) .
Mais cela peut être problématique lorsque vous avez une table énorme, car prendre un verrou sur la table entière peut bloquer d'autres requêtes pendant une longue période. C'est le compromis :de nombreux verrous à petite granularité sont plus lents que moins (ou un) verrous à grain grossier, et le fait d'avoir plusieurs requêtes verrouillant différentes parties d'une table crée la possibilité d'un blocage si un processus attend un autre.
Il existe une option au niveau de la table, LOCK_ESCALATION , nouveau dans SQL 2008, qui permet de contrôler l'escalade des verrous. La valeur par défaut, "TABLE", permet aux verrous de remonter jusqu'au niveau de la table. DISABLE empêche l'escalade de verrous à l'ensemble de la table dans la plupart des cas. AUTO autorise les verrous de table sauf si la table est partitionnée, auquel cas les verrous ne sont constitués qu'au niveau de la partition. Voir cet article de blog pour plus d'informations.
Je soupçonne que l'IDE ajoute ce paramètre lors de la recréation d'une table car TABLE est la valeur par défaut dans SQL 2008. Notez que LOCK_ESCALATION n'est pas pris en charge dans SQL 2005, vous devrez donc le supprimer si vous essayez d'exécuter le script sur un cas de 2005. De plus, puisque TABLE est la valeur par défaut, vous pouvez supprimer cette ligne en toute sécurité lors de la réexécution de votre script.
Notez également que, dans SQL 2005 avant que ce paramètre ne soit présent, tous les verrous pouvaient remonter au niveau de la table. En d'autres termes, "TABLE" était le seul paramètre sur SQL 2005.
