Discussion :

[StringBuilder]

Bonjour,

J'ai un programme qui plante lamentablement lors d'un traitement, et je retrouve dans le log le message suivant :

SQL Error State:40001, Native Error Code: 4B5, ODBC Error: [Microsoft][SQL Server Native Client 11.0][SQL Server]La transaction (ID de processus 90) a été bloquée sur les ressources verrou par un autre processus et a été choisie comme victime. Réexécutez la transaction.

J'ai aussi le code SQL de la-dite requête qui a planté :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT  TOP 18 Objekt,Ort,ID,F7021,F7063,F7067 
FROM TE_ISI_OJ 
WHERE LosKZ=0 AND ((((((TE_ISI_OJ.AD2GrpId=100021) OR (TE_ISI_OJ.AD3GrpId=100021) OR (TE_ISI_OJ.F7048=100021) OR (TE_ISI_OJ.F7052=100021) OR (TE_ISI_OJ.F7056=100021) OR (TE_ISI_OJ.F7060=100021)) AND (TE_ISI_OJ.F7080 NOT IN(5,6)) AND (TE_ISI_OJ.F7021!=5) AND ((TE_ISI_OJ.Objektart IN(1,0))))) AND ((((TE_ISI_OJ.ID<>0 AND EXISTS(SELECT ID FROM TE_ISI_OZ WHERE TE_ISI_OJ.ID=ID_OJ AND (TE_ISI_OZ.LosKZ=0 AND ((TE_ISI_OZ.F7001 IN(1,0)))) AND ((EXISTS(SELECT ID FROM TE_ISI_ID WHERE TE_ISI_OZ.BetreuerId<>0 AND TE_ISI_ID.ID=TE_ISI_OZ.BetreuerId AND (TE_ISI_ID.LosKZ=0 AND ((TE_ISI_ID.HierarchyCode LIKE '217.1.5.5.32.7.4.4.1.%'))))))))))))) 
ORDER BY Objekt,Ort;

Évidement, une fois le message obtenu, le process ID 90 n'existe plus !

SQL Server garde-t-il une trace exploitable du pourquoi du comment de quoiqu'est-ce ?

Genre à partir de l'heure et de l'ID du process tué, ai-je moyen de retrouver :
- la liste des process qui ont provoqué le lock
- si possible le code SQL de ces process

Ceci afin d'identifier à quel endroit je me prend les pieds dans le tapis...

Car entre les triggers, les vues, les scripts, les webservices et tout ce qui tourne autour, mon traitement doit faire pas loin (si ce n'est plus) d'une centaine de requêtes de mise à jour sur les mêmes lignes dans un laps de temps de quelques millisecondes, impossible de désactiver chaque truc un à un pour trouver qui me bloque... Et j'ai des merdes du genre un trigger qui appelle un web service qui déclenche en retour des mises à jour à partir d'une autre session et transaction... le truc impossible à tracer

Par contre, la situation est reproductible, systématiquement.

[Invité]

C'est un deadlock, il y a plusieurs moyens de tracer ça.
Il y a plein d'articles sur le sujet, je cite celui-là par exemple :
https://www.mssqltips.com/sqlservert...-how-to-solve/

Si c'est reproductible, c'est vraisemblablement dû à une mauvaise gestion des transactions.

[SQLpro]

Le plus simple est de mettre une trace du profiler capturant les deadlock avec leur graphe. Puis d'utiliser la petite requête que je fournit.

A lire :
https://blog.developpez.com/sqlpro/p...ck-du-profiler

A +

[hmira]

Bonjour,

Une autre solution consiste à utiliser les notifications d'événements, mettant en œuvre le Service Broker, une file d'attente etc.

Une procédure stockée d'activation (ACTIVATION) permettra d'extraire le ou les événement(s) Deadlock de la file d'attente et d'y répondre, par exemple stocker les information de l'événement Deadlock dans une table permanente, envoyer un mail d'alerte etc.

A+

[SQLpro]

Bonjour,

Une autre solution consiste à utiliser les notifications d'événements, mettant en œuvre le Service Broker, une file d'attente etc.

Comme tu dis, etc... lourdingue !

A +

[hmira]

Bonjour SQLPro,

Il faut certes fournir un effort, peut être même un gros effort, pour mettre en œuvre cette mécanique basée la notifications d'événements et le Service Broker.
Mais une fois la mise en œuvre est maitrisée, la mécanique automatisée, personnellement, je préfère cette méthode, et c'est désormais la méthode que j'utilise pour détecter les deadlock, mais je ne veux pas l'imposer aux autres !
Ayant eu l'occasion d'utiliser les deux méthodes, je conviens que la technique que tu proposes est beaucoup plus simple à mettre en œuvre.
Chacune des méthodes a ses avantages et ses inconvénients (simplicité de mise en œuvre, méthode plus ou moins intrusive, etc.), et chacun pourra choisir la méthode qui lui convient le mieux .

A+

[mikedavem]

Personnellement, je suis plus en faveur d'utiliser directement la session d'événement étendue system_health et qui existe par défaut . Cette dernière intègre les deadlocks par défaut. A moins d'avoir un serveur qui produit énormément d'événement en général cela suffit. Sinon activer une autre trace d'événement étendue peut résoudre le problème.

Sinon une bonne trace profiler au niveau serveur ...

Tous ces mécanismes sont intrinsèques, facile à mettre en place et en général avec une emprunte minimale au niveau de l'impact sur les performances.

Question de goût et de couleur

++

[Invité]

Si c'est reproductible, autant passer par le profiler.