Discussion :

[Kagami]

bonjour je suis responsable débutante d'une application , elle est assez compliquée , application de gestion de pharmacie . bref .. le pharmacien à reçu un message d'erreur et a contacté notre société , et puisque c est moi qui suis chargée de cette app , je dois voir d'où vient ce problème .
voila le message d'erreur :
"La transaction (ID de processus 52) a été bloquée sur les ressources verrou par un autre processus et a été choisie comme victime. Réexécutez la transaction."
j ai cherché sur internet , on dit qu'il faut installer un SQL Server 2000 Service Pack 4 , je veux prendre de risque et l installer , en plus de ça la pharmacie a l 'ancien serveur MSDE Manager ,
d’après ce qu on m'a informé , le problème apparaît lorsque deux poste essaient de faire une opération de vente.
merci de m'aider je suis vraiment coincée et je n sais pas quoi dire sur ça
MERCI

[mikedavem]

Hello,

Je pense qu'il y a de fortes changes que ton problème se situe plus au niveau du code de l'application avec 2 transactions qui arrivent à un deadlock (2 transactions qui se bloquent et qui ne peuvent plus sortir de cette situation).

As-tu la maitrise du code de ton application ?
Il faudrait pouvoir récupérer les informations du deadlock en question avec l'aide d'une trace par exemple et corriger en fonction

A+

[Kagami]

je connais l étape dans l application où l erreur se produit mais quand j fais la trace tout est normal , j ai même débogué et je ne n'ai rencontré aucun problème , mon code et trop long (plusieurs classe , plusieurs méthodes et procédures stockée surtout, forms..)

[Kagami]

le problème c est que si je veux voir cette erreur et comment elle se produit je dois me rendre à la pharmacien où est installé l'application sur les deux postes , plus , ils n'ont pas SQL SERVER , plutôt UN SERVEUR MSDE MANAGER il n y a pas de sql profiler pour tracer l'erreur et tout, c 'est pourquoi je dois analyser le code tout entier (envers les 9000 lignes) c'est quelque chose d’incroyable.
s'il vous plait si vous avez une autre idée sur ça j en sera très reconnaissante .
MERCI

[mikedavem]

Tu peux tout à fait préparer un Template de trace coté serveur et l'exécuter sur ton serveur SQL. Tu récupères le fichier trace que tu peux analyser ensuite via tes outils.

++

[Kagami]

tu peux s'il te plait m'expliquer en détail cette opération , bien sûr si tu n'es pas retenu par autre chose .
MERCI

[elsuket]

Bonjour,

Je vous propose de lire l'article que j'ai écrit sur le sujet. Dans votre cas, ne cochez que l'événement Deadlock Graph, et arrêtez vous à la fin de l'étape III.

Changez la portion de code suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
-- Create a Queue
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 5 
 
-- Please replace the text InsertFileNameHere, with an appropriate
-- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension
-- will be appended to the filename automatically. If you are writing from
-- remote server to local drive, please use UNC path and make sure server has
-- write access to your network share
 
exec @rc = sp_trace_create @TraceID output, 0, N'InsertFileNameHere', @maxfilesize, NULL

Par celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
-- Create a Queue
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 1024
 
exec @rc = sp_trace_create @TraceID output, 0, N'C:\MonDossier\ma_trace', @maxfilesize

On change la taille du fichier à 1024Mo, et on précise où le fichier de trace va être stocké

Chaque événement de deadlock / étreinte mortelle sera donc enregistré dans le fichier de trace. Vous pouvez ensuite l'ouvrir une fois que vous l'aurez, à l'aide de SQL Profiler : vous obtiendrez alors un graphe qui décrit le code exécuté, les ressources mises en jeu, et vous verrez quel processus a été tué. Si vous faites un clic droit sur la ligne qui représente l'événement, vous pouvez choisir d'extraire les données sous la forme d'un fichier xdl, qui est interprétable aussi par SQL Server Management Studio.

Un peu de lecture sur SQL Profiler, avec le livre de Brad McGehee sur le sujet.

Enfin, même si le Service Pack 4 n'est pas la source de votre problème à priori, il est quand même bon de considérer son installation

@++