it-swarm.com.de

Trace Flag 4199 - Global aktivieren?

Dies mag unter die Kategorie der Meinung fallen, aber ich bin gespannt, ob Leute Trace-Flag 4199 als Startparameter für SQL Server verwenden. Unter welchen Umständen haben Sie bei denjenigen, die es verwendet haben, eine Regression der Abfrage festgestellt?

Es scheint sicherlich ein potenzieller Leistungsvorteil auf ganzer Linie zu sein. Ich denke darüber nach, es global in unserer Nicht-Produktionsumgebung zu aktivieren und es ein paar Monate lang stehen zu lassen, um Probleme ausfindig zu machen.

Werden die Korrekturen in 4199 2014 (oder 2016) standardmäßig in den Optimierer übernommen? Obwohl ich den Fall verstehe, dass keine unerwarteten Planänderungen eingeführt werden, scheint es seltsam, all diese Korrekturen zwischen den Versionen verborgen zu halten.

Wir verwenden 2008, 2008R2 und hauptsächlich 2012.

20
FilamentUnities

Persönlich aktiviere ich TF4199 immer global, wenn ich einen neuen Server für ein neues Projekt baue. Gleiches gilt, wenn ich vorhandene Instanzen auf neuere Versionen aktualisiere.

Der TF ermöglicht neue Korrekturen, die sich auf das Verhalten der Anwendung auswirken würden. Bei neuen Projekten ist das Risiko einer Regression jedoch kein Problem. Bei Instanzen, die von früheren Versionen aktualisiert wurden, sind die Unterschiede zwischen der alten und der neuen Version für sich genommen ein Problem, und es wird ohnehin erwartet, dass die Planregression behandelt werden muss. Daher bevorzuge ich es, mit TF4199 zu kämpfen.

In Bezug auf vorhandene Datenbanken gibt es nur einen Weg, dies zu wissen: Testen Sie es. Sie können eine Arbeitslast des vorhandenen Setups erfassen und nach dem Aktivieren des Flags erneut abspielen. RML-Dienstprogramme können Ihnen dabei helfen, den Prozess zu automatisieren, wie in diese Antwort beschrieben.

Offensichtlich wirkt sich das Flag auf die gesamte Instanz aus, sodass Sie alle dort befindlichen Datenbanken testen müssen.

21
spaghettidba

Meine Suche nach dem Thema hat mich hierher gebracht, daher möchte ich nur meine jüngsten Erfahrungen zu diesem Thema mitteilen.

Ich habe SQL 2014 ausgeführt, also dachte ich mir, dass ich mich nicht ein bisschen um 4199 kümmern müsste ... aber es stimmte einfach nicht ...

So diagnostizieren Sie, wenn Sie 4199 benötigen

Wenn Ihre Abfrage anscheinend schlecht ausgeführt wird, insbesondere wenn Sie der Meinung sind, dass dies nicht der Fall sein sollte, fügen Sie am Ende Folgendes hinzu, um festzustellen, ob das Problem behoben ist alle Ihre Probleme, wie Sie möglicherweise benötigen 4199 ("Alle Korrekturen für das Abfrageoptimierungsprogramm aktivieren.")

SELECT SomeColumn
FROM SomeTable    
OPTION(QUERYTRACEON 4199)

In meiner Situation hatte ich eine Top-10-Klausel, die eine Abfrage in die Luft jagte, die ohne lief, was mich glauben ließ, dass etwas faul war, und dass 4199 helfen könnte.

Ungefähr 4199

Alle SQL Server Query Optimizer-Fehler-/Leistungskorrekturen, die nach der neuen Hauptversion erstellt werden, werden tatsächlich ausgeblendet und blockiert. Dies ist für den Fall, dass sie tatsächlich einem anderen theoretisch perfekt optimierten Programm schaden könnten. Installieren Sie die Updates so, wie Sie möchten. Die tatsächlichen Änderungen des Abfrageoptimierers sind standardmäßig nicht aktiviert. Sobald eine einzelne Korrektur oder Verbesserung durchgeführt wurde, wird 4199 daher zu einer Notwendigkeit, wenn Sie davon profitieren möchten. Wenn viele Korrekturen angezeigt werden, werden Sie diese möglicherweise aktivieren, wenn eine davon Sie betrifft. Diese Fixes sind normalerweise an ihre eigenen Trace-Flags gebunden, aber 4199 wird als Master "Jedes Fix einschalten" verwendet.

Wenn Sie wissen, welche Korrekturen Sie benötigen, können Sie sie anstelle von 4199 aktivieren. Wenn Sie alle Korrekturen aktivieren möchten, verwenden Sie 4199.

Ok, du willst also 4199 global ...

