Fortsetzung der Summer Performance Palooza 2013

Am 27. Juni veranstaltete das PASS Performance Virtual Chapter sein Summer Performance Palooza 2013 – eine Art abgespecktes 24-Stunden-PASS, das sich jedoch ausschließlich auf leistungsbezogene Themen konzentrierte. Ich habe eine Sitzung mit dem Titel „10 schlechte Gewohnheiten, die die Leistung zerstören können“ gegeben, in der die folgenden 10 Konzepte behandelt wurden:

1. AUSWÄHLEN *
2. Blind-Indizes
3. Kein Schemapräfix
4. Standard-Cursor-Optionen
5. sp_ Präfix
6. Cache-Bloat zulassen
7. Breite Datentypen
8. SQL Server-Standardeinstellungen
9. Überbeanspruchung von Funktionen
10. "Funktioniert auf meinem Rechner"

Sie erinnern sich vielleicht an einige dieser Themen aus Präsentationen wie meinem Vortrag „Bad Habits and Best Practices“ oder unseren wöchentlichen Query Tuning-Webinaren, die ich mit Kevin Kline von Anfang Juni bis diese Woche veranstaltet habe. (Diese 6 Videos werden übrigens Anfang August auf YouTube verfügbar sein.)

Meine Sitzung hatte 351 Teilnehmer und ich bekam großartiges Feedback. Einiges davon wollte ich ansprechen.

Zuerst ein Konfigurationsproblem:Ich benutzte ein brandneues Mikrofon und hatte keine Ahnung, dass jeder Tastendruck wie Donner klingen würde. Ich habe dieses Problem durch eine bessere Platzierung meiner Peripheriegeräte behoben, aber ich möchte mich bei allen entschuldigen, die davon betroffen sind.

Als nächstes die Downloads; Das Deck und die Proben werden auf der Veranstaltungsseite veröffentlicht. Sie befinden sich unten auf der Seite, aber Sie können sie auch gleich hier herunterladen.

Abschließend folgt eine Liste mit Fragen, die während der Sitzung gepostet wurden, und ich wollte sicherstellen, dass ich alle angesprochen habe, die während der Live-Fragen und Antworten nicht beantwortet wurden. Ich entschuldige mich dafür, dass ich dies in knapp einem Monat hineingequetscht habe , aber es waren viele Fragen, und ich wollte sie nicht in Teilen veröffentlichen.

A: Sie müssen dies von Fall zu Fall angehen, da es wirklich von einer Vielzahl von Faktoren abhängt (einschließlich der Komplexität des Plans). Beachten Sie auch, dass Sie eine Neukompilierung auf Anweisungsebene durchführen können, sodass nur die betroffenen Anweisungen den Treffer erhalten müssen, im Gegensatz zum gesamten Modul. Paul White erinnerte mich daran, dass Leute das Parameter-Sniffing oft mit RECOMPILE „reparieren“. , aber allzu oft bedeutet das WITH RECOMPILE im Stil von 2000 statt der viel besseren OPTION (RECOMPILE) , die sich nicht nur auf die Anweisung beschränkt, sondern auch die Einbettung von Parametern ermöglicht, die WITH RECOMPILE nicht. Wenn Sie also RECOMPILE verwenden Um Parameter-Sniffing zu verhindern, fügen Sie es der Anweisung hinzu, nicht dem Modul.

A: Wie oben wird dies von den Kosten und der Komplexität der Pläne abhängen, und es gibt keine Möglichkeit zu sagen:"Ja, es wird immer einen großen Leistungseinbruch geben." Das musst du auch unbedingt mit der Alternative vergleichen.

A: Ich bin mir nicht sicher, was "in der realen Welt lesbar" bedeutet. Wenn Sie die Ausgabe in einem bestimmten Format wünschen, ist es in der Regel besser, wenn Sie clientseitig in eine Zeichenfolge konvertieren. C# und die meisten anderen Sprachen, die Sie wahrscheinlich auf der Präsentationsebene verwenden, sind mehr als in der Lage, Datums-/Zeitausgaben aus der Datenbank in jedem gewünschten regionalen Format zu formatieren.

