Bearbeiten : Gelöst, es gab einen Auslöser mit einer Schleife auf dem Tisch (lies meine eigene Antwort weiter unten).
Wir haben eine einfache Löschanweisung, die folgendermaßen aussieht:
%Vor%Das hängt einfach, keine Zeitüberschreitung, nichts.
Wir haben uns den Ausführungsplan angesehen und er besteht aus vielen Nachschlagevorgängen in verwandten Tabellen, um sicherzustellen, dass keine Fremdschlüssel das Löschen stolpern würden. Wir haben jedoch überprüft, dass keine dieser anderen Tabellen Zeilen enthält, die sich auf dieses Thema beziehen Reihe.
Zu diesem Zeitpunkt ist kein anderer Benutzer mit der Datenbank verbunden.
Wir haben DBCC CHECKDB dagegen ausgeführt und es werden 0 Fehler gemeldet.
Wenn ich mir die Ergebnisse von sp_who und sp_lock anschaue, merke ich, dass mein Spid auch viele PAG- und KEY-Sperren enthält wie die gelegentliche TAB-Sperre.
Die Tabelle hat 1.777.621 Zeilen, und ja, pk ist der Primärschlüssel. Es handelt sich also um eine einzelne Zeilenlöschung basierend auf dem Index. Es gibt keinen Tabellenscan im Ausführungsplan, obwohl ich bemerke, dass er etwas enthält, das Tabellenspool (Eager Spool) sagt, aber Geschätzte Anzahl von Zeilen 1. Kann dies tatsächlich ein Table-Scan sein Verkleidung? Es sagt nur, dass es die Primärschlüsselspalte betrachtet.
DBCC DBREINDEX und UPDATE STATISTICS in der Tabelle wurden versucht. Beide sind innerhalb einer angemessenen Zeit abgeschlossen.
Leider gibt es eine große Anzahl von Indizes für diese bestimmte Tabelle. Es ist die Kerntabelle in unserem System mit vielen Spalten und Referenzen, sowohl ausgehende als auch eingehende. Die genaue Anzahl ist 48 Indizes + der Primärschlüsselclusterindex.
Was sollten wir uns noch ansehen?
Beachten Sie auch, dass dieses Problem in der Tabelle zuvor nicht aufgetreten ist. Dieses Problem ist heute plötzlich aufgetreten. Wir haben auch viele Datenbanken mit der gleichen Tabellenkonfiguration (Kopien von Kundendatenbanken), und sie verhalten sich wie erwartet, es ist nur diese eine, die problematisch ist.
Eine fehlende Information ist die Anzahl der Indizes in der Tabelle, aus der Sie die Daten löschen. Da SQL Server den Primärschlüssel als Zeiger in jedem Index verwendet, müssen für jede Änderung des Primärindex alle Indizes aktualisiert werden. Obwohl, wenn wir nicht eine hohe Zahl sprechen, sollte dies kein Problem sein.
Ich vermute aus Ihrer Beschreibung, dass dies eine Primärtabelle in der Datenbank ist, auf die viele andere Tabellen in FK-Beziehungen verweisen. Dies würde für die große Anzahl von Sperren verantwortlich sein, da es den Rest der Tabellen nach Referenzen prüft. Und wenn Sie kaskadierende Löschungen aktiviert haben, könnte dies zu einem Löschen in Tabelle A führen, das mehrere Tabellen tief überprüft.
Versuchen Sie, den Index für diese Tabelle neu zu erstellen, und versuchen Sie, die Statistiken neu zu generieren.
Ok, das ist peinlich.
Ein Kollege hatte vor einer Weile einen Trigger zu dieser Tabelle hinzugefügt, und der Auslöser hatte einen Fehler. Obwohl er den Fehler behoben hatte, wurde der Auslöser für diese Tabelle nie neu erstellt.
Also hat der Server tatsächlich nichts gemacht, es hat es einfach viele Male gemacht.
Naja ...
Danke für die Augäpfel an alle, die das gelesen haben und über das Problem nachgedacht haben.
Ich werde Josefs Antwort akzeptieren, da seine die engste war, und indirekt das Problem mit den kaskadierenden Löschungen angehen.
Tags und Links sql sql-server sql-server-2005