Problème de verrouillage de la base de données

Question

Pls. nous avons obtenu un LOT de verrous sur une base de données de production qui a récemment été témoin d'une augmentation substantielle du trafic. Nous utilisons IdeaBlade pour la plupart des accès aux données.

j'ai eu la trace suivante à l'aide du Générateur de profils:

deadlock victim="process84af28" 
    resource-list 
    keylock hobtid="72057594096451584" dbid="6" objectname="cpc_db.dbo.Prefix_ChildTableName" indexname="PK_Prefix_ChildTableName" id="lock45982ac0" mode="X" associatedObjectId="72057594096451584" 
     owner-list 
owner id="processb852e8" mode="X" 
    owner-list 
    waiter-list 
    waiter id="process84af28" mode="S" requestType="wait" 
    waiter id="processb855b8" mode="RangeS-U" requestType="wait" 
    waiter-list 
    keylock 
    keylock hobtid="72057594096451584" dbid="6" objectname="cpc_db.dbo.Prefix_ChildTableName" indexname="PK_Prefix_ChildTableName" id="lock513c3bc0" mode="RangeS-U" associatedObjectId="72057594096451584" 
    owner-list 
    owner id="processb855b8" mode="RangeS-U" 
    owner-list 
    waiter-list 
    waiter id="processb852e8" mode="RangeS-U" requestType="wait" 
    waiter-list 
    keylock 
resource-list 
deadlock 

Idées anyone?

Je ne suis pas un DBA, mais cette trace semble indiquer que:

1. Un processus avec un verrou exclusif X sur une ligne dans le tableau de l'enfant tente d'acquérir un verrou Sélectionnez Mise à jour sur la même ressource (ne semble pas logique)

2. un autre processus avec un verrou Sélectionnez Mise à jour tente toujours d'acquérir un verrou Sélectionnez Mise à jour

Clarifications une nyone? Comment peut-on minimiser ou éliminer les blocages?

Answer 1

mode="RangeS-U"

serrures Range? Arrêtez d'utiliser des niveaux d'isolation de transaction élevés. S'en tenir à lire commited. Si vous utilisez l'objet CLR TransactionScope, faites-les utiliser l'isolation Read Commited (par défaut, ils utilisent Seralizable, beurk). Essayez d'activer l'isolement instantané de lecture sur la base de données. Voir Using Snapshot Isolation.

Answer 2

Couple de choses à noter d'abord:

1. Vous utilisez serializable transactions, la forme la plus restrictive de verrouillage pessimiste. Les chances sont, vous n'avez pas besoin de cela (nous savons que vous utilisez des transactions sérialisables car les verrous KEY ne s'appliquent qu'à ce niveau d'isolation). Comme Remus mentionne ci-dessus, vous devriez certainement regarder dans d'autres options ici le plus probable.

2. Il semble que la sortie ci-dessus a été tronqué un peu, vous devriez avoir des sections appelées liste de processus avec informations de mappage des informations de processus SPID et requêtes

D'après ce que vous pouvez dire à la sortie ci-dessus:

processb852e8 owns an exclusive lock on index "cpc_db.dbo.Prefix_ChildTableName.PK_Prefix_ChildTableName" 
    process84af28 is waiting for a shared KEY lock 
    processb855b8 is also waiting for a Shared Range-Update KEY lock 

processb855b8 owns Shared Range-Update lock on index "cpc_db.dbo.Prefix_ChildTableName.PK_Prefix_ChildTableName" (the same index) 
    processb852e8 is waiting on a Shared Range-Update KEY lock 

le verrou exclusif est une écriture d'une sorte (par exemple la mise à jour, supprimer, insérer), les serrures Ranges-U est probablement une mise à jour, mais aucun moyen de dire sans voir les informations cartographiées. Bart Duncan a quelques excellents articles sur le déchiffrement de la sortie de trace si vous avez tout, voir part 1 et part 2. Vous pouvez également voir une vue d'ensemble de la concurrence et des scripts en général here.

Answer 3

le coupable semble être: -

owner id="processb855b8" mode="RangeS-U" 

Cela semble avoir verrouillé un ensemble de lignes. Il attend qu'une ligne soit générée par process84af28, qui attend qu'une ligne soit générée par processb852e8 qui attend qu'une ligne soit libérée par le premier processus. SQLServer est en train de résoudre le blocage en supprimant le processus au milieu, ce qui permet aux deux autres de se terminer.

Vous devriez examiner vos niveaux d'isolation. La meilleure pratique consiste à utiliser le niveau de verrouillage le plus bas disponible lors de la "sélection" de plusieurs lignes. N'utilisez un niveau supérieur sur une ligne "select" que si vous êtes très susceptible de mettre à jour la ligne dans la transaction en cours.

Et JAMAIS, ne laissez jamais une ligne verrouillée en attendant un service externe ou une action de l'utilisateur.

Answer 4

J'ai vu ce problème d'interblocage moi-même avec un produit différent (pas IdeaBlade). Dans mon expérience, ce n'est pas un problème de base de données; c'est probablement un problème avec le logiciel communiquant avec la base de données.

Mes problèmes concernaient la configuration des composants communiquant avec la base de données.

La première fois, COM + par défaut à SERIALIZABLE et a dû être configuré par défaut à READ COMMITTED. La deuxième fois, une condition d'interopérabilité COM + vers .NET a entraîné la connexion par défaut de la base de données à SERIALIZABLE. Pour nous, une solution rapide et sale consistait à préfixer les commandes SQL avec "SET TRANSACTION ISOLATION LEVEL READ COMMITTED" pour remplacer SERIALIZABLE jusqu'à ce que le problème principal puisse être résolu.