INF: Analyse et éviter les blocages dans SQL Server

Traductions disponibles Traductions disponibles
Numéro d'article: 169960 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Microsoft SQL Server maintient l'intégrité transactionnelle et de la base de données la cohérence à l'aide de verrous. SQL Server version 6.5 éventuellement le verrouillage au niveau de la ligne pour les opérations d'insertion et verrouillage des pages pour d'autres opérations. Comme avec n'importe quel système de base de données relationnelle, verrouillage peut entraîner des blocages entre utilisateurs.

Par exemple, supposons que l'utilisateur 1 (ou Connection1) a un verrou sur données d'articles «A» et veut un verrou sur l'élément de données «b». L'utilisateur 2 comporte un verrou sur l'élément de données «B» et maintenant veut obtenir un verrou sur l'élément de données «a». Dans ce scénario de SQL Server, User1 ou User2 est victime du blocage et l'autre utilisateur recevra le verrou demandé.

Dans SQL Server, le développeur d'applications pouvez décidez quelle connexion sera candidat pour la victime à l'aide de SET DEADLOCK_PRIORITY. Si le développeur ne désigne pas une priorité pour les blocages, SQL Server sélectionne la victime du blocage en choisissant le processus qui se termine la chaîne circulaire de verrous.

Application de base de données systèmes peuvent se comporter différemment lorsque porté à partir d'une base de données relationnel à l'autre, basé sur la mise en oeuvre du système de base de données relationnelle. Une des zones pour rechercher des modifications comportementales se bloque. Cet article explique comment analyser les blocages dans SQL Server et les techniques que vous pouvez utiliser pour les éviter.

Plus d'informations

Cet article met en évidence à l'aide de la sortie de l'indicateur de trace T1204 pour analyser les blocages. Lorsque l'indicateur de trace T1204 est définie, SQL Server imprime des informations sur le blocage lorsqu'il se produit. Pour utiliser cet indicateur de trace, utilisez la commande suivante à l'invite de commande pour démarrer SQL Server :
   sqlservr -c -T1204
				

Les résultats de la trace sont envoyées dans la fenêtre de console, sauf si vous définissez l'indicateur de trace T3605, qui envoie la sortie de traçage dans le journal des erreurs.

Des blocages peuvent survenir lorsque deux connexions mettre à jour les tables dans l'ordre opposé. Par exemple, une seule connexion insère à la table "example1" première et à la "example2", pendant une autre connexion insère dans la table "example2" première, puis dans "example1" dans une transaction. Un exemple de scénario est utile d'expliquer comment éviter les blocages.

Les instructions SQL utilisées pour créer la table utilisée pour cet exemple sont les suivantes :
   create table example1 (column1 int, column2 char(20), column3 char(50))
   go
   create table example2 (column1 int, column2 char(20), column3 char(50))
   go
   declare @lvar int
   select @lvar = 0
   while @lvar < 500
   begin
   insert into example1 values (@lvar, 'AAA', 'CCC')
   insert into example2 values (@lvar, 'AAA', 'CCC')
   select @lvar = @lvar + 1
   end
   go
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
   create unique clustered index ex2ind1 on example2 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
				

Exemple 1: Tableau insertions dans ordre opposé

Dans cet exemple, deux tables ont été insérés dans l'ordre inverse et un blocage s'est produite. Blocages peuvent également se produire lorsque deux ou plus de connexions effectuer des mises à jour ou suppressions dans les tables de l'ordre inverse.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
				

À ce stade, Connection1 peut bloquer Connection2 car la ligne de qu'insertion de Connection2 peut-être sur la même page où Connection1 a déjà inséré une ligne et maintient un verrou.
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

À ce stade, Connection2 peut bloquer Connection1, car la ligne de qu'insertion de Connection1 peut se trouver sur la page même où Connection2 a déjà inséré une ligne et un verrou. Cela provoque un blocage.

Voici la sortie pour l'indicateur de trace 1204 lorsque le blocage s'est produit :
97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES (100,
     'AAAA', 'CCC')
   spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (200,
   'AAAB', 'CCC')
   VICTIM: spid 13, pstat 0x0000 , cputime 30
				