A: Die meisten DMVs sind erst seit dem letzten Dienststart gültig, und sogar andere können häufiger geleert werden (sogar auf Anfrage – sowohl versehentlich als auch absichtlich). Der Plan-Cache ist natürlich in ständiger Bewegung, und AFAIK-Pläne, die aus dem Cache herausfallen, behalten ihre vorherige Zählung nicht bei, wenn sie wieder reinkommen. Also, selbst wenn Sie einen Plan im Cache sehen, bin ich nicht 100% zuversichtlich, dass Sie der Anzahl der Verwendungen glauben können, die Sie finden.

Das heißt, was Sie wahrscheinlich suchen, ist sys.dm_exec_cached_plans.usecounts und Sie können auch sys.dm_exec_procedure_stats.execution_count finden um Informationen für Prozeduren zu ergänzen, bei denen einzelne Anweisungen innerhalb der Prozeduren nicht im Cache gefunden werden.

A: Die Hauptsorgen in diesem Zusammenhang sind die Möglichkeit, eine bestimmte Syntax zu verwenden, wie z. B. OUTER APPLY oder Variablen mit einer Tabellenwertfunktion. Mir sind keine Fälle bekannt, in denen die Verwendung einer niedrigeren Kompatibilität sich direkt auf die Leistung auswirkt, aber einige Dinge, die normalerweise empfohlen werden, sind, Indizes neu zu erstellen und Statistiken zu aktualisieren (und Ihren Anbieter dazu zu bringen, die neuere Kompatibilitätsstufe so schnell wie möglich zu unterstützen). Ich habe gesehen, wie es in einer beträchtlichen Anzahl von Fällen unerwartete Leistungseinbußen behoben hat, aber ich habe auch einige Meinungen gehört, dass dies nicht notwendig und vielleicht sogar unklug ist.

A: Nein, zumindest in Bezug auf die Leistung, eine Ausnahme, bei der SELECT * spielt keine Rolle, wenn es innerhalb eines EXISTS verwendet wird Klausel. Aber warum sollten Sie * verwenden? hier? Ich bevorzuge die Verwendung von EXISTS (SELECT 1 ... – Der Optimierer behandelt diese gleich, aber in gewisser Weise dokumentiert er den Code selbst und stellt sicher, dass die Leser verstehen, dass die Unterabfrage keine Daten zurückgibt (selbst wenn sie das große EXISTS übersehen). draußen). Einige Leute verwenden NULL , und ich habe keine Ahnung, warum ich angefangen habe, 1 zu verwenden, aber ich finde NULL auch etwas unintuitiv.

