Untersuchung von hohen SQL-Wartezeiten, insbesondere LCK_M_U

7

Vor kurzem hatte ich Probleme mit der Leistung von SQL Servern, und obwohl wir eine Vielzahl grundlegender Fehler in der Konfiguration behoben haben, ist die Leistung immer noch schlecht. Zur Verdeutlichung handelt es sich nicht um die Gesamtleistung, sondern um ziemlich häufige Zeitüberschreitungen (von der Client-Anwendung). Früher hatte ich die Erinnerung als Ursache angesehen, aber dies wurde jetzt behoben und wir bekommen immer noch das gleiche Verhalten.

Wenn ich mir die Grafiken aus dem Management Data Warehouse ansehe, kann ich sehen, dass LCK_M_U / X / IX den größten Teil unserer Wartezeiten verursacht, wenn ein Benutzer eine Zeitüberschreitung erfährt. Alles, was ich lese, besagt, dass ich mir die laufenden Abfragen und Prozesse ansehen muss, aber ich muss noch etwas finden, das auf ein Niveau abzielt, das ich verstehen kann. Wie Sie im Bild unten sehen können, scheinen die Sperren zu spitzen, was mit dem Fehler auf der Benutzerseite zusammenfällt. Gibt es eine clevere DMV oder eine solche, die ich ansprechen kann, um herauszufinden, welche Abfrage ausgeführt wird, die die Sperre erstellt? Geht es darum, eine Spur zu durchsuchen, um die Details zu finden? Jede Anleitung wird sehr geschätzt und entschuldigt sich, wenn die Informationen nicht klar sind.

Geben Sie hier die Bildbeschreibung ein

sql-server-2008 performance wait-types Tim Alexander
quelle
1
Welche Datenbanken befinden sich auf diesem Server? Ist es eine einzelne Datenbank oder viele? Was sind die Zugriffsmuster (OLTP / DW)? Meine erste Reaktion ist, dass in einem Teil der App ein großer Lese- oder Schreibvorgang ausgeführt wird (fehlender Index?) Und andere Benutzer warten müssen, um Änderungen an den Daten vorzunehmen (auch bekannt als Blockierung). Dieser Beitrag auf meinem Blog kann für den Hintergrund von Interesse sein: Volunteerdba.com/post/2013/01/22/…
Jon Seigel

Antworten:

4

Das Sammeln von Daten aus sp_WhoIsActive in einer Tabelle ist eine gute Technik, um Blockierungs- und Sperrprobleme aufzuspüren.

Der Parameter @get_locks kann verwendet werden, wenn Sie die Details der beteiligten Sperren anzeigen möchten. Alternativ erfassen @get_task_info und @get_additional_info normalerweise genug, um die Ursache zu identifizieren.

Wenn die gesammelten Ergebnisse nicht klar genug sind, um das Problem zu verstehen, können Sie Ihre Frage anhängen.

Mark Storey-Smith
quelle
7

Schlösser neigen dazu, Ketten zu bilden, und Sie sind immer hauptsächlich daran interessiert, was der Prozess am Kopf der Kette tut. Das einfache Betrachten der Wartezeiten für Sperren kann irreführend sein, da viele Prozesse lange warten können (wodurch sich die Statistiken für Wartezeiten erhöhen), aber alle durch einen einzigen langsamen Prozess blockiert werden. Was Sie wahrscheinlich sehen, ist ein Zusammenführungspunkt: Da gewährte Sperren mit allen aktuellen Berechtigten und allen ausstehenden Kellnern kompatibel sein müssen, wenn eine übergeordnete Sperre (X oder SCH_M) in die Warteschlange für eine Ressource gelangt, stehen alle nachfolgenden Anforderungen dahinter .

Um ein Beispiel zu nennen: Angenommen, Sie haben eine Abfrage, die einen Bericht für eine Tabelle ausführt. Angenommen, es dauert 5 Minuten. Es hält eine IS-Sperre auf dem Tisch. Dieser IS ist kompatibel mit allen normalen Vorgängen (Lesen und Schreiben). Es kommt eine Anfrage, die SCH_M will. Ist mit dem IS nicht kompatibel, wird er in die Warteschlange gestellt. Jetzt werden plötzlich alle anderen Aktivitäten auf dem Tisch in die Warteschlange gestellt, da alle Anfragen, Lese- oder Schreibvorgänge mit diesem Kellner nicht kompatibel sind. Also plötzlich spitzen sich alle Sperrzeiten. Nach 5 Minuten ist die langsame Abfrage beendet (sie wird im DB-Jargon "abgelassen"), das SCH_M wird gewährt, es erledigt seine Arbeit in 5 ms und alle anderen können fortfahren. Dies ist nur ein (extremes) Beispiel, es muss nicht SCH_M sein. Die Idee ist, dass Wartezeiten nicht die ganze Geschichte erzählen.

Glücklicherweise kann SQL Server selbst Blockierungsketten über eine fast unbekannte Funktion namens melden blocked process threshold. Wenn Sie blockierte Prozessberichte und DDL-Ereignisbenachrichtigungen einmischen, erhalten Sie eine vollautomatische Lösung.

Ein Beispiel finden Sie in meiner Antwort unter MS SQL Server-Tools zur Überwachung der Transaktionsblockierung von Drittanbietern .

Eine weitere Beobachtung: Sie haben 22,30% Wartezeiten auf IX. Dies impliziert, dass eine Sperre auf Objektebene aufgetreten ist. Absichtssperren (IS, IX) sind kompatibel. Die Tatsache, dass IX blockiert wurde, deutet darauf hin, dass jemand eine inkompatible Sperre auf Objektebene erworben hat. Ein Scan, der ein S erwirbt, oder ein großes Update, das zu X eskaliert.

Remus Rusanu
quelle