Lassen Sie mich die wichtigen Datenpunkte in Ihrer Tabelle zusammenfassen (und abrunden!):
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527
Die erste Zeile zeigt also die schlechten Dinge, die ungefähr 2/3 Ihres Plan-Caches beanspruchen (Dinge, die mit wenigen Ausnahmen meist nur einmal verwendet werden). Sie müssen versuchen, so viel davon wie möglich loszuwerden. Die zweite Reihe zeigt die guten Sachen. Dies sind die Dinge, die Sie in Ihrem Plan-Cache haben möchten (Pläne mit einem hohen Wiederverwendungsgrad). Der Rest der Daten ist meiner Meinung nach weitgehend irrelevant. Ein weiterer Punkt: Sie sagen, dass der Zugriff ausschließlich über gespeicherte Prozeduren erfolgt. Wenn diese Prozeduren jedoch dynamisches SQL verwenden, werden diese Anweisungen als AdHocPläne und nicht als Pläne zwischengespeichert Proc.
Ab 2008 würde ich sagen, schalten Sie ein optimize for ad hoc workloadsund fahren Sie mit dem nächsten Problem fort - dies würde die Anzahl der MBs, die Ihre Einwegpläne derzeit belegen, auf so gut wie nichts reduzieren. Leider sind Ihre Optionen im Jahr 2005 sehr begrenzt, abgesehen von der Umgestaltung dieser gespeicherten Prozeduren, um Anweisungsebene OPTION (RECOMPILE)und / oder weniger / kein dynamisches SQL zu verwenden, oder dem Aktivieren der erzwungenen Parametrisierung auf Datenbankebene - wodurch versucht wird, eine bessere Wiederverwendung von Plänen zu erzielen ähnliche Abfragen, indem Literale als Parameter für Planabgleichszwecke behandelt werden. Ich zögere sogar, Planleitfäden zu erwähnen, weil sie nicht schüchtern sind, und - wie ich später in dieser Antwort erläutere - ich bin mir nicht sicher, ob es sich lohnt, diesen Weg zu gehen, es sei denn, Sie wissen, dass Ihr Plan-Cache definitiv die Quelle Ihrer Leistung ist Problem.
Ich habe nachgefragt, @@VERSIONweil vor SP2 der Algorithmus für die Speichermenge, die dem Plan-Cache zugewiesen werden konnte, relativ locker war. Ab SP2 haben sie das ziemlich verschärft (die Änderung wird in diesem Beitrag und diesem Beitrag dokumentiert und erklärt ). In Ihrem Fall ist der Plan-Cache relativ voll, sodass es nicht verwunderlich ist, dass Cache-Fehler auftreten. 26 GB = eine Obergrenze von 5,8 GB; Ich sehe ~ 4,5 GB in der Tabelle, aber es kann hier einige Berechnungs- oder Konfigurationsunterschiede geben, von denen ich nichts weiß.
In diesem MSDN-Artikel wird auf die optimize for ad hoc workloads2008 hinzugefügte Servereinstellung eingegangen und das Trace-Flag 8032 erwähnt, mit dem Sie Ihren Caches mehr Speicher zuweisen können (vermutlich, wenn diese Einstellung nicht auf Serverebene festgelegt wurde, was ich jetzt allen empfehle unsere Kunden oder zumindest die 99%, die nicht mehr auf 2005 sind). Ich habe dieses Trace-Flag noch nie auf 2005 SP3 oder SP4 getestet und bin mir ehrlich gesagt nicht einmal sicher, wann es eingeführt wurde. Ich weiß auch nicht, ob es Ihr Problem lösen oder es einfach verschieben wird, da ich denke, selbst wenn Sie etwas mehr RAM für Caches reserviert hätten, würden Sie es immer noch füllen und aufgrund der Natur von viele Cache-Fehler haben Ihre gespeicherten Prozeduren.
Oder natürlich, wenn es überhaupt ein zu lösendes Problem gibt, das sich überhaupt direkt auf den Plan-Cache bezieht. Nur weil Ihre Cache-Trefferquote nicht so hoch ist, wie Sie es vielleicht erwarten, bedeutet dies nicht, dass dies Ihr Problem verursacht, und natürlich ist das Gegenteil der Fall, selbst bei einer Cache-Trefferquote von 100% - was angesichts der vielen nicht realistisch erscheint Ihre Pläne sind einmalig und ad hoc - Ihre Benutzer leiden möglicherweise immer noch unter Leistungsproblemen, die durch etwas ganz anderes verursacht werden.
Mein Vorschlag ist, nach besseren Rauchwaffen zu suchen, als die Cache-Trefferquote zu planen. Erfahren Sie mehr über die Leistungsbeschwerden Ihrer Benutzer. Sind alle Abfragen immer langsam? Bestimmte Fragen? Bestimmte Zeiten von Tag / Woche / Konjunkturzyklus? Sind nur Berichtsanfragen langsam? Lesen Sie dieses zugegebenermaßen trockene und lange Dokument zu Best Practices für SQL Server gründlich durch - insbesondere den Abschnitt zu Wartezeiten und Warteschlangen, in dem Sie einen logischen Ansatz zur Identifizierung, Diagnose und Lösung von Leistungsproblemen formulieren können. Es mag sehr befriedigend sein, eine Nummer in einem Dashboard besser aussehen zu lassen - eine Nummer, von der Sie nicht einmal wissen, dass sie direkt zum Problem beiträgt -, aber wenn sie die Leistungsprobleme Ihrer Benutzer nicht löst, hat sie Sie nicht wirklich erwischt irgendwo.
Diese können auch hilfreich sein, um Informationen zur Kompilierung / Neukompilierung zu erhalten und die Wiederverwendung des Caches zu planen. Einige davon konzentrieren sich auf 2008 (insbesondere auf die Einstellung der Ad-hoc-Workloads), aber ein Großteil der Informationen ist für 2005 noch nützlich und / oder um die Vorteile eines Upgrades besser zu verstehen (Hinweis, Hinweis).