La colonne bloquée dans la table sysprocesses est remplie pour les attentes de verrou après l’installation de SQL Server 2000 SP4


Résumé


Après avoir installé Microsoft SQL Server 2000 Service Pack 4 (SP4), vous pouvez remarquer que la colonne dans la table système sysprocesses bloqué est remplie d’attentes de verrou en plus d’attentes de verrou. Parfois, vous pouvez remarquer les brèves périodes de temps lorsqu’un même processus serveur ID (SPID) est signalé en tant que le blocage lui-même. Ce comportement est normal.

Plus d'informations


Loquets sont utilisés pour synchroniser l’accès aux pages de données en mémoire cache et autres objets en mémoire. En général, les loquets ne sont conservés que brièvement et les temps d’attente de verrou sont relativement petits. SQL Server 2000 SP4 ajoute des tests de diagnostic pour résoudre les cas dans lesquels un SPID attend un certain temps d’un verrou interne. Ces outils de diagnostic provoquent la colonne bloqué dans la table système sysprocesses pour refléter le propriétaire d’un verrou qui bloque la demande de verrouillage d’un autre SPID. Avant SQL Server 2000 SP4, la colonne bloqué n’a été renseignée que lors d’une attente de verrouillage a provoqué le blocage.



Cette modification dans SQL Server 2000 SP4 ne modifie pas les situations dans lesquelles un verrou est demandé. En outre, cette modification ne change pas les situations dans lesquelles un SPID est bloqué par un verrou. Cette modification affecte uniquement le mode dans lequel un verrou attend figurent dans la table système sysprocesses .

Propriétaire du verrou est suivi uniquement pour les loquets dans exclusif (EX) ou mettre à jour (le mode de verrouillage haut). La propriété n’est pas suivie pour les verrous internes qui sont en mode de verrou partagé (SH). Cela signifie que la colonne bloqués n’est pas remplie pour certaines requêtes, même après l’installation de SQL Server 2000 SP4.

La plupart du temps, vous pouvez ignorer la valeur de la colonne bloqué si les conditions suivantes sont remplies :
  • La valeur de la colonne waittime est faible.
  • Les colonnes waittype du SPID est un type d’attente loquet.
Pour plus d’informations sur les valeurs possibles de la colonne type d’attente, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :

822101 waittype et lastwaittype colonnes de la table sysprocesses dans SQL Server 2000

Lorsqu’un SPID attend un verrou de page d’e/s, vous pouvez remarquer que la colonne bloqué brièvement signale que le SPID bloque lui-même. Ce comportement est un effet secondaire de la façon que les verrous sont utilisés pour les opérations d’e/s sur les pages de données. Lorsqu’un thread émet une demande d’e/s, le SPID qui émet la requête acquiert un verrou sur la page. Toutes les opérations d’e/s de SQL Server 2000 sont asynchrones. Par conséquent, le SPID va tenter d’acquérir un autre verrou sur la même page si le SPID qui a émis la demande d’e/s doit attendre que la requête se termine. Cette deuxième verrou est bloqué par le loquet de la première. Par conséquent, la colonne bloqué indique que le SPID bloque lui-même. Une fois la requête terminée, le premier verrou est libéré. Ensuite, la deuxième demande de verrou est accordée.

Par exemple, les conditions suivantes peuvent se produire :
  1. SPID 55 souhaite lire une page de données qui n’existe pas dans le pool de tampons.
  2. SPID 55 acquiert un verrou EX sur la page. Étant donné que la page n’existe pas encore dans la mémoire, le mode de verrouillage demandé est : Le mode de verrouillage EX force les autres SPID qui peut également accéder à la page d’attendre que la requête se termine. Le mode de verrouillage EX empêche également les autres SPID à partir de l’émission d’une demande d’e/s en double de la même page.
  3. SPID 55 émet la demande d’e/s de lecture de la page à partir du disque.

  4. Parce que SPID 55 souhaite lire la page, SPID 55 doit attendre que la requête se termine. Pour attendre la demande d’e/s se termine, SPID 55 essaie d’acquérir un autre verrou qui a le mode d’accès rapide (SH) partagé sur la même page. Dans la mesure où un verrou EX a déjà été acquis, la demande de verrou SH est bloquée et le SPID est suspendu. Étant donné que le loquet EX qui bloque la demande de verrou SH a également acquis par SPID 55, le SPID est temporairement signalé comme blocage lui-même.

  5. Une fois la requête terminée, le verrou de départ sur la page est libéré.
  6. Le dégagement du loquet EX donne le loquet SH SPID 55.

  7. SPID 55 peuvent désormais lire la page.

Entre les étapes 4 et 5, la table sysprocesses indique que SPID 55 est bloqué par lui-même avec un waittype de PAGEIOLATCH_XX. Dans ce type d’attente, XX est peut-être SH, jusqu'à ou : Ce comportement indique que SPID 55 émis une demande d’e/s et que SPID 55 attend que la demande d’e/s se termine.