Discussion :

[ocean_78]

Bonjour à toutes et à tous et merci à ceux qui nous aident et font vivre ce forum

Je rencontre des problèmes avec une application, des traitements me génèrent souvent les erreurs ci-dessous et j'aimerai avoir votre avis, la cause de ces deadlocked et quel outil sqlserver utiliser pour m'aider à trouver la source du problème, trace etc

La version sqlserver utilisée et 2008

Je vous remercie par avance

exemple numéro 1 :

J'ai remplacé certaines infos pour raison de confidentialité

An Error has occurred while Executing Query:
UPDATE nom de ma table
SET amount = amount + 0.000000
WHERE client = 'TOTO' AND period = 201003 AND ple_amount > 0.0
AND dim1 = '75-201000145'

ERROR 1205: [Microsoft][SQL Native Client][SQL Server]Transaction (Process ID 173) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
16:13:56 > ERROR 1205: Error in AGRExecSql: Couldn't execute statement when Update funds
16:13:56 > Aborting transaction.

Exemple numéro 2 :

An Error has occurred while Executing Query:
UPDATE a
SET a.apar_name = b.name , a.apar_bank = b.bank_account ,
a.apar_addr = b.address , a.apar_place = b.place ,
a.apar_zipcode = b.zip_code
FROM ##Hxxxx_DEP00000 a , aagaXXXXX b
WHERE b.client = 'TOTO' AND b.dim_value = a.xxxxx AND
b.apar_type = a.apar_type AND b.attribute_id in ( 'xx' ,
'yy' )

ERROR 1205: [Microsoft][SQL Native Client][SQL Server]Transaction (Process ID 243) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Error in UpdateTableId; Table name: ##Hxxxx_DEP00000 avalue: SET a.apar_name = b.name, a.apar_bank = b.bank_account, a.apar_addr = b.address, a.apar_place = b.place, a.apar_zipcode = b.zip_codeindex:

Message:Error in XXXUpdTable: Cannot execute update when xxxxxxxxx

Arrêt du traitement

[SQLpro]

Les deadlock (verrous mortel, étreinte fatale, interblocage...) sont liés aux transactions et ne sont en théorie pas évitable. On peut cependant en réduire leur fréquence en adoptant un style de développement axé sur les points suivants :
1) minimiser la durée de la transaction
a) en la faisant côté serveur SGBDR et non côté client (éviter donc Hibernate et autres saloperie du même genre), les
b) en impliquant moins possible d'ordre SQL
c) en diminuant le niveau d'isolation des transactions (SET TRANSACTION ISOLATION LEVEL...)
...

2) respecter une modélisation relationnelle
a) s'assurer que les formes normales ont été respectées au moins jusqu'à la 3e.
b) faire des tables les plus courtes possible (ne pas faire des tables fourre tout avec 80 colonnes - personnellement à plus de 20 colonnes, je considère que la table est mauvaise)
c) prendre des types de données adéquat et donc éviter le VARCHAR(250) systèmatique par exemple
d) mettre en place des clefs primaire les plus courte possible. A ce sujet l'auto incrément sur un INT est la meilleure des choses.
...

Lisez les articles que j'ai écrit sur l'optimisation : http://sqlpro.developpez.com/optimisation/

Pour débusquer les deadlock, vous pouvez utiliser le profiler SQL et vous trouverez dans la rubrique Lock, les événéments Deadlock, DeadlockChain et DeadlockGraph à suivre.

Bon courage, car la multiplication des deadlock est généralement le signe d'un développement épouvantable : modèle de données sans respect des règles de l'art, type de données inappropriés, style de codage imbécile (par exemple ne pas avoir utilisé les procédures stockées...).

A +

[ocean_78]

Merci à toi pour ta réponse précise et rapide, je vais tracer via sqlprofiler

[ocean_78]

Bonjour, j'ai donc essayer d'installer une trace avec filtres sur les deadlock.

Je me pose la question de savoir comment filtrer si mon logiciel n'utilise pas les procédures stockées, quels evenements prévoir, security audit, sessions, tsql, je ne parle pas de stored procedure puisqu'il porte sur les procédures stockées.
Dois-je laisser de coté les événements et cliquer sur filtres de colonnes et choisir les filtres sur les locks ou n'est-ce pas suffisant.

Autre question, comment arrêter ma trace en cours qui est programmée pendant une semaine, fichier, arreter la trace est grisé.

Je vous remercie par avance pour vos réponses

[dbaffaleuf]

Lorsque tu passe le curseur de la souris sur chaque 'bulle' du graphe, tu dois voir la dernière requête impliquée pour chaque session. cf capture.

[dbaffaleuf]

Autre question, comment arrêter ma trace en cours qui est programmée pendant une semaine, fichier, arrêter la trace est grisé.

1) Vérifier si la trace par défaut est active:

Code :

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

1
2
sp_configure 'default trace enable'
GO

2a) Si run_value est à 1:

Code :

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

1
2
select * from fn_trace_getinfo(null)
GO

Repérer la ou les traceids > 1 (traceid = 1 est la trace par défaut)

Code :

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

1
2
3
4
exec sp_trace_setstatus <traceid>, 0
GO
exec sp_trace_setstatus <traceid>, 2
GO

0 stoppe la trace, et 2 la supprime.

2b) Si run_value=0, considérer toute traceid et opérer comme en 2a)

[ocean_78]

Super merci dbaffaleuf

Donc si je comprends bien il suffit que je trace uniquement en événement Lock et sous événements deadlock graph, lock:deadlock, lock:deadlock chain, lock:timeout
Et cela doit suffire à pister un éventuel problème.

J'ai pu arrêter ma trace en cours avec l'aide des tes commandes, dommage qu'on ne trouve pas ces commandes facilement.

Par contre pour la commande :
sp_configure 'default trace enable'
Il me renvoie un message d'erreur, je vais chercher à quoi cela correspond.
Msg 15123, Level 16, State 1, Procedure sp_configure, Line 51
L'option de configuration*'default trace enable' n'existe pas ou il s'agit d'une option avancée.