SUPPRIMER la Déclaration se bloque sur SQL Server pour aucune raison apparente

Question

Modifier:Résolu, il a été un déclencheur avec une boucle sur la table (lire ma propre réponse ci-dessous).

---

Nous avons un simple delete qui ressemble à ceci:

DELETE FROM tablename WHERE pk = 12345

Cela se bloque, pas de délai d'attente, ni rien d'autre.

Nous avons examiné le plan d'exécution, et il se compose de nombreuses recherches sur les tables pour s'assurer qu'aucune des clés étrangères serait le voyage jusqu'à la supprimer, mais nous avons vérifié qu'aucun de ces autres tables ont toutes les lignes en se référant à la ligne particulière.

Il n'y a aucun autre utilisateur connecté à la base de données à ce moment.

Nous avons exécutez DBCC CHECKDB contre elle, et il indique 0 erreurs.

En regardant les résultats de sp_who et sp_lock tandis que la requête est suspendu, je m'aperçois que mon spid a beaucoup de PAG et de serrures à CLÉS, ainsi que les occasionnels ONGLET de verrouillage.

La table a 1.777.621 lignes, et oui, pk est la clé primaire, c'est donc une seule ligne à supprimer, après l'index.Il n'y a pas de table de balayage dans le plan d'exécution, mais je remarque qu'il contient quelque chose qui dit Table De Bobine (Eager Spool), mais, dit-Estimation du nombre de lignes 1.Cela peut effectivement être une table-scan dans le déguisement?Il dit seulement qu'il regarde la colonne de clé primaire.

Essayé de DBCC DBREINDEX et mise à JOUR des STATISTIQUES sur la table.Tous les deux terminé dans un délai raisonnable.

Il n'y a malheureusement un grand nombre d'index dans cette table particulière.C'est le noyau de la table dans notre système, avec beaucoup de colonnes, et de références, à la fois entrant et sortant.Le nombre exact est de 48 index + la clé primaire de l'index cluster.

Quoi d'autre devrions-nous regarder?

Notez également que ce tableau n'a pas eu ce problème avant, ce problème s'est produit soudainement aujourd'hui.Nous avons également beaucoup de bases de données avec la même table de configuration (copies des bases de données clients), et ils se comportent comme prévu, c'est juste ce qui est problématique.

Answer 1

Une information manque, c'est le nombre d'indices sur la table que vous êtes en train de supprimer les données.Que SQL Server utilise la Clé Primaire comme un pointeur dans chaque indice, toute modification de l'index primaire nécessite une mise à jour tous les index.Cependant, à moins que nous parlons d'un grand nombre, cela ne devrait pas être un problème.

Je devine, à partir de votre description, que c'est une primaire de la table dans la base de données référencé par de nombreuses autres tables dans FK relations.Ceci expliquerait le grand nombre de verrous car il vérifie le reste de la tables de références.Et, si vous avez les suppressions en cascade allumé, cela pourrait conduire à une suppression dans une table nécessitant des vérifications de plusieurs tables de profondeur.

Answer 2

Essayez de recréer l'index sur la table, et essayez de régénérer les statistiques.

DBCC RÉINDEXER

MISE À JOUR DES STATISTIQUES

Answer 3

Ok, c'est embarrassante.

Un collègue avait ajouté un trigger de la table il y a un moment, et le déclencheur avait un bug.Bien qu'il ait corrigé le bug, le déclencheur n'avait jamais été recréé pour cette table.

Afin que le serveur était en fait à ne rien faire, il a juste fait un grand nombre de fois.

Eh bien...

Merci pour les yeux à tous ceux qui lisent ceci et réfléchi sur le problème.

Je vais accepter Josef réponse, comme sa a été le plus proche, et indirectement thouched sur la question avec les suppressions en cascade.