SQL Server - Forcer la base de données en mémoire?

Nous avons un serveur Windows 2008 x64 costaud (processeur 4 x 4 cœurs, 32 Go de RAM) exécutant SQL Server 2005 64 bits. Nous avons une petite base de données (6 Go) mais très importante qui est un peu lente à accéder jusqu'à ce que les pages soient mises en cache en mémoire (l'utilisation est très aléatoire E / S donc les chances sont très faibles une page donnée est en mémoire et les utilisateurs finaux se plaindre de la lenteur initiale). Les disques sont assez rapides (local 15K SAS) mais je suppose que l'application est un peu maladroitement écrite (c'est une solution COTS) donc je me demande s'il y a un moyen de "forcer" une base de données en mémoire dans SQL Server 2005 (2008 n'est pas supporté par le fournisseur, donc nous ne devrions pas encore mettre à niveau vers cela) pour éviter les bleus initiaux de remplissage du cache?

Ma méthode actuelle consiste à exécuter un SELECT * à partir de chaque table d'un script pour obtenir des pages de données en mémoire, mais certains objets (index, recherche de texte intégral, etc.) ne sont pas mis en cache par cette méthode (et en modifiant le script pour interroger les index et écrire les clauses WHERE appropriées pour mettre en cache le complexe ébullition).

Non, malheureusement, il n'y a aucun moyen de forcer une base de données dans le cache. Votre méthode de force brute est probablement la plus simple. Vous pourriez vous rapprocher en utilisant des scripts de défragmentation d'index avec un paramètre de seuil très bas, comme dire reconstruire l'index s'il est fragmenté à 1%, comme ceci:

http://sqlserverpedia.com/wiki/Index_Maintenance

Cela prendra plus de temps et impliquera plus d'écritures sur le disque, mais cela aura pour effet secondaire de défragmenter vos index et de mettre à jour les statistiques, ce qui est une bonne idée de toute façon.

Ok - je ne peux pas commenter la réponse de Brent (pour l'instant, comme je n'ai pas assez de représentants) - mais si vous allez suivre la voie de la défragmentation, ne reconstruisez pas nécessairement l'index - car cela va construire de nouveaux index, augmenter éventuellement la base de données s'il n'y a pas assez d'espace libre et garantir que votre prochaine sauvegarde de journal est au moins de la taille de vos index et votre journal peut également contenir une tonne d'enregistrements de journal (selon le modèle de récupération). Si vous allez faire l'itinéraire de défragmentation, faites un ALTER INDEX ... REORGANIZE, qui ne nécessite aucun espace libre (enfin, une page de 8 Ko) mais lira le niveau de la feuille en mémoire et ne fonctionnera que sur le fragmenté pages. Les niveaux non foliaires devraient arriver rapidement après certaines requêtes et (selon le fan-out) devraient être beaucoup moins de données que le niveau foliaire.

Pourquoi les objets de base de données sont-ils vidés du cache en premier lieu? Redémarrez-vous les services SQL ou retirez-vous / en ligne de la base de données? Ou sont-ils expulsés par la mise en cache à partir d'autres bases de données?

Cordialement,

SCM.

Si la base de données est si petite, pensez à la mettre sur SSD?

J'ai eu certains scénarios où la mise à jour des statistiques avec FULLSCAN sur les tables de clés a forcé les données dans le cache et a rendu mes DML suivants autour de ces tables beaucoup plus rapides. Et ce n'était pas le résultat de statistiques obsolètes car cela n'a entraîné aucun changement dans les plans d'exécution.

Pourquoi n'installez-vous pas une deuxième instance de SQL Server avec uniquement cette base de données et définissez la mémoire minimale pour cette instance sur 6 Go?

Cela garantira que vos autres bases de données ne satureront jamais la mémoire de votre base de données "petite mais très importante".

Cela signifie également que vous pouvez mettre l'autre instance hors ligne et que votre petite base de données restera en mémoire.

J'utiliserais le profileur pour vérifier votre sql. Comparez les lectures «logiques» aux lectures «physiques». Le serveur SQL est intelligent et utilisera la RAM dont il a besoin pour les résultats les plus efficaces.

Vérifiez également que vos statistiques automatiques sont à jour.

Sans plus d'idée du type de requête et des tailles de table db, cela semble un peu étrange.