SQL Server - Datenbank im Speicher erzwingen?

Wir haben einen leistungsfähigen Windows 2008 x64-Server (4 x 4-Kern-CPU, 32 GB RAM), auf dem SQL Server 2005 64-Bit ausgeführt wird. Wir haben eine kleine (6 GB), aber sehr wichtige Datenbank, auf die nur langsam zugegriffen werden kann, bis die Seiten im Arbeitsspeicher zwischengespeichert sind (die Verwendung erfolgt sehr zufällig, sodass die Wahrscheinlichkeit sehr gering ist, dass sich eine bestimmte Seite im Arbeitsspeicher befindet und die Endbenutzer sich über die anfängliche Langsamkeit beschweren). Die Festplatten sind schnell genug (lokale 15K SAS), aber ich denke, die App ist etwas umständlich geschrieben (es ist eine COTS-Lösung), und ich frage mich, ob es eine Möglichkeit gibt, eine Datenbank im Speicher in SQL Server 2005 "zu erzwingen" (2008 wird nicht unterstützt) Wir sollten also noch kein Upgrade durchführen, um den anfänglichen Cache-Filling-Blues zu vermeiden.

Meine aktuelle Methode ist, dass ich ein SELECT * aus jeder Tabelle in einem Skript ausführe, um Datenseiten in den Speicher zu bekommen, aber einige Objekte (Indizes, Volltextsuche usw.) werden von dieser Methode nicht zwischengespeichert (und das Skript so modifiziert, dass Indizes und abgefragt werden Schreiben Sie geeignete WHERE-Klauseln zum Cachen (Boil-the-Ocean-Komplex).

Nein, es gibt leider keine Möglichkeit, eine Datenbank in den Cache zu zwingen. Ihre Brute-Force-Methode ist wahrscheinlich die einfachste. Möglicherweise können Sie mit Index-Defragmentierungsskripten mit einem sehr niedrigen Schwellenwert näher herangehen, z.

http://sqlserverpedia.com/wiki/Index_Maintenance

Es wird länger dauern und mehr Schreibvorgänge auf die Festplatte erfordern, aber es hat den Nebeneffekt, dass Ihre Indizes defragmentiert und Statistiken aktualisiert werden, was ohnehin eine gute Idee ist.

Ok - Ich kann die Antwort von Brent nicht kommentieren (da ich noch nicht genug Wiederholungen habe) - aber wenn Sie die Defragmentierungsroute gehen, müssen Sie den Index nicht unbedingt neu erstellen - da dies neue Indizes erstellen wird, Erweitern Sie möglicherweise die Datenbank, wenn nicht genügend freier Speicherplatz vorhanden ist, und stellen Sie sicher, dass Ihre nächste Protokollsicherung mindestens der Größe Ihrer Indizes entspricht und in Ihrem Protokoll möglicherweise auch eine Menge Protokolldatensätze enthalten sind (je nach Wiederherstellungsmodell). Wenn Sie die Defragmentierungsroute ausführen möchten, führen Sie einen ALTER INDEX ... REORGANIZE aus, der keinen freien Speicherplatz (also eine 8-KB-Seite) benötigt, jedoch die Blattebene in den Speicher einliest und nur die fragmentierten Seiten bearbeitet Seiten. Die Nicht-Blattebenen sollten nach einigen Abfragen schnell eintreffen und (je nach Fan-Out) wesentlich weniger Daten enthalten als die Blattebene.

Warum werden die Datenbankobjekte überhaupt aus dem Cache gelöscht? Starten Sie die SQL-Dienste neu oder nehmen Sie die Datenbank aus / online? Oder werden sie durch Caching aus anderen Datenbanken entfernt?

Grüße,

SCM.

Wenn die Datenbank so klein ist, ziehen Sie in Betracht, sie auf eine SSD zu stellen?

Ich hatte einige Szenarien, in denen Statistiken mit FULLSCAN für Schlüsseltabellen aktualisiert wurden. Dadurch wurden Daten in den Cache gezwungen und meine nachfolgenden DMLs für diese Tabellen wurden viel schneller. Und dies war kein Ergebnis veralteter Statistiken, da die Ausführungspläne unverändert blieben.

Warum installieren Sie keine zweite Instanz von SQL Server mit nur dieser Datenbank und legen den Mindestspeicher für diese Instanz auf 6 GB fest?

Dies stellt sicher, dass Ihre anderen Datenbanken niemals Speicher aus Ihrer "kleinen, aber sehr wichtigen" Datenbank auslagern.

Dies bedeutet auch, dass Sie die andere Instanz offline schalten können und Ihre kleine Datenbank im Speicher verbleibt.

Ich würde Profiler verwenden, um Ihre SQL zu überprüfen. Vergleichen Sie "logische" Lesevorgänge mit "physischen" Lesevorgängen. SQL Server ist intelligent und verwendet den Arbeitsspeicher, den es für die effizientesten Ergebnisse benötigt.

Überprüfen Sie auch, ob Ihre Autostaten auf dem neuesten Stand sind.

Ohne mehr Ahnung von der Art der Abfrage und der Größe der DB-Tabelle klingt es etwas seltsam.