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
Fred BROUARD
En les évitant par des transactions bien gérées => 1) créer une transaction pour toute SP manipulant les données 2) piloter le niveau d'isolation de chaque transaction 3) éviter toute transaction prenant du temps 4) éviter absolument les transactions sur le poste client. 5) manipuler les tables dans les SP et au sens de chaque requête dans un même ordre constant, exemple ordre alphabétique
A +
ARNAUD a écrit:
Bonjour,
Comment résoudre des problèmes de DEADLOCKS?
Merci
Arnaud
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
En les évitant par des transactions bien gérées =>
1) créer une transaction pour toute SP manipulant les données
2) piloter le niveau d'isolation de chaque transaction
3) éviter toute transaction prenant du temps
4) éviter absolument les transactions sur le poste client.
5) manipuler les tables dans les SP et au sens de chaque requête dans un
même ordre constant, exemple ordre alphabétique
A +
ARNAUD a écrit:
Bonjour,
Comment résoudre des problèmes de DEADLOCKS?
Merci
Arnaud
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto:brouardf@club-internet.fr ******************
En les évitant par des transactions bien gérées => 1) créer une transaction pour toute SP manipulant les données 2) piloter le niveau d'isolation de chaque transaction 3) éviter toute transaction prenant du temps 4) éviter absolument les transactions sur le poste client. 5) manipuler les tables dans les SP et au sens de chaque requête dans un même ordre constant, exemple ordre alphabétique
A +
ARNAUD a écrit:
Bonjour,
Comment résoudre des problèmes de DEADLOCKS?
Merci
Arnaud
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
Michel Walsh
Salut,
Delaney suggère:
- pour éviter des DL par cycles, accéder aux ressources de façon consistante. Ainsi, essayer de ne pas avoir une transaction qui update TableA, puis TableB et une autre transaction qui, elle, commence par mettre à jour la TableB puis la tableA.
- pour éviter des DL par isolation, essayer de réduire le niveau d'isolation de la transaction à son strict minimum applicable.
- pour éviter des DL dit de "conversion", sérialiser explicitement l'accès aux ressources. Un exemple de DL de "conversion" est donné par ( noter qu'on demande un REPEATABLE READ ) :
USE pubs SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN SELECT * FROM authors WHERE au_id='172-32-1176' UPDATE authors SET au_lname= 'Updated by ' + CONVERT( varchar, @@spid) WHERE au_id='172-32-1176' COMMIT TRANS
et sa possible correction:
USE pubs SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN SELECT * FROM authors (UPDLOCK) WHERE au_id='172-32-1176' UPDATE authors SET au_lname= 'Updated by ' + CONVERT( varchar, @@spid) WHERE au_id='172-32-1176' COMMIT TRANS
Delaney, "Inside Microsoft SQL Server 2000", en parle pendant une vingtaine de pages, ceci n'est qu'un succint résumé, il va de soi. Et c'est sans compter la détermination du choix de la victime du DL ( par défaut, le processus le moins onéreux à reflouer (RollBack) ) et le monitoring. Une référence à consulter, à mon bien humble avis.
Espérant être utile, Vanderghast, Access MVP
"ARNAUD" wrote in message news:d4a601c3ef13$32f770c0$ Bonjour,
Comment résoudre des problèmes de DEADLOCKS?
Merci
Arnaud
Salut,
Delaney suggère:
- pour éviter des DL par cycles, accéder aux ressources de façon
consistante. Ainsi, essayer de ne pas avoir une transaction qui update
TableA, puis TableB et une autre transaction qui, elle, commence par
mettre à jour la TableB puis la tableA.
- pour éviter des DL par isolation, essayer de réduire le niveau
d'isolation de la transaction à son strict minimum applicable.
- pour éviter des DL dit de "conversion", sérialiser
explicitement l'accès aux ressources. Un exemple de DL de "conversion" est
donné par ( noter qu'on demande un REPEATABLE READ ) :
USE pubs
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
SELECT * FROM authors WHERE au_id='172-32-1176'
UPDATE authors SET au_lname= 'Updated by '
+ CONVERT( varchar, @@spid) WHERE au_id='172-32-1176'
COMMIT TRANS
et sa possible correction:
USE pubs
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
SELECT * FROM authors (UPDLOCK) WHERE au_id='172-32-1176'
UPDATE authors SET au_lname= 'Updated by '
+ CONVERT( varchar, @@spid) WHERE au_id='172-32-1176'
COMMIT TRANS
Delaney, "Inside Microsoft SQL Server 2000", en parle pendant une vingtaine
de pages, ceci n'est qu'un succint résumé, il va de soi. Et c'est sans
compter la détermination du choix de la victime du DL ( par défaut, le
processus le moins onéreux à reflouer (RollBack) ) et le monitoring. Une
référence à consulter, à mon bien humble avis.
Espérant être utile,
Vanderghast, Access MVP
"ARNAUD" <anonymous@discussions.microsoft.com> wrote in message
news:d4a601c3ef13$32f770c0$a601280a@phx.gbl...
Bonjour,
- pour éviter des DL par cycles, accéder aux ressources de façon consistante. Ainsi, essayer de ne pas avoir une transaction qui update TableA, puis TableB et une autre transaction qui, elle, commence par mettre à jour la TableB puis la tableA.
- pour éviter des DL par isolation, essayer de réduire le niveau d'isolation de la transaction à son strict minimum applicable.
- pour éviter des DL dit de "conversion", sérialiser explicitement l'accès aux ressources. Un exemple de DL de "conversion" est donné par ( noter qu'on demande un REPEATABLE READ ) :
USE pubs SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN SELECT * FROM authors WHERE au_id='172-32-1176' UPDATE authors SET au_lname= 'Updated by ' + CONVERT( varchar, @@spid) WHERE au_id='172-32-1176' COMMIT TRANS
et sa possible correction:
USE pubs SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN SELECT * FROM authors (UPDLOCK) WHERE au_id='172-32-1176' UPDATE authors SET au_lname= 'Updated by ' + CONVERT( varchar, @@spid) WHERE au_id='172-32-1176' COMMIT TRANS
Delaney, "Inside Microsoft SQL Server 2000", en parle pendant une vingtaine de pages, ceci n'est qu'un succint résumé, il va de soi. Et c'est sans compter la détermination du choix de la victime du DL ( par défaut, le processus le moins onéreux à reflouer (RollBack) ) et le monitoring. Une référence à consulter, à mon bien humble avis.
Espérant être utile, Vanderghast, Access MVP
"ARNAUD" wrote in message news:d4a601c3ef13$32f770c0$ Bonjour,