Chaque ligne de la trace de blocage peut demander aux utilisateurs plus d'informations sur un blocage. Connection1 est spid 13 et Connection2 spid 14 (vous pouvez déterminer le spid associé à une connexion à l'aide de la procédure stockée système sp_who).
   >> 97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   The deadlock was detected between spid 13 and spid 14.
   >> spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES
   (100, 'AAAA', 'CCC')
				

SPID 13 a été de demandant le verrou EX_PAGE et a été bloquée par spid 14, ayant déjà EX_PAGE verrou pour page 0x188 sur table example2 dans dbid 6. Le verrou est maintenu sur la page appartenant à un index ordonné en clusters.
      Indid Value         Description
-------------------------------------
         0                Data page if there is no clustered index, or the
                          leaf page of a clustered index if there is one
         1                Non-leaf page of the clustered index page
       255                Text/image page
    Any other value       Non-clustered secondary index
				

La commande en cours d'exécution par spid 13 est une instruction INSERT et la trace renvoie la partie de la mémoire tampon d'entrée.
   >> spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES
   (200, 'AAAB', 'CCC')
				

14 SPID attend le verrou EX_PAGE et est bloqué par spid 13, qui contient déjà EX_PAGE verrou sur la même page.
   >> VICTIM: spid 13, pstat 0x0000 , cputime 30
   SQL Server has chosen spid 13 as the deadlock victim.
				

Voici une explication de la signifient des verrous différents dans la trace :

SH_INT et EX_INT
Les verrous d'intention sont pris sur un élément de niveau supérieur (par exemple, une table) avant le verrouillage de niveau inférieur (par exemple, une page) peuvent être prises, le Gestionnaire de verrous étant ignore la relation entre les différents types d'éléments (dans ce cas, les pages et les tables). Si un verrou EX_INT n'était pas pris sur la table avant de prendre EX_PAG verrous sur les pages, un autre utilisateur pourrait exécuter un verrou EX_TAB sur la même table et le Gestionnaire de verrous ne saurait pas qu'il existait un conflit. Actuellement, SQL Server a des verrous d'intention uniquement sur des tables. Il existe deux types de verrous d'intention : partagé (SH_INT) et exclusive (EX_INT) verrouille.

EX_PAGE
Il s'agit d'un verrou de page exclusifs entreprise lorsqu'une page est mise à jour en raison d'une instruction DELETE, UPDATE, ou une instruction INSERT avec insérer de verrouillage de lignes (IRL) désactivé.

UP_PAGE
Ceci est un verrou de page de mise à jour qui est pris à la place d'un verrou de page partagés au moment où une page est analysée et l'optimiseur sait que la page sera mise à jour (ou la directive UPDLOCK est utilisée).

PR_EXT, NX_EXT, UPD_EXT et EX_EXT
Ces verrous sont appliquent lorsqu'il allocation ou désallocation de l'espace disque. UPD_EXT est prise lors de l'allocation ou désallocation une page à partir d'une étendue existante et les autres sont utilisés lors de l'allocation ou désallocation extensions entières.

IX_PAGE et LN_PAGE
Il s'agit de verrous IRL. IX_PAGE est un verrou intent-à--ligne-verrouillage sur une page. LN_PAGE est pris au moment où une page sur laquelle IRL porte doit être fractionnée.

RLOCK et XRLOCK
Ces verrous à court terme sont appliquent lorsqu'il transitant par un index b-tree. Il existe deux types de ce type de verrouillage : partagé (RLOCK) et exclusive (XRLOCK). Verrous partagés s'appliquent au cours d'analyse, tandis que les verrous exclusifs sont pris sur les pages d'index pendant une mise à jour.

EX_TAB
Il s'agit d'un verrou de table exclusif qui se produit lorsque l'optimiseur de SQL Server détermine qu'un balayage de table est le moyen le plus efficace pour résoudre une requête mise à jour (par exemple, lorsqu'il n'y a aucuns index sur une table). Verrous EX_TAB apparaissent également lorsque vous verrouillez la table avec indication TABLOCKX ou lorsque SQL Server transmet les verrous de page sur une table à un verrou de table.