*Hinweis* Sie müssen vorsichtig sein, wenn Sie versuchen, EXISTS (SELECT * innerhalb eines schemagebundenen Moduls:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Sie erhalten diesen Fehler:

Ändern Sie es jedoch in SELECT 1 funktioniert prima. Vielleicht ist das ein weiteres Argument dafür, SELECT * zu vermeiden auch in diesem Szenario.

A: Es gibt wahrscheinlich Hunderte in einer Vielzahl von Sprachen. Wie Namenskonventionen sind Codierungsstandards eine sehr subjektive Sache. Es spielt keine Rolle, welche Konvention für Sie am besten geeignet ist; wenn Sie tbl mögen Präfixe, verrückt! Bevorzugen Sie Pascal gegenüber BigEndian, haben Sie es. Sie möchten Ihren Spaltennamen den Datentyp voranstellen, z. B. intCustomerID , ich werde dich nicht aufhalten. Wichtiger ist, dass Sie eine Konvention definieren und diese *konsequent* anwenden.

Das heißt, wenn Sie meine Meinung wollen, ich habe keinen Mangel an ihnen.

A: Ich kenne keine Pläne, XACT_ABORT zu verwerfen also sollte es weiterhin gut funktionieren. Ehrlich gesagt sehe ich das jetzt nicht mehr sehr oft verwendet, da wir TRY / CATCH haben (und THROW ab SQL Server 2012).

A: Ich habe das nicht getestet, aber in vielen Fällen kann das Ersetzen einer Skalarfunktion durch eine Inline-Tabellenwertfunktion große Auswirkungen auf die Leistung haben. Das Problem, das ich finde, ist, dass das Durchführen dieses Wechsels eine erhebliche Menge an Arbeit auf Systemen bedeuten kann, die vor APPLY geschrieben wurden existierten oder werden immer noch von Leuten verwaltet, die diesen besseren Ansatz nicht angenommen haben.

A: Zwei Dinge fallen mir spontan ein:(1) die Verzögerung hat mit der Kompilierungszeit zu tun oder (2) die Verzögerung hat mit der Datenmenge zu tun, die geladen wird, um die Abfrage zu erfüllen, und wann sie zum ersten Mal von der Festplatte kommen muss und nicht Erinnerung. Für (1) können Sie die Abfrage im SQL Sentry Plan Explorer ausführen, und die Statusleiste zeigt Ihnen die Kompilierzeit für den ersten und die nachfolgenden Aufrufe (obwohl eine Minute dafür ziemlich übertrieben und unwahrscheinlich erscheint). Wenn Sie keinen Unterschied finden, kann es einfach an der Art des Systems liegen:nicht genügend Arbeitsspeicher, um die Datenmenge zu unterstützen, die Sie mit dieser Abfrage in Kombination mit anderen Daten, die sich bereits im Pufferpool befanden, zu laden versuchen. Wenn Sie nicht glauben, dass beides das Problem ist, prüfen Sie, ob die beiden unterschiedlichen Ausführungen tatsächlich zu unterschiedlichen Plänen führen – wenn es Unterschiede gibt, posten Sie die Pläne auf answers.sqlperformance.com und wir sehen uns das gerne an . Tatsächlich kann das Erfassen tatsächlicher Pläne für beide Ausführungen mit dem Plan-Explorer Sie in jedem Fall auch über Unterschiede bei der E/A informieren und dazu führen, dass SQL Server seine Zeit bei der ersten, langsameren Ausführung verbringt.

A: Nein, ich glaube nicht, dass die Einstellung „Für Ad-hoc-Arbeitslasten optimieren“ in diesem Szenario hilfreich sein wird, da Parameter-Sniffing impliziert, dass nachfolgende Ausführungen desselben Plans für unterschiedliche Parameter und mit deutlich unterschiedlichem Leistungsverhalten verwendet werden. Optimize for ad hoc workloads wird verwendet, um die drastischen Auswirkungen auf den Plan-Cache zu minimieren, die auftreten können, wenn Sie eine große Anzahl unterschiedlicher SQL-Anweisungen haben. Es sei denn, Sie sprechen über die Auswirkungen vieler verschiedener Anweisungen, die Sie an sp_executesql senden, auf den Plan-Cache – was nicht als Parameter-Sniffing bezeichnet werden würde – ich denke, mit OPTION (RECOMPILE) zu experimentieren möglicherweise ein besseres Ergebnis erzielen, oder wenn Sie die Parameterwerte kennen, die bei einer Vielzahl von Parameterkombinationen *gute Ergebnisse erzielen, verwenden Sie OPTIMIZE FOR . Diese Antwort von Paul White bietet möglicherweise einen viel besseren Einblick.

A: Sicher, fügen Sie einfach OPTION (RECOMPILE) hinzu im dynamischen SQL-Text:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Ergebnisse:1 Zeile mit Sales.SalesOrderHeader Anfrage.

Wenn nun eine Anweisung im Batch NICHT OPTION (RECOMPILE) enthält , der Plan ist möglicherweise noch im Cache, er kann nur nicht wiederverwendet werden.

DBCC FREEPROCCACHE(0x06.....);