Führen Sie einen bestimmten tatsächlichen Abfrageplan erneut aus

Ich habe einen tatsächlichen Abfrageplan für eine bestimmte Abfrage erfasst.

Danach habe ich einige Dinge geändert (einschließlich der Aktualisierung der Statistiken) und diese spezielle Abfrage erneut ausgeführt. Jetzt ist der eigentliche Abfrageplan anders (was Sinn macht).

Die Abfrage läuft jetzt viel schneller. Ich bin gespannt, ob der neue Ausführungsplan etwas damit zu tun hat, da andere Änderungen (Änderungen am E / A-Setup, VM-Einstellungen, Neustart der SQL-Instanz usw.) ebenfalls zu einer Leistungsverbesserung führen können. Um dies zu testen, möchte ich die Abfrage erneut ausführen und versuchen, SQL Server zu zwingen, den alten Ausführungsplan zu verwenden.

Frage : Gibt es eine Möglichkeit, eine Abfrage mit einem vom Benutzer bereitgestellten Ausführungsplan erneut auszuführen oder sogar eine Abfrage direkt aus einem solchen Plan auszuführen?

Folgendes habe ich versucht, um dies herauszufinden:

Ich habe in den Büchern gesucht, die wir im Büro zur Verfügung haben ( Professional SQL Server 2012-Interna und Fehlerbehebung , Abfragen von Microsoft SQL Server 2012 ).
Google-Suchanfragen, z. B. "Abfrage basierend auf einem bestimmten Abfrageplan ausführen"
DBA.SE sucht beispielsweise nach "Abfrageplan ausführen" und "Ausführungsplan erneut ausführen".
Und schließlich eine, die meine Fragen schon oft beantwortet hat: Überprüfen Sie sorgfältig "Fragen, die möglicherweise bereits beantwortet wurden", bevor Sie auf "Frage posten" klicken :-)

Fazit: Ist das möglich? Wenn das so ist, wie?

sql-server sql-server-2012 execution-plan

— Jeroen
quelle

Ich habe Folgendes verwendet, um lange und kurze Abfragen auf meinen Entwicklungs- und Testsystemen zu überprüfen. Löschen Sie dann die vorhandenen Pläne, Puffer und Caches und führen Sie die Abfrage (n) mit aktivierter Ablaufverfolgung aus. Verwenden von dbcc drop / free-Funktionen zum Löschen der Sitzung, des Caches, der Puffer usw. und zum Deaktivieren oder Deaktivieren des Trace. Unabhängig, aber hilfreich ist es, zu sehen, was mit den Daten in der Tabelle zu tun hat. Bitte beachten Sie, dass ich gesehen habe, dass Sie S2K12 verwendet haben, sodass diese Refs übereinstimmen sollten. Das Verhalten kann in früheren Versionen von SQL Server abweichen. Hoffe das hilft. DBCC FREESYSTEMCACHE, DROPCLEANBUFFERS, Trace On, show_statistics usw.

— Ray Porrata

Ja.

Du brauchst den USE PLANHinweis.

In dem liefern Sie die XMLaus dem ersten Plan.

SELECT *
FROM T
OPTION (USE PLAN N'<?xml version="1.0" encoding="utf-16"?> ....')

Dies garantiert zwar nicht, dass der Plan genau derselbe ist (z. B. können sich beispielsweise skalare Operatoren bewegen), ist aber wahrscheinlich ziemlich nah.

— Martin Smith
quelle

Danke, genau das, wonach ich gefragt habe. (Leider habe ich ein neues Problem: " Ein Abfrageplan konnte nicht gefunden werden, da das Optimierungsprogramm die Anzahl der zulässigen Vorgänge bei der Suche nach dem im USE PLAN-Hinweis angegebenen Plan überschritten hat. ", Aber das ist wohl ein weiteres Problem.)

— Jeroen

@ Jeroen - Hmmm. Ich bin mir nicht sicher, ob es dafür Abhilfe gibt. Vielleicht gibt es ein Trace-Flag, das diese Grenze erhöhen würde, aber wenn ja, weiß ich es nicht!

— Martin Smith

Kein Problem, danke für Ihre Hilfe auf jeden Fall: Heute etwas Neues gelernt! : D

— Jeroen

@Jeroen - Möglicherweise undokumentierter TF 8780, der das Zeitlimit für Optimierer deaktiviert ? Ich bin mir nicht sicher, ob dies den gewünschten Effekt haben würde.

— Martin Smith