SH_TAB
Il s'agit d'un verrou de table est utilisée lors de l'optimiseur considère que la majeure partie de la table est analysé (ou verrouillage de page fait remonter) ou l'indicateur TABLOCK est utilisée.

L'exemple précédent de blocage peut être évité si les deux connexions mettre à jour les tables dans l'ordre suivant :
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

Exemple 2: Insertions sur différentes parties de la même table

Ce blocage peut également se produire lorsque deux connexions insérez dans différentes parties de la même table dans l'ordre inverse lorsque lignes partagent des pages. Par exemple :
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example1 VALUES (400, 'AAAA', 'CCC')
				

Dans ce tableau, il existe un index ordonné en clusters sur la première colonne de la table example1. Lignes ayant les mêmes valeurs pour la première colonne ont tendance à tombent sur la même page. Dans l'exemple, la deuxième ligne insérée par Connection1 probablement tombera la même page que la première ligne insérée par Connection2, car ils les deux ont une valeur d'index ordonné en clusters de 400. Cela entraîne Connection2 bloc Connection1.
   Connection2 > INSERT INTO example1 VALUES (100, 'AAAB', 'CCC')
				

Maintenant Connection2 peut également être bloqué par Connection1, conduisant à un blocage. Voici la trace de blocage :
   97/04/20 12:56:01.40 spid16   *** DEADLOCK DETECTED with spid 15 ***
   spid 16 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 15, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (100,
   'AAAB', 'CCC')
   spid 15 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 16, dbid 6, page 0x8bd, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (400,
   'AAAA', 'CCC')
   VICTIM: spid 16, pstat 0x0000 , cputime 130
				

La demande de spid 16 de verrou EX_PAGE pour page 0x2c5 est bloquée par spid 15, qui contient déjà EX_PAGE verrou pour page 0x2c5 après que la première insertion. Et spid 15 également a été bloqué par spid 16 sur attend un verrou EX_PAGE pour page 0x8db interlignage de blocage.

Ce blocage peut être évité en utilisant la commande suivante pour activer IRL pour table example1 :
   sp_tableoption 'example1', 'insert row lock', true
				

Exemple 3: Insertions à l'aide de IRL

IRL permet à deux ou plusieurs utilisateurs de partager une page lorsqu'ils insèrent uniquement les opérations, qui se traduit souvent par une amélioration du débit. Toutefois, l'activation IRL ne réduit pas toujours les verrous mortels. Dans certains cas, IRL peut introduire des blocages.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (105, 'AAAB', 'CCC')
				

Avec IRL activé, les deux connexions contiendra un verrou IX_PAGE sur la page contenant deux nouvelles lignes. Si IRL a été désactivé, Connection1 devrait avoir acquis un verrou EX_PAGE et Connection2 aurait été bloqué immédiatement.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

À ce stade, Connection2 doit un verrou exclusif page pour faire une instruction UPDATE qui n'est pas compatible avec IX_PAGE verrou de Connection1. Par conséquent, Connection2 attendra.
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 100
   and column2 = 'AAAA'
				

Maintenant Connection1 peut être bloquée par Connection2, conduisant à un blocage. Voici la trace de blocage :
   97/04/20 15:13:50.07 spid17   *** DEADLOCK DETECTED with spid 18 ***
   spid 17 requesting UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 18, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 100 and column2 = 'AAAA'
   spid 18 waiting for UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 17, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   VICTIM: spid 17, pstat 0x0000 , cputime 20
				

SPID 17 (connexion unique) est en attente d'un verrou UP_PAGE, qui est la première étape pour obtenir un verrou exclusif de la page. Il est bloqué par spid 18, qui contient le verrou IX_PAGE sur page 0x2c5. 18 SPID attend le verrou UP_PAGE sur la même page et est bloqué par IX_PAGE verrou détenu par spid 17. Cela entraîne un blocage car IX_PAGE verrou est partageable, alors que UP_LOCK n'est pas. Au cours des première insertions, à la fois le SPID a verrou IX_PAGE sur la même page et ultérieurement qu'ils avez essayé de mettre à niveau du verrou en verrou UP_PAGE, qui n'est pas possible car UP_PAGE verrou est exclusif.

