Ist RECOMPILE wirklich so schlecht?

Heh … auf der DBCC FREEPROCCACHE Sache und mit dem Verständnis, dass mein Server wahrscheinlich nicht irgendwo in der Nähe eines Ortes ist, wo es eine echte Sorge verursachen würde, haben wir eine schwere Mischung zwischen OLTP und großen Verarbeitungsläufen, vor allem während des Tages. Es dauert viel zu lange, um jede einzelne gespeicherte Prozedur zu isolieren, die neu kompiliert werden muss, und so verwende ich DBCC FREEPROCCACHE von Zeit zu Zeit auf meiner Produktionsbox ohne ernsthafte negative Auswirkungen und bereinigt sofort eine Fülle von Sünden. YMMV aber für mich ist die Verwendung von DBCC FREEPROCCACHE nicht das Nein-Nein, zu dem jeder es macht.

Was die Neukompilierung betrifft, stimme ich zu. Sie sind nicht unbedingt die Sünde, die viele Leute glauben machen würden. Sie sind besonders nützlich bei einigen dieser großen Verarbeitungsläufe, bei denen eine Neukompilierung erforderlich ist, damit die minimale Protokollierung tatsächlich funktioniert.

Es ist schon eine Weile her, dass ich mir unsere Neukompilierungssituation bei der Arbeit angesehen habe, aber wir hatten einen Prozess, dessen Ausführung „nur“ 100 ms dauerte, von dem ich auch dachte, dass er zu lange dauerte, aber ich konnte das Management nicht dazu bringen, sich zu bewegen, obwohl ich die zehntausende Male erklärte, die jede Stunde getroffen wurden. Dann habe ich eine Neukompilierungsanalyse durchgeführt und das verdammte Ding wurde nicht nur jedes Mal neu kompiliert, es dauerte zwischen 2 und 22 Sekunden, um jedes Mal neu zu kompilieren, wobei der Durchschnitt bei 20 Sekunden lag. Nachdem ich den ziemlich kurzen Code im proc optimiert hatte, verschwanden nicht nur die Neukompilierungen, sondern die Ausführung wird jetzt in einstelligen ms gemessen. Ich wusste es nicht, aber dies löste auch einen großen Schmerzpunkt bei den Rückgabezeiten auf dem Boden für einen bestimmten Bildschirm in der Anwendung, die den Proc verwendete.

Was die „Fortschritte“ betrifft, die sie in diesem Bereich für 2017 und 2019 gemacht haben, habe ich Todesangst, 2016 abzuziehen. Ich leide immer noch unter einigen der „Fortschritte“, die sie 2014 und 2016 gemacht haben. Sie geben uns jedoch nicht viel Auswahl, wenn es um Upgrades geht. Ein solcher „Fortschritt“ sind „Schnelle Einsätze“. Die meisten Leute wissen nichts davon, weil ihre Indexwartungsroutinen den Fehler verbergen, der beim Zuweisen einer vollständigen Ausdehnung auftritt, ohne nach teilweise leeren, bereits vorhandenen Ausdehnungen zu suchen, selbst wenn Sie eine sprichwörtliche „1-Byte“ -Zeile einfügen. Gott sei Dank für TF 692.

Die Änderungen, die sie für TempDB vorgenommen haben, sind ziemlich gut, aber nicht einmal eine temporäre Exkursion zum Ungleichgewicht der Dateigrößen zuzulassen, hat eine ganze Menge Dinge getötet, die wir wegen eines anderen Fehlers in SET IDENTITY INSERT gemacht haben, wo die gesamte Datenübertragung in TempDB sortiert ist, obwohl es wegen des Vorhandenseins eines Clusterindex und minimaler Protokollierung nicht benötigt wird.

Ich wünschte, MS würde aufhören, „Verbesserungen“ vorzunehmen und anfangen, die „Verbesserungen“, die sie bereits vorgenommen haben, ernsthaft zu beheben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.