Discussion :

[Donpi]

Bonjour,

Voilà, j'ai plusieurs deadlock sur un projet depuis plusieurs jours.
Certains j'ai plus les réglé en changeant légèrement la requête mais pour d'autres c'est une vrai plaie.

J'ai utilisé le profiler et les graphiques de deadlock (un truc génial cela dit en passant) pour identifier ce qui posait problème.

En gros j'ai systématiquement un "Échange" de pages entre deux requêtes toujours sur la même table.
C'est une table de mouvements de stock qui contient ~200 lignes par page.

Et là j'ai plusieurs solutions :
- Utiliser des with(nolock) mais ça me fait trop mal donc je garde comme dernier recours.
- "Défragmenté" les lignes pour que les lignes d'un même contexte se suive et aient plus de probabilités d'être sur la même page (cependant je sais pas du tout comment le faire)
- Forcé le blocage au niveau table par défaut (je ne sais pas non-plus comment le faire)

Quelqu'un a-t-il une autre proposition, ou une piste pour réaliser l'une ou l'autre des miennes ?

A+

[Invité]

• Pour les indexes qui bloquent, changer l'option « Allow page lock » à false
• Créer des indexes pertinents

[Boubou2020]

merci de voir du coté développement essayer de minimiser les longues transaction (avoir des requêtes courtes) tu peux aussi a essayer de changer votre niveau d'isolation


ce ci aussi ne néglige pas que Parfois, un blocage peut être résolu en ajoutant l'indexation

[mikedavem]

Bonjour,

En gros j'ai systématiquement un "Échange" de pages entre deux requêtes toujours sur la même table.
C'est une table de mouvements de stock qui contient ~200 lignes par page.

A+

On pourrait avoir un exemple de requête qui te pose problème?

++

[SQLpro]

De manière générale les deadlocks arrivent quand deux conditions sont réunies :

• des transactions explicites
• l'utilisation d'un même objet par au moins deux transactions

En sus, la fréquence des deadlocks dépend directement de la durée des transactions :

• plus le blocage est long (verrouillage d'index ou de table) plus il y a statistiquement de chances que cela survienne. (phénomène stochastique).

Pour éradiquer globalement les deadlocks il faut :
1) MINIMISER la durée des transactions (par exemple éradiquer les curseurs, travailler uniquement en procédures stockées, rajouter de la RAM, du CPU, des disques plus rapide...)
2) avoir un modèle de données FORTEMENT NORMALISÉ (respecter à la lettre les formes normales 1, 2, 3, BC, 4 et 5)
3) rajouter des INDEX pertinents (analyser ce que demande SQL Server dans sys.dm_db_èmissing_index_details)
4) séquencer les ordres SQL dans le même sens (dans les procédures)
5) s'interdire l'utilisation d'ORM ou de framework dès que le traitement devient un tant soit peu complexe

A +

[elsuket]

Bonjour,

En sus des conseils prodigués par SQLPro :

- pourriez-vous partager un xdl ou une trace, de sorte que nous puissions vous aider plus avant ?
- vous pouvez lire les articles de Bart Duncan et Jonathan Kehayias sur ce sujet
- vous pouvez lire les billets que j'ai posté à ce sujet sur la trace système, l'origine des verrous mortels, et la création de fichiers de trace côté serveur.
- le chapitre 20 du livre que j'ai co-écrit avec SQLPro et Mikedavem peut également vous aider

@++

[Donpi]

Bonjour,

Il n'est difficile de fournir une requête "significative" qui plante car elles sont très variées.
Et le "bottleneck" est dans des triggers.

Dans tout les cas j'ai fais un mix de toutes vos remarques et j'ai commencé par la plus simple.
J'ai créé les indexes demandés par SQL. IL y avait effectivement un gros manque sur un index.
Pour le moment j'ai laisser le "Alow page lock" a actif.

Merci du soutiens, a+