Discussion :

[samirCA007]

bonjour a tous

Si je suis devant ce scénario de blocage (deadlook)

avec quel SPID Je doit commencer l'opération kill

kill 53 ou kill 68 ou celle du 79 ? je ne sais pas qui attend qui

merci pour vos explication

[janlouk]

Tout d'abord tu n'es pas face à un Deadlock mais à un blocked process. Car un deadlock est tué toutes les 5 secondes.

C'est quoi le 68?

[hmira]

La session 53 est bloquée par la session n° 68
La session 79 est bloquée par la session n° 53

Plus généralement,
- La colonne session_id représente l'ID de la session" associée à la tâche en attente de certaines ressources.
- La colonne blocking_session_id représente l'ID de la session qui bloque la demande de ressource.

Maintenant que vous êtres au clair, pour le "Kill" plusieurs choix s'offrent à vous, et ce, en fonction de la session que vous voulez interrompre (la session "victime")
par exemple :
- un kill 53 préservera les sessions 79 et 68
- un kill 68 préservera et déloquera les sessions 53 et par ricochet la session 79

A+

[aieeeuuuuu]

Bonjour,

Et pour résumer et compléter les deux réponses, vu qu'il ne s'agit en effet pas de deadlock, n'effectuer aucun kill devrait préserver les trois sessions.

Du coup, la question de janlouk reste ouverte

C'est quoi le 68?

,
ou plutôt que fait-elle ? Même si elle est longue, il est possible de la laisser terminer, ce qui devrait débloquer les autres.

Enfin au final le choix dépend du contexte et du besoin.

[janlouk]

Si tu veux savoir depuis quand elles tournent, je te conseille d'utiliser sp_whoisactive : http://whoisactive.com/downloads/

[hmira]

Les remarques de janlouk et de aieeeuuuuu concernant les deadLock et les Kill (kill qui dans le cas présent ne sont pas nécessaires ), sont très justes et je n’aurais pas dû vous suggérer de faire des Kill Session (mea cupla !).

L'interblocage (deadlock) est souvent confondu avec le blocage ordinaire (blocked process). Lorsqu'une transaction demande un verrou sur une ressource verrouillée par une autre transaction, elle attend que le verrou soit libéré. Par défaut, les transactions SQL Server n'ont pas de délai d'expiration, à moins que LOCK_TIMEOUT ne soit activé (1). La transaction qui demande le verrou est bloquée. La transaction qui détient le verrou va finir par se terminer et libérer le verrou. La transaction en attente pourra alors obtenir son verrou et s'exécuter normalement.

(1) ATTENTION : Modifier le paramètre LOCK_TIMEOUT peut avoir des conséquences très grave si les applications ne gèrent pas correctement les erreurs 1222. En effet, le paramètre LOCK_TIMEOUT permet à une application de définir la durée maximale pendant laquelle une instruction reste en attente sur une ressource bloquée. Si l'attente d'une instruction dépasse la valeur du paramètre LOCK_TIMEOUT, l'instruction bloquée est automatiquement annulée (ATTENTION "annulé" ne signifie pas faire ROLLBACK !), et le message d'erreur 1222 (Lock request time-out period exceeded) est retourné à l'application. Toute transaction contenant la commande n'est toutefois pas restaurée (c.à.d. il n'y a pas forcément un ROLLBACK) ou annulée par SQL Server. L'application doit donc posséder un gestionnaire d'erreurs capable d'intercepter le message d'erreur 1222. Si une application ne gère pas cette erreur, elle peut continuer en ignorant que l'une des instructions de la transaction a été annulée. Des erreurs, y compris les erreurs fonctionnelles, métiers, peuvent se produire lorsque les instructions ultérieures dans la transaction dépendent de l'instruction qui n'a jamais été exécutée.

L'implémentation d'un gestionnaire d'erreurs qui intercepte le message d'erreur 1222 permet à une application de prendre les mesures conséquentes au délai d'expiration, par exemple soumettre à nouveau l'instruction qui été bloquée ou restaurer toute la transaction (c.à.d. effectuer un ROLLBACK).

A+

[SQLpro]

...Par défaut, les transactions SQL Server n'ont pas de délai d'expiration, à moins que LOCK_TIMEOUT ne soit activé (1). ...

Non... ce paramètre ne sert qu'à attendre l'acquisition du premier verrou et ne contrôle pas la durée de la transaction qui n'a en pratique aucune limite et aucune possibilité de limiter...

A +