Le AVEC (nolock) allusion est une commande explicite dirigé vers une table ou une vue spécifique utilisé pour définir le niveau d’isolation de transaction à l’encontre de la table ou des tables dans une vue pour une requête. Une fois émis, les verrous ne seront pas utilisés contre les données de la table. L’avantage est qu’il n’y a aucune chance qu’un blocage se produise contre d’autres requêtes exécutées contre la table., L’autre avantage indirect est que moins de mémoire sera utilisée afin de maintenir des verrous contre ces données.

exemple:

le paramètre NOLOCK ci-dessus est explicite pour la table contre laquelle il est défini.,s ne se produira pas contre d’autres requêtes exécutées sur les mêmes données

inconvénients:

• Les données non validées peuvent> dans la plupart des endroits où j’ai travaillé, avec (NOLOCK) a été une pratique généralement acceptée dans les domaines spécifiques du système qui ne sont pas sensibles aux données étant légèrement désynchronisées., Il est important de savoir où les choses pourraient mal tourner. Le plus grand drapeau rouge auquel je puisse penser pour ne pas utiliser NOLOCK serait un système qui utilise des transactions explicites (BEGIN TRAN ..Fin TRAN) ou une utilisation intensive des déclencheurs. Plusieurs instructions exécutées dans une transaction subissent un délai de leurs opérations D’insertion / mise à jour / suppression, mais les modifications sont validées immédiatement lors de la validation., Les instructions qui interrogent les données modifiées à l’aide du niveau D’isolement READ COMMITTED seront bloquées de voir ces modifications jusqu’à la validation, tandis que READ UNCOMMITTED (NOLOCK) verra les modifications immédiatement indépendamment du moment où la validation se produit. L’hypothèse ici est que si votre système utilise des transactions explicites ou s’appuie fortement sur des déclencheurs, il peut être plausible de supposer que nolock n’est pas une bonne idée.,
  

  ne pas utiliser avec (NOLOCK) sans bien comprendre les ramifications d’une lecture sale

  exemple d’une lecture Sale

  L’exemple suivant ouvrira une transaction afin de mettre à jour la colonne first_name dans notre table temp globale: ##my_name

  Si OBJECT_ID(‘tempdb..,##my_name’) N’est pas nul
  BEGIN
  DROP TABLE ##my_name;
  END;

  CREATE TABLE ##my_name
  (
  id int,
  first_name varchar(20)
  );

  INSERT INTO ##my_name (id, first_name)
  VALUES (1, ‘dexter’);

  BEGIN TRAN

  UPDATE ##my_name
  set first_name = ‘Derek’
  WHERE id = 1;

  ici, nous avons laissé une transaction ouverte sur ##my_name afin que la ligne soit exclusivement verrouillée et ne puisse être lue par aucune transaction utilisant le niveau d’isolement read committed ou supérieur.,

  ici, vous verrez que la première requête affichera la valeur mise à jour ‘derek’, alors que la requête sans le nolock se bloquera en attendant la libération de la transaction. Les données qui ont été lues avec succès sont considérées comme des données sales. En effet, il peut y avoir d’autres tables qui doivent être mises à jour qui se rapportent à l’enregistrement « derek » (id=1) afin de montrer une vue cohérente de toutes les données liées à « derek ».

  enfin, validons notre transaction dans notre fenêtre d’origine et vous verrez que vous pouvez maintenant interroger les données sans utiliser (nolock).,

  COMMIT TRAN
  SELECT * from ##my_name;

  Déposées en vertu de TSQL