L'une façon d'éviter le blocage consiste à insérer la valeur mise à jour directement dans la table au lieu d'insertion et de mise à jour de la ligne dans la même transaction. Si ce n'est pas possible, à l'aide de la commande suivante pour désactiver IRL contribuera à éviter un blocage :
   sp_tableoption 'example1', 'insert row lock', false
				

Exemple 4: Insertions pour les lignes à la même page

Un blocage peut également entraîner lorsque les lignes deux sur que SPID travaillent sont différentes mais appartiennent à la même page.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 405
   and column2 = 'AAAA'
				

À ce stade, Connection1 peut être bloquée par Connection2. Cette situation peut se produire car Connection1 souhaite mettre à jour une ligne dans une page où Connection2 a déjà inséré une ligne.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

À ce stade, Connection2 peut même être bloquée par Connection1, entraîne un blocage. Cette situation peut se produire lorsque Connection2 souhaite mettre à jour une ligne dans une page où Connection1 a inséré une ligne. Voici la trace de blocage :
   97/04/20 15:48:21.18 spid20   *** DEADLOCK DETECTED with spid 19 ***
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x2c4, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0xc48, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 405 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 60
				

Ce blocage peut être évité en répartissant les lignes sur différentes pages. L'un méthode pour ce faire consiste à recréer l'index ordonné en clusters sur cette table avec un facteur de remplissage de grande taille. Voici une instruction qui crée un index ordonné en clusters avec un facteur de remplissage de 50 pour cent :
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 50, PAD_INDEX
				

