SQL Server - t-il [SELECT] de verrouillage [mise à JOUR]?

J'ai une requête sélection complexe et d'une immense table.

Je suis l'exécution de cette select déclaration, en attendant un Update déclaration arrive et tente de mise à jour la table.

À mon humble avis - mise à jour nécessite une exclusif de verrouillage de sorte que la mise à jour de la déclaration auront à attendre jusqu'à la commande select est fini.

  1. Suis-je droit ?

  2. que puis-je faire pour: exécuter le complexe select, et également à la update commande exécuter (actuellement, je ne se soucient pas de la sale de données)

Ce niveau d'isolation de transaction parlez-vous?
La valeur par défaut - je crois que c'est de lire obligé.
"actuellement, je ne se soucient pas de la sale de données": attention ce que vous souhaitez pour.

OriginalL'auteur Royi Namir | 2012-08-06

  1. 15

    Oui - dans une certaine mesure.

    Combien de temps un SELECT détient un verrou partagé est selon le niveau d'isolation de la transaction:

    • READ UNCOMMITTED - pas de verrou partagé est acquis à tout UPDATE n'est pas bloqué
    • READ COMMITTED - verrou partagé est acquise pour la durée de la lecture des données - UPDATE peut être bloqué pour une très courte période de temps
    • REPEATABLE READ et SERIALIZABLE - verrou partagé est acquis et a tenu jusqu'à la fin de la transaction - UPDATE est bloqué jusqu'à ce que le SELECT opération se termine

    Techniquement, le UPDATE déclaration obtient d'abord un UPDATE de verrouillage qui est compatible avec un verrou partagé (tel qu'utilisé par le SELECT) - pour la durée du temps de tout lire les valeurs actuelles des lignes à mettre à jour.

    Une fois cela fait, le Update de verrouillage est transmis à un verrou exclusif pour les nouvelles données à écrire sur le tableau.

    the UPDATE statement first gets an UPDATE lock - which is compatible with a shared lock Je ne comprends pas marc. la mise à jour est en attente pour sélectionner à la fin ?
    la mise à jour peut acquérir la Update de verrouillage (pour lire les données "anciennes") alors qu'un autre processus est encore la lecture de cette même ligne et a un shared verrou sur cette ligne. La mise à jour ne sera pas en mesure d'aller à un verrou exclusif (pour écrire les "nouvelles" données en arrière), cependant, tant que la shared de verrouillage est encore en place, donc il faudra attendre....

    OriginalL'auteur marc_s

  2. 5

    Lorsque vous exécutez les deux états simultanément (une sélection et une mise à JOUR) le comportement réel sera fondamentalement aléatoire. C'est parce que aucun de ces opérations est instantanée. Pour simplifier, pensez à votre table une liste et SÉLECTIONNEZ traverse cette liste, à la recherche d'une ligne à la fois. La mise à JOUR est aussi en train d'essayer de mettre à jour une ou plusieurs lignes. Lorsque la mise à JOUR est d'essayer de mettre à jour une ligne derrière le SÉLECTIONNER puis rien ne se passe (pas de blocage) parce que le SELECT a déjà progressé au-delà du point de mise à JOUR. Si la mise à JOUR est en train d'essayer de mettre à jour la ligne à, qui choisissent est à la recherche maintenant puis la mise à JOUR devra attendre pour SÉLECTIONNER à passer, ce qui va arriver très très très vite et la mise à JOUR permettra de débloquer et de réussir, tout le SELECT est aller de l'avant. Mais si la mise à JOUR est mise à jour une ligne à l'avance de le SÉLECTIONNER puis de la mise à jour va réussir et, plus tard, SÉLECTIONNEZ finira par atteindre exactement cette ligne et arrêt, bloqué. Maintenant, SÉLECTIONNEZ doit attendre jusqu'à ce que la transaction qui a fait la mise à JOUR s'engage.

    C'est la version simplifiée de l'histoire. La vie réelle est beaucoup plus compliqué. Le SELECT peut avoir plusieurs lire points (plans parallèles). À la fois la sélection et la mise à JOUR sont soumis à choisir un chemin d'accès, de sens d'utiliser un ou plusieurs index secondaires de localiser les lignes. Des requêtes complexes peuvent contenir des opérateurs causer de multiples recherches dans un tableau (par exemple. les jointures). À la fois la sélection et la mise à JOUR peut faire des recherches signet pour récupérer des données BLOB, ce qui modifie considérablement le comportement de verrouillage. L'estimation de cardinalité peut provoquer le SÉLECTIONNER pour exécuter à un haut degré de granularité de verrouillage de mode (par exemple. niveau de la table verrou Partagé). La mise à JOUR peut déclencher la promotion de verrous, et l'escalade peut échouer ou réussir. Choisir différents chemins d'accès peuvent conduire à une impasse. Faux conflit de verrouillage peut se produire en raison de collisions de hachage. Il y a une multitude de variables qui ont un mot à dire dans cette. Et je n'ai même pas mention de la hausse des niveaux d'isolement (repeatable read, serializable).

    Peut-être que vous devriez utiliser INSTANTANÉ isolement et arrêtez de vous inquiéter à propos de ce problème?

    Si vous suggère d'aller avec SNAPSHOT - assurez-vous que le TempDB est correctement mis en place ! (l'emplacement et le nombre de fichiers de données, les options de dimensionnement, etc.)
    Oui, reproductible et serializable cause verrou partagé d'être retenu pour l'étendue de la transaction. Serializable également ajouter des verrous de plage. Tous ces ajouter de la complexité.
    le lien vers la rubrique MSDN couvre la Versioning de l'Utilisation de la Ressource. Je préfère ne pas effrayer les utilisateurs, car je considère que les avantages de l'INSTANTANÉ l'emportent de loin sur son coût.

    OriginalL'auteur Remus Rusanu