Discussion :

[rocketter]

Bonjour,

depuis peu ayant des deadlock sous sql server 2000, j'ai activé le suivi détaillé des deadlock via DBCC TRACEON (3605,1204,-1) mais savez vous comment interpréter ces logs par contre ?

[rocketter]

par exemple celui ci :

spid4 Node:1
spid4 PAG: 7:1:198648 CleanCnt:3 Mode: SIU Flags: 0x2
spid4 Grant List 0::
spid4 Owner:0x445d4160 Mode: S Flg:0x0 Ref:0 Life:00000001 SPID:110 ECID:0
spid4 SPID: 110 ECID: 0 Statement Type: UPDATE Line #: 1
spid4 Input Buf: RPC Event: sp_executesql;1
spid4 Grant List 1::
spid4 Requested By:
spid4 ResType:LockOwner Stype:'OR' Mode: IX SPID:109 ECID:0 Ec0x32385518) Value:0x68f94080 Cost0/0)
spid4
spid4 Node:2
spid4 PAG: 7:1:198648 CleanCnt:3 Mode: SIU Flags: 0x2
spid4 Grant List 0::
spid4 Grant List 1::
spid4 Owner:0x67d7bd60 Mode: S Flg:0x0 Ref:0 Life:00000001 SPID:109 ECID:0
spid4 SPID: 109 ECID: 0 Statement Type: UPDATE Line #: 1
spid4 Input Buf: RPC Event: sp_executesql;1
spid4 Requested By:
spid4 ResType:LockOwner Stype:'OR' Mode: IX SPID:110 ECID:0 Ec0x2D20F518) Value:0x77b076a0 Cost0/0)
spid4 Victim Resource Owner:
spid4 ResType:LockOwner Stype:'OR' Mode: IX SPID:110 ECID:0 Ec0x2D20F518) Value:0x77b076a0 Cost0/0)

[SQLpro]

SIU = Shared Intent Update (verrou d'intention de modif)
IX = Intent eXclusif (verrou d'intention d'exclusivité)
Les verrous d'intention sont des verrous transitoites pour passer d'un mode à l'autre (Shared vers eXclusif par exemple)
PAG = adresse de la page (n°base, N° fichier, N° page dans le fichier) 7:1:198648
SPID = n° de processus 109 et 110 se sont bloqués.
Le Victim Resource Owner: est celui qui a été tué.

Un DBCC PAGE sur 1:198648 dans la base considérée devrait vous donner l'objet (table ou index) puis si c'est un index, la table...

A +

[elsuket]

Bonjour,

Un peu plus de détails : pour voir les résultats s'afficher dans la console d'Enterprise Manager, exécutez DBCC TRACEON (3604).

Une fois ce drapeau de trace activé, vous pouvez exécuter DBCC PAGE (7, 1, 198648, 3)

Dans le résultat que vous allez voir apparaitre, il devrait y avoir un objectid et un indexid, que vous devriez pouvoir retrouver dans la table système sys.sysindexes (respectivement colonnes id and indid).

Si vous ne les trouvez pas, donnez nous la sortie de l'exécution de l'instruction DBCC PAGE.

@++

[rocketter]

Ok merci je vais essayer ça et vous tenir au courant, j'ai pu exécuter le DBCC TRACEON (3604) mais je n'ai pas les droits pour le DBCC PAGE, je vais demander à notre prestataire.
Les résultats du DBCC TRACEON (3604) apportent plus de détails ?

Par contre ce qui risque d'être compliqué à résoudre, c'est que dans logs, les noeuds diffèrent, ce n'est pas toujours PAG: 7:1:198648

[rocketter]

Autre petite question, dans le DBCC PAGE (7, 1, 198648, 3) ; le 3 fait référence à CleanCnt:3 dans le log ou pas du tout ?

[mikedavem]

Le 3 est une option de formatage d'affichage de la commande DBCC PAGE.

3 signifie que tu auras un affichage de l'entête de la page + détail par ligne de données

++

[rocketter]

merci mikedavem

sinon j'ai dans sysindexes avec l'id de l'objet et de l'index (id index à 0) obtenu avec le DBCC PAGE, le nom de la table concernée via la colonne name, après y a-t-il d'autres infos intéressantes que je peux avoir ?

le résultat DBCC Page :

BUFFER:
-------

BUF @0x010E3580
---------------
bpage = 0x4CD1C000 bhash = 0x00000000 bpageno = (1:228481)
bdbid = 7 breferences = 1 bstat = 0x9
bspin = 0 bnext = 0x00000000

PAGE HEADER:
------------

Page @0x4CD1C000
----------------
m_pageId = (1:228481) m_headerVersion = 1 m_type = 1
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8000
m_objId = 217155919 m_indexId = 0 m_prevPage = (0:0)
m_nextPage = (0:0) pminlen = 44 m_slotCnt = 74
m_freeCnt = 335 m_freeData = 7997 m_reservedCnt = 0
m_lsn = (40060:5010:537) m_xactReserved = 0 m_xdesId = (0:0)
m_ghostRecCnt = 0 m_tornBits = 621875329

Allocation Status
-----------------
GAM (1:2) = ALLOCATED SGAM (1:3) = NOT ALLOCATED
PFS (1:226464) = 0x44 ALLOCATED 100_PCT_FULL DIFF (1:6) = NOT CHANGED
ML (1:7) = NOT MIN_LOGGED

[rocketter]

Personne pour me répondre ?

[SQLpro]

Il faudrait maintenant savoir quels sont les transactions qui ont générés le verrou mortel, les tables en jeu (structure) et l'indexation de ces tables.

A +

[rocketter]

Dans input buf la requête retournée est un update, il n'y a qu'une table concernée et aucun index sur cette table. Après je ne sais pas s'il y a d'autres infos pertinentes à prendre.
J'ai remarqué qu'en supprimant d'anciennes données dans cette table (elle était à 500 000 lignes, maintenant à 4000 lignes) ; plus de deadlock. Pourtant 500 000 me parait peu comme valeur pour envisager un partitionnement non ? serait ce ma version de sql serveur 2000 peut-être ?

[SQLpro]

Le nombre de ligne n'a pas un lien direct avec la survenance d'un deadlock.

En revanche il a un lien indirect....

Statistiquement la possibilité d'un deadlock croit avec la durée du verrouillage. Plus la quantité de données à verrouiller est importante, plus la durée du verrou augmente, et plus la possibilité d'un deadlock apparait.

Enfin sachez que sans transaction EXPLICITE, pas de deadlock...

Postez le DDL de votre table AVEC SES INDEX et la requête UPDATE.
Sans doute avec un bon index minimiserons nous la possibilité de survenance d'un verrous mortel.

A +

[rocketter]

Puis je vous envoyer les données en MP ?

[SQLpro]

Je suis trop occupé... Je donne un cours sur SQL en ce moment et intervient aux poses ou lorsque es stagiaires travaillent !

A +

[mikedavem]

On ne peut pas avoir ces infos sur le forum ? Ca éviterait à SQLPro de devoir s'en occuper à la pause de ses formations

++

[rocketter]

Arf non désolé je ne préfère pas

[elsuket]

Bonjour,

j'ai dans sysindexes avec l'id de l'objet et de l'index (id index à 0) obtenu avec le DBCC PAGE

Ceci signifie que la table sous-jacente n'est pas indexée : l'index cluster a toujours l'id 1, et les index non-cluster un id plus grand que 1.
Donc de toute évidence, l'UPDATE n'est pas supporté par un index

@++