SQL Server Select Count READ_COMMITTED_SNAPSHOT QUESTION

Il semble que j'obtienne de nombreux blocages lors de la sélection du nombre (*) sur une table particulière. J'ai déjà modifié tous les paramètres requis et les ai transformés en verrouillage de ligne uniquement.

J'ai également modifié la base de données pour utiliser l'isolement READ_COMMITTED_SNAPSHOT,

cependant, il semble que l'utilisation d'un nombre sélectionné (*) où colonne =? sur la table déclenche des blocages ou des verrous sur la table.

Ai-je raison de dire que le nombre sélectionné (*) ne doit accéder qu'aux lignes intermédiaires?, Cependant, cela ne semble pas ainsi et je rencontre toujours des blocages. Une indexation appropriée aiderait probablement,

La question est la suivante: SQL Server 2008 R2 place-t-il un verrou partagé sur la table pendant le nombre de sélections (*) même lorsque read_committed_snapshot est activé?

Merci

— grassbl8d
source

Avez-vous besoin d'un décompte exact (à la demande), ou un décompte approximatif est-il correct?

— Jon Seigel

en fait, j'ai seulement besoin de savoir si des verrous partagés sont placés. J'essaie d'enquêter sur un problème de blocage. Merci

— grassbl8d

Mon point était que si vous pouvez envisager de changer la façon dont le nombre est obtenu, cela peut être le moyen de résoudre le problème de l'impasse. Mais maintenant que j'ai relu la question, si vous avez besoin d'utiliser une WHEREclause, la méthode à laquelle je pense ne fonctionnera pas de toute façon.

— Jon Seigel

Vous pouvez récupérer des nombres approximatifs à partir de tables de métadonnées pour un sous-ensemble de la table si la clause where correspond à un index filtré.

— Aaron Bertrand

Réponses:

Soyez prudent avec READ_COMMITTED_SNAPSHOT: si vous le configurez, cela peut provoquer de nombreux bugs subtils.

READ_COMMITTED_SNAPSHOT est également le niveau d'isolement par défaut, qui peut être remplacé par quelque chose. Exécutez DBCC USEROPTIONS pour déterminer le niveau d'isolement réel sous lequel votre sélection s'exécute.

JE DÉFINIRS DE FAÇON INSTANTANÉE DE NIVEAU D'ISOLEMENT DE TRANSACTION juste avant votre sélection. De cette façon, vous serez sûr que votre sélection n'embrasse jamais dans des blocages, et vous ne cassez aucun autre code, comme READ_COMMITTED_SNAPSHOT pourrait le faire.

— AK
source

Le verrouillage avec Snapshot Isolation ne change pas. Ce qui change, c'est que lorsque des pages sont modifiées sous vous, ces pages sont copiées dans la base de données tempdb afin que vous puissiez les lire à partir de la base de données tempdb au lieu de la base de données normale. (Oui, c'est une version simplifiée de ce qui se passe.)

Vous avez mentionné que vous n'avez pas d'indexation appropriée en place, vous effectuez donc une analyse d'index en cluster (ou une analyse de table s'il s'agit d'un segment). C'est potentiellement beaucoup de données à déplacer vers la base de données tempdb. Si cette requête est exécutée plusieurs fois, je suggère d'ajouter l'index à la table.

Quel niveau d'isolement utilise votre requête?

— mrdenny
source

J'utilise le niveau d'isolement read_commited_snapshot. Je l'ai allumé car j'utilise read_committed par défaut. Je suis simplement intéressé si des verrous sont placés pendant les comptages sélectionnés. Merci, j'ai déjà placé des index btw

— grassbl8d

Oui, des serrures sont toujours prises. Vous pouvez interroger sys.dm_tran_locks pour voir les verrous qui sont pris. Exécutez votre requête dans une fenêtre et recherchez sys.dm_tran_locks dans une autre fenêtre pour voir quels verrous sont pris. Vous pouvez passer aux verrous de table et devez utiliser un indice pour forcer les verrous de page ou même de niveau ligne.

— mrdenny