Cette instruction crée l'index ordonné en clusters en laissant la moitié des pages vides, notamment les niveaux non-feuille de l'index ordonné en clusters (en raison de l'option PAD_INDEX). La table occupe double la taille réelle et le nombre de lignes par page est la moitié des valeurs qu'elles avaient.

Le facteur de remplissage n'est pas maintenue sur une table ; la table est réorganisée avec le facteur de remplissage spécifié uniquement pendant la phase de création d'index. Au fil du temps, les lignes par page transforme le facteur de remplissage spécifié lors de la création d'index. Dans ce cas, il peut s'avérer utile pour recréer l'index ordonné en clusters avec le facteur de remplissage souhaité.

Une autre solution pour éviter la situation d'interblocage précédente consiste à remplir la table contenant les colonnes factices (par exemple, dummy1 char(255)). Ceci augmente la taille de la ligne et entraîne moins de lignes par page (seulement une ligne par page). Ce type de remplissage étant mises à jour au fil du temps, il est inutile de recréer l'index ordonné en clusters pour maintenir la marge intérieure (même si vous souhaitez recréer l'index ordonné en clusters pour d'autres raisons). L'inconvénient de cette technique est gaspillage de l'espace de stockage sur des champs factices.

Exemple 5: Remplissage des lignes

Remplissage des lignes entraîne moins de lignes par page (donc moins de blocages), mais il va élimine pas complètement les blocages.

Dans ce tableau, exemple1 est rempli d'occuper une ligne par page. Les instructions utilisées pour créer la table pour cet exemple sont les suivantes :
   create table example1 (column1 int, column2 char(20), column3 char(50),
   dummy_column4 char (255), dummy_column5 char (255), dummy_column6 char
   (255))
   go
   create unique index ex1ind5 on example1 (column3, column2, column1,
   dummy_column4, dummy_column5, dummy_column6) with fill factor = 85
   go
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 401
   and column2 = 'AAAA'
				

À ce stade, Connection1 est bloqué par Connection2 lors de la mise à jour de la ligne. Parce que SQL Server doit conserver des pointeurs de chaîne de pages, il verrouille la page précédente, la page suivante et la page qui est mis à jour. Étant donné que Connection2 détient un verrou sur la page précédente, Connection1 doit attendre que Connection2 valide la transaction.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 101
   and column2 = 'AAAB'
				

À ce stade, Connection2 est bloqué par Connection1 car il doit verrouiller la page précédente, qui est actuellement verrouillée par Connection1. Il en résulte un blocage. Voici la trace de blocage :
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x12b5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 101 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0x1531, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 401 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 300
				

Ce blocage peut être évité en insérant des lignes factices entre les lignes insérées, mises à jour ou supprimées. Par exemple, si Connection1 fonctionne (insertions, mises à jour ou suppressions) avec ligne pk = 1 et Connection2 fonctionne avec ligne pk = 5, insertion d'une ligne entre ces deux lignes (par exemple une ligne contenant pk = 3) éviter les blocages. Cette méthode augmente la taille de la table mais peut être la meilleure solution pour ces tables de file d'attente critiques pour l'application.

Exemple 6: Les index non ordonnés en clusters

Dans certains cas, index secondaires non ordonnés en clusters peuvent introduire des blocages. Dans cet exemple, la maintenance de l'index secondaire présente un blocage.

Voici l'instruction utilisée pour créer l'index secondaire utilisé dans cet exemple :
   create index ex1ind2 on example1 (column3) with fill factor = 90,
   PAD_INDEX
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCBA', ' ', '
   ', ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (300, 'AAAB', 'CCCZ', ' ', '
   ', ' ', ' ')
   Connection2 > UPDATE example1 SET column3 = 'CCBA' where column1 = 105
				

À ce stade, Connection2 peut être bloqué par Connection1 car Connection1 peut être maintient un verrou sur la page d'index non ordonné en clusters secondaire où Connection2 doit mettre à jour.
   Connection1 > UPDATE example1 SET column3 = 'CCCZ' where column1 = 305
				

À ce stade, Connection1 peut être bloquée par Connection2, ce qui entraîne un blocage. Cette situation peut se produire lorsque Connection1 attend un verrou mettre à jour l'index secondaire non ordonné en clusters où Connection2 a déjà inséré et détient un verrou sur cette page. Voici la trace de blocage pour cet exemple de blocage :
   97/04/20 19:05:38.75 spid11   *** DEADLOCK DETECTED with spid 12 ***
   spid 11 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 12, dbid 6, page 0x112f, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCZ' where column1 = 305
   spid 12 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 11, dbid 6, page 0x1108, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCBA' where column1 = 105
   VICTIM: spid 11, pstat 0x0000 , cputime 50
				

Ce blocage peut être évité en supprimant l'index secondaire. Il n'est pas possible remplir l'index afin de contenir une ligne par page, afin que cette situation peut être évitée uniquement en supprimant l'index secondaire non ordonné en clusters ou en modifiant l'application.

Blocages peuvent se produire avec plus de deux connexions, auquel cas la trace du blocage répertorie les SPID impliquées dans le blocage et également les verrous en conflit. Blocages peuvent se produire avec les verrous RLOCK et XRLOCK, acquises au cours de l'index parcours. Blocages peuvent également se produire en raison de verrous d'étendue (PR_EXT, NX_EXT, UPD_EXT & EX_EXT).

Pour plus d'informations sur l'analyse des blocages, vous pouvez activer les indicateurs de trace suivants :

T1200
Imprime toutes les informations de demande/version de verrouillage lorsqu'il se produit, si un blocage est impliqué ou non. Il est coûteux en termes de performances, mais il peut s'avérer utile pour l'analyse.

T1206
Imprime tous les verrous détenus par les participants SPID dans le blocage.

T1208
Imprime le nom ordinateur hôte et le nom du programme fourni par le client. Cela peut aider à identifier un client impliquée dans un blocage, en supposant que le client spécifie une valeur unique pour chaque connexion.

Propriétés

Numéro d'article: 169960 - Dernière mise à jour: jeudi 16 octobre 2003 - Version: 3.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 6.5 Édition Standard
Mots-clés : 
kbmt kbhowto kbusage KB169960 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 169960
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Exclusion de responsabilité concernant les contenus obsolètes dans la Base de connaissances
Cet article concerne des produits pour lesquels Microsoft n'offre plus de support. Il est par conséquent fourni « en l'état » et ne sera plus mis à jour.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com