Blocage lors de la mise à jour de différentes lignes avec un index non clusterisé
Je résous un problème de blocage tandis que je remarquais que le comportement de verrouillage était différent lorsque j'utilisais un index cluster et non cluster sur le champ id. Le problème de blocage semble résolu si l'index ou la clé primaire sécurisée est appliqué au champ id.
J'ai différentes transactions effectuant une ou plusieurs mises à jour sur différentes lignes, par exemple la transaction A ne mettra à jour que la ligne avec ID = a, tx B ne touchera que la ligne avec ID = b etc.
Et j'ai compris que sans index, la mise à jour acquerra un verrou de mise à jour pour toutes les lignes et sera convertie en verrou exclusif si nécessaire, ce qui conduira finalement à un blocage. Mais je n'arrive pas à comprendre pourquoi avec un index non clusterisé, l'impasse est toujours là (bien que le taux de réussite semble être baissé)
Tableau de données:
CREATE TABLE [dbo].[user](
[id] [int] IDENTITY(1,1) NOT NULL,
[userName] [nvarchar](255) NULL,
[name] [nvarchar](255) NULL,
[phone] [nvarchar](255) NULL,
[password] [nvarchar](255) NULL,
[ip] [nvarchar](30) NULL,
[email] [nvarchar](255) NULL,
[pubDate] [datetime] NULL,
[todoOrder] [text] NULL
)
Trace de blocage
deadlock-list
deadlock victim=process4152ca8
process-list
process id=process4152ca8 taskpriority=0 logused=0 waitresource=RID: 5:1:388:29 waittime=3308 ownerId=252354 transactionname=user_transaction lasttranstarted=2014-04-11T00:15:30.947 XDES=0xb0bf180 lockMode=U schedulerid=3 kpid=11392 status=suspended spid=57 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2014-04-11T00:15:30.953 lastbatchcompleted=2014-04-11T00:15:30.950 lastattention=1900-01-01T00:00:00.950 clientapp=.Net SqlClient Data Provider hostname=BOOD-PC hostpid=9272 loginname=getodo_sql isolationlevel=read committed (2) xactid=252354 currentdb=5 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
executionStack
frame procname=adhoc line=1 stmtstart=62 sqlhandle=0x0200000062f45209ccf17a0e76c2389eb409d7d970b0f89e00000000000000000000000000000000
update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@owner
frame procname=unknown line=1 sqlhandle=0x00000000000000000000000000000000000000000000000000000000000000000000000000000000
unknown
inputbuf
(@para0 nvarchar(2)<c/>@owner int)update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@owner
process id=process4153468 taskpriority=0 logused=4652 waitresource=KEY: 5:72057594042187776 (3fc56173665b) waittime=3303 ownerId=252344 transactionname=user_transaction lasttranstarted=2014-04-11T00:15:30.920 XDES=0x4184b78 lockMode=U schedulerid=3 kpid=7272 status=suspended spid=58 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2014-04-11T00:15:30.960 lastbatchcompleted=2014-04-11T00:15:30.960 lastattention=1900-01-01T00:00:00.960 clientapp=.Net SqlClient Data Provider hostname=BOOD-PC hostpid=9272 loginname=getodo_sql isolationlevel=read committed (2) xactid=252344 currentdb=5 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
executionStack
frame procname=adhoc line=1 stmtstart=60 sqlhandle=0x02000000d4616f250747930a4cd34716b610a8113cb92fbc00000000000000000000000000000000
update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@uid
frame procname=unknown line=1 sqlhandle=0x00000000000000000000000000000000000000000000000000000000000000000000000000000000
unknown
inputbuf
(@para0 nvarchar(61)<c/>@uid int)update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@uid
resource-list
ridlock fileid=1 pageid=388 dbid=5 objectname=SQL2012_707688_webows.dbo.user id=lock3f7af780 mode=X associatedObjectId=72057594042122240
owner-list
owner id=process4153468 mode=X
waiter-list
waiter id=process4152ca8 mode=U requestType=wait
keylock hobtid=72057594042187776 dbid=5 objectname=SQL2012_707688_webows.dbo.user indexname=10 id=lock3f7ad700 mode=U associatedObjectId=72057594042187776
owner-list
owner id=process4152ca8 mode=U
waiter-list
waiter id=process4153468 mode=U requestType=wait
Une conclusion connexe intéressante et possible est également que l'index cluster et non cluster semble avoir des comportements de verrouillage différents
Lorsque vous utilisez l'index clusterisé, il existe un verrou exclusif sur la clé ainsi qu'un verrou exclusif sur RID lors de la mise à jour, ce qui est attendu; alors qu'il y a deux verrous exclusifs sur deux RID différents si un index non cluster est utilisé, ce qui m'embrouille.
Serait utile si quelqu'un peut expliquer pourquoi à ce sujet aussi.
Testez SQL:
use SQL2012_707688_webows;
begin transaction;
update [user] with (rowlock) set todoOrder='{1}' where id = 63501
exec sp_lock;
commit;
Avec id comme index clusterisé:
spid dbid ObjId IndId Type Resource Mode Status
53 5 917578307 1 KEY (b1a92fe5eed4) X GRANT
53 5 917578307 1 PAG 1:879 IX GRANT
53 5 917578307 1 PAG 1:1928 IX GRANT
53 5 917578307 1 RID 1:879:7 X GRANT
Avec id comme index non clusterisé
spid dbid ObjId IndId Type Resource Mode Status
53 5 917578307 0 PAG 1:879 IX GRANT
53 5 917578307 0 PAG 1:1928 IX GRANT
53 5 917578307 0 RID 1:879:7 X GRANT
53 5 917578307 0 RID 1:1928:18 X GRANT
EDIT1: Détails du blocage sans aucun index
Disons que j'ai deux tx A et B, chacun avec deux déclarations de mise à jour, ligne différente bien sûr
tx A
update [user] with (rowlock) set todoOrder='{1}' where id = 63501
update [user] with (rowlock) set todoOrder='{2}' where id = 63501
tx B
update [user] with (rowlock) set todoOrder='{3}' where id = 63502
update [user] with (rowlock) set todoOrder='{4}' where id = 63502
{1} et {4} auraient une chance de blocage, car
à {1}, le verrou U est demandé pour la ligne 63502 car il doit effectuer une analyse de table, et le verrou X aurait pu être maintenu sur la ligne 63501 car il correspond à la condition
à {4}, le verrou U est demandé pour la ligne 63501 et le verrou X est déjà maintenu pour 63502
nous avons donc txA détient 63501 et attend 63502 tandis que txB détient 63502 en attente de 63501, qui est une impasse
EDIT2: Il s'avère qu'un bogue de mon cas de test fait une situation différente ici Désolé pour la confusion, mais le bogue fait une situation différente, et semble finalement provoquer l'impasse.
Puisque l'analyse de Paul m'a vraiment aidé dans ce cas, je vais donc accepter cela comme une réponse.
En raison du bogue de mon cas de test, deux transactions txA et txB peuvent mettre à jour la même ligne, comme ci-dessous:
tx A
update [user] with (rowlock) set todoOrder='{1}' where id = 63501
update [user] with (rowlock) set todoOrder='{2}' where id = 63501
tx B
update [user] with (rowlock) set todoOrder='{3}' where id = 63501
{2} et {3} auraient une chance de blocage lorsque:
txA demande le verrouillage U sur la clé tout en maintenant le verrouillage X sur le RID (en raison de la mise à jour de {1}) txB demande le verrouillage U sur le RID tout en maintenant le verrouillage U sur la clé
... pourquoi avec un index clusterisé, le blocage est toujours là (bien que le taux de réussite semble être abandonné)
La question n'est pas précisément claire (par exemple, combien de mises à jour et à quelles valeurs id se trouvent dans chaque transaction) mais un scénario de blocage évident se produit avec plusieurs mises à jour sur une seule ligne au sein d'une même transaction, où il y a un chevauchement de [id] Et les identifiants sont mis à jour dans un ordre [id] Différent:
[T1]: Update id 2; Update id 1;
[T2]: Update id 1; Update id 2;
Séquence de blocage: T1 (u2), T2 (u1), T1 (u1) attente , T2 (u2) attendez .
Cette séquence d'interblocage peut être évitée en mettant à jour strictement dans l'ordre id au sein de chaque transaction (acquisition de verrous dans le même ordre sur le même chemin).
Lorsque vous utilisez l'index clusterisé, il y a un verrou exclusif sur la clé ainsi qu'un verrou exclusif sur RID lors de la mise à jour, ce qui est attendu; alors qu'il y a deux verrous exclusifs sur deux RID différents si un index non cluster est utilisé, ce qui m'embrouille.
Avec un index cluster unique sur id, un verrou exclusif est pris sur la clé de clustering pour protéger les écritures dans les données en ligne. Un verrou exclusif RID distinct est requis pour protéger l'écriture dans la colonne LOB text, qui est stockée sur une page de données distincte par défaut.
Lorsque la table est un tas avec uniquement un index non cluster sur id, deux choses se produisent. Premièrement, un verrou exclusif RID concerne les données de tas en ligne, et l'autre est le verrou sur les données LOB comme précédemment. Le deuxième effet est qu'un plan d'exécution plus complexe est nécessaire.
Avec un index clusterisé et une simple mise à jour de prédicat d'égalité à valeur unique, le processeur de requêtes peut appliquer une optimisation qui effectue la mise à jour (lecture et écriture) dans un seul opérateur, en utilisant un seul chemin:
La ligne est localisée et mise à jour en une seule opération de recherche, ne nécessitant que des verrous exclusifs (aucun verrou de mise à jour n'est nécessaire). Un exemple de séquence de verrouillage à l'aide de votre exemple de table:
acquiring IX lock on OBJECT: 6:992930809:0 -- TABLE
acquiring IX lock on PAGE: 6:1:59104 -- INROW
acquiring X lock on KEY: 6:72057594233618432 (61a06abd401c) -- INROW
acquiring IX lock on PAGE: 6:1:59091 -- LOB
acquiring X lock on RID: 6:1:59091:1 -- LOB
releasing lock reference on PAGE: 6:1:59091 -- LOB
releasing lock reference on RID: 6:1:59091:1 -- LOB
releasing lock reference on KEY: 6:72057594233618432 (61a06abd401c) -- INROW
releasing lock reference on PAGE: 6:1:59104 -- INROW
Avec seulement un index non clusterisé, la même optimisation ne peut pas être appliquée car nous devons lire à partir d'une structure b-tree et en écrire une autre. Le plan à chemins multiples comporte des phases de lecture et d'écriture distinctes:
Cela acquiert des verrous de mise à jour lors de la lecture, se convertissant en verrous exclusifs si la ligne se qualifie. Exemple de séquence de verrouillage avec le schéma donné:
acquiring IX lock on OBJECT: 6:992930809:0 -- TABLE
acquiring IU lock on PAGE: 6:1:59105 -- NC INDEX
acquiring U lock on KEY: 6:72057594233749504 (61a06abd401c) -- NC INDEX
acquiring IU lock on PAGE: 6:1:59104 -- HEAP
acquiring U lock on RID: 6:1:59104:1 -- HEAP
acquiring IX lock on PAGE: 6:1:59104 -- HEAP convert to X
acquiring X lock on RID: 6:1:59104:1 -- HEAP convert to X
acquiring IU lock on PAGE: 6:1:59091 -- LOB
acquiring U lock on RID: 6:1:59091:1 -- LOB
releasing lock reference on PAGE: 6:1:59091
releasing lock reference on RID: 6:1:59091:1
releasing lock reference on RID: 6:1:59104:1
releasing lock reference on PAGE: 6:1:59104
releasing lock on KEY: 6:72057594233749504 (61a06abd401c)
releasing lock on PAGE: 6:1:59105
Notez que les données LOB sont lues et écrites dans l'itérateur de mise à jour de table. Le plan plus complexe et les multiples chemins de lecture et d'écriture augmentent les risques de blocage.
Enfin, je ne peux m'empêcher de remarquer les types de données utilisés dans la définition de la table. Vous ne devez pas utiliser le type de données obsolète text pour de nouveaux travaux; l'alternative, si vous avez vraiment besoin de pouvoir stocker jusqu'à 2 Go de données dans cette colonne, est varchar(max). Une différence importante entre text et varchar(max) est que les données text sont stockées hors ligne par défaut, tandis que varchar(max) stocke en ligne par défaut.
N'utilisez les types Unicode que si vous avez besoin de cette flexibilité (par exemple, il est difficile de voir pourquoi une adresse IP aurait besoin d'Unicode). En outre, choisissez des limites de longueur appropriées pour vos attributs - 255 semble peu probable partout être correct.
Lecture supplémentaire:
Modèles courants d'interblocage et de verrouillage en direct
série de dépannage de blocage de Bart Duncan
Le traçage des verrous peut être effectué de différentes manières. SQL Server Express avec services avancés ( 2014 et 2012 SP1 uniquement ) contient le Outil de profilage , qui est un moyen pris en charge pour afficher les détails de l'acquisition et de la libération du verrou.