Discussion :

[Marco46]

* Bonjour, *

Lors de l'exécution d'une requête SELECT je prends une erreur 1222 ayant pour description "Délai de requête de verrou dépassé.".

Une transaction a échoué précédemment.
Pourtant, la table impliquée dans le SELECT ne fait pas parti de la transaction !

La requête suivante :

Code :

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

SELECT * FROM sys.dm_tran_locks WHERE request_owner_type = 'TRANSACTION'

Renvoi plusieurs enregistrements alors que l'application ne fonctionne pas forcément.

Comment supprimer ces blocages ?

* Merci *

[zinzineti]

Une méthode de contournement

1.) Obtenir la valeur actuelle du paramètre LOCK_TIMEOUT, à l'aide de la commande

Code :

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

SELECT @@LOCK_TIMEOUT

2.) augmenter le delai du timeout à l'aide de LOCK_TIMEOUT X

(X est le nombre de millisecondes ).


Exemple
--------
pour fixer le delai du timeout à 3 secondes il faut exécuter

Code :

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

SET LOCK_TIMEOUT 3000

[kagemaru]

salut

@Etienne :

Utilisation du lock_timeout : c'est un peu la méthode de l'autruche ;-) Ma requête est bloquée, ce n'est pas normal mais ce n'est pas grave car elle renvoie une erreur 1222 au bout de N secondes. Donc ces erreurs apparaîtront toujours.

Et c'est bien le soucis dans ce cas : une application .NET a par un timeout défaut qu'il faut corriger dans le code (connection.CommandTimeout (30 sec par défaut) avec .NET). C'est une aberration, et je rencontre ce soucis sur un grand nombre d'applis qui n'ont pas forcément un code à toute épreuve. Donc l'appli sort une erreur 1222 car la requête a mis plus de 30 sec à s'exécuter. Il faut donc positionner ce paramètre à 0 (temps d'exécution sans limite), malgré les conseils de Microsoft de faire l'autruche ;-).

Une erreur 1222 indique un problème grave qu'il faut résoudre.

Quand ta requête est bloquée, utilises donc la vue sys.dm_exec_requests pour afficher la liste des requêtes en cours d'exécution et repère celles pour lesquelles le blocking_session_id > 0.

Le numéro de ce champs indique le numéro de session de la session qui bloque.

Ensuite tu peux essayer d'afficher le code SQL de cette requête avec
DBCC INPUTBUFFER(<blocking_session_id>) ou utiliser une commande pour afficher l'utilisation des verrous (sp_lock par ex).

Il faudrait alors poster les commandes qui s'entrebloquent.

[zinzineti]

Salut Emmanuel,
Mais j'ai proposé "Une méthode de contournement" ;-) allez disons plutôt une méthode de l'autruche ;-)

Sinon sur le fond je suis d'accord ;-)

A+

[Marco46]

La première proposition de solution est inappropriée car comme vous le dites vous mêmes, elle ne fait que masquer le problème.

L'exécution de cette requête :

Code :

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

SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id > 0

Ne donne aucun résultat. En enlevant la condition il y a quelques résultats.

Ceci dit, mon chef m'indique qu'il a mis en place un backup quotidien de la BDD qui s'exécute en soirée. Et ce matin je n'ai plus le problème de blocage. Disparu !

Je continuerai ce fil lorsque le problème ce représentera après exécution de la requête ci-dessus.

Sinon le LOCK_TIMEOUT est par défaut à -1 sur cette base.

Merci pour votre aide.

[elsuket]

Bonjour,

Vous pouvez regarder ce billet et pour une vue plus générale, celui-ci

@++