Discussion :

[KeepItSimple]

Bonjour,

nous avons un sql server 2017 avec une activité assez importante (milliers d'update par heure).
De manière sporadique (quelques fois par jour), nous avons des transactions qui tombent en timeout à cause de lock refusé. Nous avons analysé l'application mais nous n'avons pas trouvé la raison.

De manière à investiguer, est-il possible en cas de lock refusé d'enregistrer "quelque part" (fichier, table, event viewer, ... n'importe où) les instructions en cours qui font qu'un select/update ne peut être effectué ?
(au niveau appli on a un timeout sur select * from table where id in (<valueList>) ).

Merci.

[Boubou2020]

vous pouvez tracer les deadlock en activant le trace flag

DBCC TRACEON(1204)
DBCC TRACEON(1222)

l'information sera stocké dans l'errorlog

Code :

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

EXEC master.dbo.xp_readerrorlog 0, 1, N'deadlock victim=process', NULL, NULL, NULL, N'desc'

[mikedavem]

Est-ce que tu peux définir un lock refusé ? Est-ce qu'il s'agirait de locks en timeout? De deadlocks ?
Comment tu l'identifies à ton niveau pour le moment ?

Si deadlock comme stipulé par Boubou2020 je ne conseille pas d'activer les trace flags car d'une part leur exploitation est compliquée dans le journal des erreurs SQL et d'autre part ils sont par défaut capturés dans la session d'événement étendue system_health avec SQL Server 2017.

++

[SQLpro]

En sus cette méthode est considérée comme obsolète.... Pour les deadlock utilisez le profiler SQL.

Pour le timemout il faut faire une session d'événement étendu en capturant les erreurs :

• 8645
• 17197
• 17830

A +

[KeepItSimple]

@mikedavem:
"Est-ce que tu peux définir un lock refusé ? Est-ce qu'il s'agirait de locks en timeout? De deadlocks ?
Comment tu l'identifies à ton niveau pour le moment ?"
=> au niveau du serveur applicatif

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

statement:

Code :

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

1
2
3
4
5
6
7
8
SELECT * FROM stubbe.UniqueIdentifier (NOLOCK) WHERE Id IN 
(
'QCBDRa1AnqQQFHx00000042403241n9EAA021012007',
'QCBDRa1AnqqVeub00000042403241n9EAA021012007',
'QCBDRa1AnqQW0i400000042403241n9EAA021012007',
'QCBDRa1AnqqX7WN00000042403241n9EAA021012007',
'QCBDRa1AnQQy1Re00000042403241n9EAA021012007'
)

Pour le profiler sql , ca veut dire que je dois le laisser capturer des trucs pendant des heures et espérer que ça arrive assez vite.
Ma question n'est pas ça: est-il possible via une configuration/un trigger/... de générer une trace quand une instruction sql tel update/select/delete renvoie un timeout, trace comprenant la raison du timeout (e.g. l'id de la seconde session/instruction qui a causé le lock), de manière à avoir de quoi investiguer sans devoir lancer à posteriori un profiler et espérer qu'exactement le même souci se produise endéans un temps raisonnable.