De temps en temps j'obtiens ce genre de message d'erreur (très très
aléatoire), pourriez vous me dire d'où cela peut provenir, et éventuellement
me donner une solution pour éviter cela.
Voici le message d'erreur complet :
"Microsoft][ODBC SQL Server Driver][SQL Server]La transaction (ID du
processus 58) a été bloquée sur les ressources lock par un autre processus
et a été choisie comme victime. Relancez la transaction. "
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christian Robert
Ca s'appelle un deadlock en anglais çà arrive par exemple quand une transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou écrire les mêmes données... Comme la transaction A bloque les données (lock), la transaction B se voit notifier un refus... D'où le deadlock...
La solution recommencer B plus tard, auquel cas A aura sans doute finis sa tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005 résoud définitivement ce genre de soucis.
Si çà n'est pas très fréquent, çà n'est pas très grave, çà ne doit pas se produire en permanance.
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"Stan Sainte-Rose" a écrit :
Salut,
De temps en temps j'obtiens ce genre de message d'erreur (très très aléatoire), pourriez vous me dire d'où cela peut provenir, et éventuellement me donner une solution pour éviter cela. Voici le message d'erreur complet :
"Microsoft][ODBC SQL Server Driver][SQL Server]La transaction (ID du processus 58) a été bloquée sur les ressources lock par un autre processus et a été choisie comme victime. Relancez la transaction. "
Merci d'avance
Stan
Ca s'appelle un deadlock en anglais çà arrive par exemple quand une
transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou
écrire les mêmes données... Comme la transaction A bloque les données (lock),
la transaction B se voit notifier un refus... D'où le deadlock...
La solution recommencer B plus tard, auquel cas A aura sans doute finis sa
tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005
résoud définitivement ce genre de soucis.
Si çà n'est pas très fréquent, çà n'est pas très grave, çà ne doit pas se
produire en permanance.
------------------------------
Christian Robert
Winwise
MCT - MCDBA - MCSD.Net
"Stan Sainte-Rose" a écrit :
Salut,
De temps en temps j'obtiens ce genre de message d'erreur (très très
aléatoire), pourriez vous me dire d'où cela peut provenir, et éventuellement
me donner une solution pour éviter cela.
Voici le message d'erreur complet :
"Microsoft][ODBC SQL Server Driver][SQL Server]La transaction (ID du
processus 58) a été bloquée sur les ressources lock par un autre processus
et a été choisie comme victime. Relancez la transaction. "
Ca s'appelle un deadlock en anglais çà arrive par exemple quand une transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou écrire les mêmes données... Comme la transaction A bloque les données (lock), la transaction B se voit notifier un refus... D'où le deadlock...
La solution recommencer B plus tard, auquel cas A aura sans doute finis sa tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005 résoud définitivement ce genre de soucis.
Si çà n'est pas très fréquent, çà n'est pas très grave, çà ne doit pas se produire en permanance.
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"Stan Sainte-Rose" a écrit :
Salut,
De temps en temps j'obtiens ce genre de message d'erreur (très très aléatoire), pourriez vous me dire d'où cela peut provenir, et éventuellement me donner une solution pour éviter cela. Voici le message d'erreur complet :
"Microsoft][ODBC SQL Server Driver][SQL Server]La transaction (ID du processus 58) a été bloquée sur les ressources lock par un autre processus et a été choisie comme victime. Relancez la transaction. "
Merci d'avance
Stan
BVesan
Bonjour, Ce message indique simplement que la session est victime d'un DEADLOCK (deux processus qui se bloquent mutuellement parce que chacun attend que l'autre libère un verrou), et que la transaction en cours a été annulée. En jetant un coup d'oeil sur les Books Online de SQL Server ou sur le Net, vous trouverez rapidement des informations sur le méchanisme des DEADLOCKS et certaines pistes pour les éviter.
Bonjour,
Ce message indique simplement que la session est victime d'un DEADLOCK (deux
processus qui se bloquent mutuellement parce que chacun attend que l'autre
libère un verrou), et que la transaction en cours a été annulée. En jetant un
coup d'oeil sur les Books Online de SQL Server ou sur le Net, vous trouverez
rapidement des informations sur le méchanisme des DEADLOCKS et certaines
pistes pour les éviter.
Bonjour, Ce message indique simplement que la session est victime d'un DEADLOCK (deux processus qui se bloquent mutuellement parce que chacun attend que l'autre libère un verrou), et que la transaction en cours a été annulée. En jetant un coup d'oeil sur les Books Online de SQL Server ou sur le Net, vous trouverez rapidement des informations sur le méchanisme des DEADLOCKS et certaines pistes pour les éviter.
BVesan
> Ca s'appelle un deadlock en anglais çà arrive par exemple quand une transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou écrire les mêmes données... Comme la transaction A bloque les données (lock), la transaction B se voit notifier un refus... D'où le deadlock...
L'exemple ci dessus illustre un phénomène d'attente sur verrou, et non pas de deadlock !
La solution recommencer B plus tard, auquel cas A aura sans doute finis sa tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005 résoud définitivement ce genre de soucis.
Les deadlocks sont inhérents à tout SGBDr qui utilise des mécanismes de verrou. Je ne suis pas persuadé que SQL Server 2005 puisse s'en affranchir...
> Ca s'appelle un deadlock en anglais çà arrive par exemple quand une
transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou
écrire les mêmes données... Comme la transaction A bloque les données (lock),
la transaction B se voit notifier un refus... D'où le deadlock...
L'exemple ci dessus illustre un phénomène d'attente sur verrou, et non pas
de deadlock !
La solution recommencer B plus tard, auquel cas A aura sans doute finis sa
tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005
résoud définitivement ce genre de soucis.
Les deadlocks sont inhérents à tout SGBDr qui utilise des mécanismes de
verrou. Je ne suis pas persuadé que SQL Server 2005 puisse s'en affranchir...
> Ca s'appelle un deadlock en anglais çà arrive par exemple quand une transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou écrire les mêmes données... Comme la transaction A bloque les données (lock), la transaction B se voit notifier un refus... D'où le deadlock...
L'exemple ci dessus illustre un phénomène d'attente sur verrou, et non pas de deadlock !
La solution recommencer B plus tard, auquel cas A aura sans doute finis sa tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005 résoud définitivement ce genre de soucis.
Les deadlocks sont inhérents à tout SGBDr qui utilise des mécanismes de verrou. Je ne suis pas persuadé que SQL Server 2005 puisse s'en affranchir...
Christian Robert
Désolé pour l'erreur :o(
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
> Ca s'appelle un deadlock en anglais çà arrive par exemple quand une > transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou > écrire les mêmes données... Comme la transaction A bloque les données (lock), > la transaction B se voit notifier un refus... D'où le deadlock...
L'exemple ci dessus illustre un phénomène d'attente sur verrou, et non pas de deadlock !
> > La solution recommencer B plus tard, auquel cas A aura sans doute finis sa > tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005 > résoud définitivement ce genre de soucis.
Les deadlocks sont inhérents à tout SGBDr qui utilise des mécanismes de verrou. Je ne suis pas persuadé que SQL Server 2005 puisse s'en affranchir...
Désolé pour l'erreur :o(
------------------------------
Christian Robert
Winwise
MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
> Ca s'appelle un deadlock en anglais çà arrive par exemple quand une
> transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou
> écrire les mêmes données... Comme la transaction A bloque les données (lock),
> la transaction B se voit notifier un refus... D'où le deadlock...
L'exemple ci dessus illustre un phénomène d'attente sur verrou, et non pas
de deadlock !
>
> La solution recommencer B plus tard, auquel cas A aura sans doute finis sa
> tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005
> résoud définitivement ce genre de soucis.
Les deadlocks sont inhérents à tout SGBDr qui utilise des mécanismes de
verrou. Je ne suis pas persuadé que SQL Server 2005 puisse s'en affranchir...
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
> Ca s'appelle un deadlock en anglais çà arrive par exemple quand une > transaction A écrit dans une table, et qu'un deuxième (B) essaye de lire ou > écrire les mêmes données... Comme la transaction A bloque les données (lock), > la transaction B se voit notifier un refus... D'où le deadlock...
L'exemple ci dessus illustre un phénomène d'attente sur verrou, et non pas de deadlock !
> > La solution recommencer B plus tard, auquel cas A aura sans doute finis sa > tâche... Il y a d'autres possibilités plus complexes... mais seul SQL 2005 > résoud définitivement ce genre de soucis.
Les deadlocks sont inhérents à tout SGBDr qui utilise des mécanismes de verrou. Je ne suis pas persuadé que SQL Server 2005 puisse s'en affranchir...
