Bonjour,

Je suis confronté a un problème depuis plusieurs mois, en effet aléatoirement mes visiteurs peuvent recevoir ces messages :

Microsoft OLE DB Provider for ODBC Drivers
[Microsoft][ODBC SQL Server Driver][SQL Server]La transaction (ID de processus 60) a été bloquée sur les ressources verrou par un autre processus et a été choisie comme victime. Réexécutez la transaction.

Microsoft OLE DB Provider for ODBC Drivers
[Microsoft][ODBC SQL Server Driver][SQL Server]La transaction (ID de processus 69) a été bloquée sur les ressources verrou | tampon de communication par un autre processus et a été choisie comme victime. Réexécutez la transaction.

Ca tourne sous SQL Serveur 2005 Entreprise edition
Avant de poster :
-> J'ai reinstallé completement windows
-> J'ai reinstallé completement SQL serveur

Je me rends compte que ca bloque TOUJOURS sur la même table (TABLE Account) et sur des requêtes différentes (Select, Update...)

Si quelqu'un a une idée elle est la bienvenue!!!!!!

Trés cordialement,
Yannick
 

Salut,

j'ai été confronté à un problème similaire chez un client.

La réponse de Microsoft et cela nous a bien aidé:

   "lors de vos SELECT ajouter des WITH (NOLOCK)"

ex:

SELECT *
FROM table1 WITH (NOLOCK)
INNER JOIN table2 WITH (NOLOCK) ON ....

Depuis nos procèdures ne rencontrent plus de Deadlock et sont plus rapides.

Bonne journée.

Didier

Bonjour,

Le problème qui est rémonté est un deadlock ou un interblocage en français.

C'est 2 processus qui se bloquent de manière permantes, et SQL Server le détecte et tue l'une des tâches.
C'est dans 99,9% un problème de code SQL à modifier, qui provoque ce genre de problèmes.

Sinon les solutions qui marchent :
1. Réexecuter la requête qui s'est faite tué (Ca a 90 % de chances de marcher, Si on retente encore c'est du 99%, etc). On peut faire une bouche avec un timer à prévoir au niveau de l'execution des requêtes.
2. Indexer correctement ses tables. Ca peut parraître hors sujet mais le manque d'index peut provoquer celà.
3. Ordonner l'accès aux tables dans ses requêtes. Quand celà est possible, par ordre alphabétique par exemple et s'y tenir.

Pour le NOLOCK, il est à fuir comme de la peste.
1. Il n'évitera pas tous les problèmes
2. Il risque d'ajouter des erreurs de lecture faussée quasiment indéctectables.

Cordialement
------------
Christian Robert - Winwise
http://blogs.developpeur.org/christian
MVP SQL Server