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
Version imprimable
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
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?
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+
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
,Citation:
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.
Si tu veux savoir depuis quand elles tournent, je te conseille d'utiliser sp_whoisactive : http://whoisactive.com/downloads/
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+
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...Citation:
Envoyé par hmira
A +
Vous pouvez utiliser la requête que j'ai donné dans cet article :
https://blog.developpez.com/sqlpro/p...stance-bloquee
pour déterminer quelle sont les sessions à annuler en premier.
A +
Oui c'est exact. Merci SQLPro pour cette précision. Il manquait aussi de la ponctuation dans ma phrase initiale.Citation:
Envoyé par SQLpro
Il fallait je crois que je reformule comme ceci :
"Par défaut, les demandes de verrous sur les ressources, émises par les transactions SQL Server, n'ont pas de délai d'expiration.
A moins que LOCK_TIMEOUT ne soit activé (1), la transaction qui demande un verrou sur une ressource est bloquée, elle est en attente de la libération de ce verrou détenu par une autre transaction. 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....."
ET rappeler aussi comme tu l'as fait justement :
"Les transactions elle-mêmes n'ont pas de délai d'expiration, en d'autres termes, une transaction n'a en pratique aucune limite de temps et il n'existe aucun moyen permettant de limiter dans le temps la durée d'une transaction".
J'espère que cette fois-ci il n' y a pas d'erreur et c'est clair pour tout le monde ;)
Merci.
A+