SQL 2005-Deadlocks: Ausführen von Traces und Untersuchen von Protokollen

SQL 2005-Deadlocks: Ausführen von Traces und Untersuchen von Protokollen

Wir haben eine kommerzielle Anwendung eines Drittanbieters, die unserer Meinung nach Deadlocks auf unserem SQL Server 2005-Rechner (64 Bit) verursacht. Nach einer anderthalbtägigen Schulung beim Softwareanbieter letzte Woche, die uns helfen sollte, die Software besser zu verwalten, recherchiere ich jetzt, wie ich SQL Server Profiler und Trace Templates am besten zu meinem Vorteil nutzen kann.

Mein persönliches Motto lautet: „Wenn Sie als Softwareanbieter eine Anwendung entwickeln, für die Sie eine Remote-Verbindung zum Server des Kunden herstellen müssen, dann machen Sie etwas falsch.“ Leider haben wir im Moment keine große Wahl.

Je besser ich diese Leute (Softwareanbieter) kennenlerne, desto weniger beeindruckt bin ich von ihnen – und desto mehr Arbeit „hinter den Kulissen“ möchte ich selbst erledigen. Wir haben beispielsweise seit Monaten Probleme damit, dass der Server immer langsamer wird – aber bis jetzt sehe ich absolut keine Trace-Datei oder Trace-Vorlagendatei auf dem System.

Weiter zu meinen Fragen...

  1. Beeinträchtigt das Ausführen einer Trace-Datei die Serverleistung spürbar? Ich schätze, die Antwort lautet: „Das kommt darauf an.“ Wenn das der Fall ist, sind hier die „Ereignisse“, die ich in der neuen Trace-Vorlage ausgewählt habe, die ich gerade erstellt habe:

    • Deadlock-Diagramm
    • Sperre: Deadlock
    • Schloss: Deadlock-Kette
    • RPC:Abgeschlossen
    • SP:StatementAbgeschlossen
    • SQL:BatchAbgeschlossen
    • SQL:BatchStarten
  2. Müsste eine Ablaufverfolgung ausgeführt werden, bevor der Deadlock tatsächlich auftritt, oder könnte ich die Ablaufverfolgung zu dem Zeitpunkt ausführen, an dem wir einen erheblichen Leistungsabfall bemerken?

  3. Ich lese gerade Tipps und Techniken zum Überprüfen der SQL-Protokolle, da wir diesem Thema bisher nicht viel Aufmerksamkeit geschenkt haben. Wenn ich in SQL Server Management Studio zu Management und SQL Server-Protokollen gehe, kann ich dort nichts finden, das „Deadlock“ / „Deadlocked“ usw. besagt. Vielleicht gibt es also gar keine Deadlocks. Kann mir jemand bestätigen, ob Deadlocks in den SQL-Protokollen auftauchen oder nicht, und wenn ja, welche Suchkriterien ich verwenden kann, um die Einträge zu finden?

Antwort1

Das Ausführen einer Ablaufverfolgung auf einem SQL Server wirkt sich auf den SQL Server aus. Die grundlegende Faustregel lautet, dass alles, was Sie auf dem Server tun, Ressourcen verbraucht. Können Sie Leistungsprobleme verursachen, wenn Sie eine Ablaufverfolgung oder einen SQL Profiler auf dem SQL Server ausführen? Ja, das ist sicher möglich, wenn Sie keine Filterung eingerichtet haben.

Wenn Sie Deadlock-Probleme haben, schalten SieAblaufverfolgungsflags 1204 und 1222Dadurch werden die Informationen zum Deadlock in das Fehlerprotokoll ausgegeben. Lassen Sie diese nicht die ganze Zeit eingeschaltet, da sie die Leistung beeinträchtigen. Die in das Fehlerprotokoll ausgegebenen Informationen geben Ihnen alles über die Anweisungen, die Teil des Deadlocks waren.

Antwort2

Was das Ausführen von Diagnoseprotokollen wieVerfolgenverbraucht es weniger Ressourcen alsProfileraber wie immer hängt die Antwort von Ihren Serverspezifikationen sowie davon ab, wie viel während der normalen Produktion gleichzeitig passiert. Da Sie nur SQL 2005 verwenden, gehe ich davon aus, dass die Hardware etwas in die Jahre gekommen ist, was bedeutet, dass Sie vorsichtig sein sollten, wenn Sie es auf einer Produktionsbox ausführen. Was ohnehin nicht wirklich empfohlen wird, wenn Sie versuchen, ein Problem halb blind oder sogar auf einer brandneuen Box zu beheben.

Zu 2.: Wenn Sie versuchen, etwas zu erfassen, sollten Sie meiner Meinung nach die Diagnose ausführen und dann die Ursache für den Deadlock ermitteln (vorausgesetzt, Sie haben es auf einen bestimmten Grund oder Ereignistyp bei der Anwendung oder nur bei der App im Allgemeinen eingegrenzt).

Bei Nr. 3 kann ich leider nicht viel helfen.

verwandte Informationen