Erstellen Sie einfach einen SQL Agent-Job, der jeden Morgen mit der folgenden Zeile ausgeführt wird, um das Trace-Flag global zu aktivieren. Dies stellt sicher, dass sie wieder eingeschaltet werden, wenn jemand sie ausschaltet oder so weiter. Dieser Jobschritt hat ziemlich einfaches SQL:

DBCC TRACEON (4199, -1);

Wobei -1 den globalen Teil in DBCC TRACEON angibt. Weitere Informationen finden Sie unter:

https://msdn.Microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396

Abfragepläne "neu kompilieren"

Bei meinem letzten Versuch musste ich 4199 global aktivieren, und dann auch vorhandene zwischengespeicherte Abfragepläne entfernen:

sp_recompile 'dbo.SomeTable'

https://msdn.Microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396

Wenn die gespeicherte Prozedur zum erneuten Kompilieren Abfragepläne für das Datenbankobjekt (z. B. eine Tabelle) findet und diese Abfragepläne löscht, muss beim nächsten Versuch eine ähnliche Abfrage ausgeführt werden, um sie zu kompilieren.

In meinem Fall hat 4199 verhindert, dass fehlerhafte Abfragepläne erstellt wurden, aber ich musste auch diejenigen entfernen, die noch über sp_recompile zwischengespeichert wurden. Wählen Sie eine beliebige Tabelle aus der bekannten betroffenen Abfrage aus, und Sie sollten diese Abfrage erneut versuchen, vorausgesetzt, Sie haben 4199 jetzt global aktiviert und den fehlerhaften zwischengespeicherten Abfrageplan gelöscht.

Fazit zu 4199

Wenn Sie Indizes verwenden, wird eine intelligente Abfrageplanoptimierung wichtig, um diese Indizes tatsächlich intelligent zu verwenden. Unter der Annahme, dass im Laufe der Zeit einige Korrekturen für den Abfrageoptimierungsprozess veröffentlicht werden, befinden Sie sich im Allgemeinen in sicherem Wasser, um nur mit 4199 global aktiviertem System ausgeführt zu werden. Solange Sie feststellen, dass ein neuer Fix mit einer hochoptimierten Datenbank, die in der vorherigen Umgebung vor dem Fix so optimiert wurde, möglicherweise nicht so gut funktioniert. Aber was macht 4199? Es werden nur alle Korrekturen aktiviert.

7
Greg

Ich wollte meine Erfahrungen mit Trace Flag 4199 teilen.

Ich habe gerade die Diagnose eines Leistungsproblems auf einem Kundensystem mit SQL Server 2012 SP3 abgeschlossen. Der Kunde verschob eine Berichtsdatenbank von seinem Produktionsserver OLTP Server auf einen neuen Server. Ziel des Kunden war es, die Konkurrenz um Ressourcen mit den Abfragen OLTP) zu beseitigen. Leider sagte der Kunde, der neue Berichtsserver sei sehr langsam.

Eine Beispielabfrage, die auf dem System OLTP] ausgeführt wurde, wurde in 1,6 Sekunden abgeschlossen. Der Abfrageplan führte eine Indexsuche für eine Zeilentabelle mit ~ 200 Millionen Zeilen durch, die Teil einer Ansicht war.

Auf dem neuen Server wurde dieselbe Abfrage in 10 Minuten und 44 Sekunden abgeschlossen. Es wurde ein Index-Scan für dieselbe ~ 200 Millionen Zeilentabelle durchgeführt.

Die Berichtsserverdaten waren eine Kopie der OLTP -Daten), sodass es keinen Unterschied in den Daten zu geben schien.

Ich war ratlos, bis ich mich daran erinnerte, dass unsere Software (die ihr OLTP System) ausführt) beim Start einige Trace-Flags aktiviert hat. Einer von ihnen, 4199, war ein Fix für das Abfrageoptimierungsprogramm.

Ich habe das Aktivieren des Ablaufverfolgungsflags 4199 auf dem neuen Berichtsserver des Kunden getestet und die Berichtsabfrage in 0,6 Sekunden abgeschlossen. (Wow!) Ich habe das Trace-Flag deaktiviert und die Abfrage war in 10 Minuten und 44 Sekunden wieder abgeschlossen. Flag aktiviert: zurück auf 0,6 Sekunden. Anscheinend ermöglichte das Aktivieren des Ablaufverfolgungsflags dem Optimierer, eine Indexsuche in der Ansicht der 200-Millionen-Zeilentabelle zu verwenden.

In diesem Fall machten die durch das Ablaufverfolgungsflag 4199 aktivierten Abfrageoptimierungen einen enormen Unterschied. Ihre Erfahrungen können variieren. Aufgrund dieser Erfahrung scheint es mir jedoch definitiv wert zu sein, dies zu ermöglichen.

2
Paul Williams