Wie zu bestimmen, was in SQL Server kompilieren

Question

Performance-Monitore auf meinem SQL Server 2008 Standard Edition-Installations In Tracking, habe ich bemerkt, dass SQL-Kompilierungen/Sekunde Spikes alle fünf Sekunden oder so von 3 bis etwa 50

Wir haben auch ein relativ hohes Verhältnis von Zusammenstellungen zu Stapelanfragen pro Sekunde. Ich verstehe, dass dies idealerweise ein Verhältnis von 1/10 sein sollte, aber wir arbeiten bei mehr wie 8/10.

Die Datenbank unterstützt eine stark frequentierte Website mit einer Reihe von Anwendungen, so dass es schwierig ist, den Grund für die übermäßige Kompilierung zu bestimmen, insbesondere die 5-Sekunden-Spitzen. Bei fast allen Abfragen handelt es sich um gespeicherte Prozeduraufrufe anstelle von Embedded SQL, und wir verfügen über beträchtlichen Arbeitsspeicher (48 GB).

Gibt es eine Möglichkeit, zu einem gegebenen Zeitpunkt zu sehen, welche Abfragen gerade kompiliert werden? Wenn ja, könnten wir herausfinden, ob es Probleme gibt.

Answer 1

Wenn ich in der Vergangenheit Probleme mit Plan-Caching/übermäßiger Abfrage-Neukompilierung untersuchen musste, habe ich die Anleitung im Microsoft-Whitepaper ‘Plan Caching in SQL Server 2008’ gelesen und empfehle dringend, dies zu lesen, da Plan-Caching, Abfrageplan behandelt wird Wiederverwendung, Ursachen von Neukompilierungen, Identifizierung von Neukompilierungen und andere verwandte Themen.

Mit diesem gesagt, SQL Server Profiler (Sollte unter Microsoft SQL Server 2008 -> Performance Tools, wenn Sie es als Teil Ihrer Client-Tools-Installation installiert) befinden sich drei Ereignisse direkt im Zusammenhang mit Abfrage Kompilierung, die hilfreich sein kann Sie:

• Cursor
  • CursorRecompile
• Leistung
  • Showplan XML für die Suche nach Compile
• Verfahren
  • SP Stored: Recompile

Sie Stored Procedures verwenden, müssen so wahrscheinlich, dass Sie nur über das SP:Recompile Ereignis kümmern. Dieses Ereignis wird immer dann ausgelöst, wenn eine gespeicherte Prozedur, ein Trigger oder eine benutzerdefinierte Funktion neu kompiliert wurde. Die TextData-Spalte zeigt den Text der tsql-Anweisung an, die die Neukompilierung der Anweisung verursacht hat, und die EventSubClass-Spalte zeigt einen Code, der den Grund für die Neukompilierung angibt.

EventSubClass Codes für SP: RECOMPILE in SQL 2008

• 1 = Schema geändert
• 2 = Statistik geändert
• 3 = Recompile DNR
• 4 = Set Option
geändert
• 5 = Temp-Tabelle geändert
• 6 = Remote-Rowset geändert
• 7 = Für Durchsuchen Perms Changed
• 8 = Abfrage geändert Mitteilung Environment
• 9 = MPI Ansicht
• 10 Changed = Cursor Optionen
geändert
• 11 = Mit Recompile Option

Wenn Sie überwachen Anhand der folgenden 5 Ereignisse können Sie sehen, welche gespeicherten Prozeduren und Anweisungen auf dem SQL Server aufgerufen werden und welche die Neukompilierung auslösen:

• Stored Procedures
  • SP: Starten
  • SP: StmtStarting
  • SP:
  • SP Recompile: Abgeschlossen
• Leistung
  • Auto Stats

Ich habe auch normalerweise die Profiler-Trace eingerichtet, um alle Spalten für diese Ereignisse zu erfassen. Ich würde sagen, eine Spur mit diesen 5 Ereignissen einrichten, eine Spur für 30 bis 60 Sekunden laufen lassen und dann anhalten und dann sollten Sie einen guten Schnappschuss von dem haben, was die Rekompilierung verursacht.

Wenn zu viel Rauschen vorhanden ist, können Sie mit dem Hinzufügen von Spaltenfiltern zu den Trace-Eigenschaften beginnen, um In-/Out-Ereignisse zu filtern. Wenn Sie zum Beispiel feststellen, dass die meisten Ihrer Rekompilierungen nur einmal in der Datenbank ausgeführt werden, richten Sie einen Spaltenfilter für die Spalte databaseID oder databaseName ein, sodass nur Abfragen, die für diese Datenbank ausgeführt werden, in Ihrem Trace enthalten sind.

Dann suchen Sie nach Mustern, in denen Abfragen neu kompiliert werden, und verwenden Sie das Whitepaper von Microsoft als eine Anleitung, warum sie die Neukompilierung auslösen könnten.