Comment un SELECT en bloque-t-il un autre?

Question

Je regarde la sortie de SP_WhoIsActive sur SQL Server 2005, et il me dit qu'une session en bloque une autre - très bien. Cependant, ils ont tous les deux un SELECT. Comment un SELECT en bloque-t-il un autre? Ne devraient-ils pas tous deux acquérir des verrous partagés (qui sont compatibles les uns avec les autres)?

Quelques détails supplémentaires: Aucune session n'a un nombre de transactions ouvert - elles sont donc autonomes.

Les requêtes rejoignent une vue avec une table.

Ce sont des requêtes complexes qui rejoignent beaucoup de tables et aboutissent à environ 10 000 lectures.

Un aperçu très apprécié.

Answer 1

Les instructions SELECT peuvent bloquer une autre instruction SELECT. Vous pensez probablement que puisque les deux n'acquièrent que des verrous S, ils ne devraient jamais bloquer. Mais le blocage se produit sur différents types de ressources, pas seulement sur les verrous. Un exemple typique est celui des contraintes de mémoire. Je vais essayer de creuser une réponse récente à une question ici qui avait attaché un graphique de blocage qui a montré aux instructions SELECT, l'un pour l'autre pour les ressources de mémoire d'opérateur d'échange parallèle (tampons).

Mise à jour Voici le lien avec les informations de blocage J'ai parlé: I have data about deadlocks, but I can't understand why they occur Si vous étudiez le graphique de blocage, vous remarquerez la ressource suivante dans la liste d'attente:

<exchangeEvent id="Pipe894b0680" WaitType="e_waitPipeGetRow" nodeId="0"> 
    <owner-list> 
    <owner id="process824df048"/> 
    </owner-list> 
    <waiter-list> 
    <waiter id="process86ce0988"/> 
    </waiter-list> 
</exchangeEvent> 

Ce n'est pas un verrou, est une ressource 'e_waitPipeGetRow', appartient à un SELECT et un autre SELECT l'attend. Une discussion sur les ressources parallèles intra-requête peut être trouvée ici: Today's Annoyingly-Unwieldy Term: "Intra-Query Parallel Thread Deadlocks". Alors que la plupart des discussions vont se concentrer sur les problèmes d'interblocage, cela ne signifie pas que le blocage ordinaire ne peut pas se produire sur ces ressources. sys.dm_exec_requests aura l'information appropriée dans wait_type et wait_resource.

Answer 2

Je pense que c'est parce que la première sélection effectue un verrouillage de ligne/verrouillage de table. Tout en joignant la table, vous pouvez fournir NO LOCK Hint.