Pourquoi les requêtes provoquent-elles un déversement sur tempdb?

Contexte

Je suis en train de migrer une base de données 160 Go de MSSQL 2008 (standard) sur un serveur Win 2008 avec 48 Go de RAM vers un nouveau serveur exécutant MSSQL 2012 (édition Web 64 bits) sur Win 2012 avec 64 Go de RAM. L'ancien serveur est actif et sous charge; le nouveau serveur n'est pas en production. Le nouveau serveur dispose de 8 fichiers tempdb (4 Go chacun).

Problème

Lors des tests sur le nouveau serveur, je constate que les étapes de nombreuses requêtes provoquent des alertes mentionnant "l'opérateur a utilisé tempdb pour renverser les données pendant l'exécution". J'ai pu éviter les tris en réécrivant certaines des requêtes, mais cela ne résout pas vraiment le problème. Les mêmes requêtes sur l'ancien serveur ne provoquent pas de déversements. J'ai lu que les déversements se produisent lorsque MSSQL ne peut pas terminer une opération en mémoire et doit se déverser / page dans tempdb. Dois-je m'inquiéter des déversements?

Exemples

entrez la description de l'image ici

J'ai exécuté sp_updatestats sur la base de données, les statistiques doivent donc être à jour, mais vous remarquerez qu'il existe des écarts entre le nombre estimé et réel de lignes.

Problème de mémoire

J'ai défini un paramètre de mémoire maximale pour MSSQL de 58 sur 64 Go. Actuellement, MSSQL a consommé environ 35 Go de cette mémoire, mais dispose d'un ensemble fonctionnel de seulement 682 Mo. L'ancien serveur (quoique en production, en charge de la charge) dispose de 44 Go de mémoire dédiée à MSSQL dont 43,5 Go dans son jeu de travail.

entrez la description de l'image ici

Je ne sais pas si les déversements pourraient être liés à un paramètre de mémoire - quelqu'un a-t-il des idées? MSSQL dispose actuellement de plusieurs hectares de RAM, alors pourquoi se répand-il dans tempdb pour certaines sortes et correspondances de hachage?

sql-server sql-server-2012

— Andy W
source

L'alerte dans le plan d'exécution est nouvelle en 2012. Avez-vous vérifié qu'elle ne se répétait pas tout le temps sur l'ancien serveur? Surveilliez-vous cela?

— Martin Smith

@MartinSmith ah, je ne savais pas que l'alerte était nouvelle. Je ne surveillais pas les déversements sur l'ancien serveur. Va enquêter là-dessus.

Point légèrement tangent, mais je suis assis devant une jointure de table 10 qui, par défaut, utilise principalement des jointures de fusion avec de très bonnes estimations de ligne qui provoquent des déversements de niveau 0 de tempdb et 25s d'exécution. Forcer les jointures de hachage (et l'ordre) supprime les déversements et les exécutions en 9 secondes. Je me demande si c'est la fusion vs le hachage ou le déversement qui cause la différence et si l'optimiseur pondère correctement l'effet d'un déversement à venir apparemment connu (car les estimations de ligne sont très bonnes).

— crokusek

Le nouveau serveur a un matériel numa?

— stacylaray

Il y a plusieurs questions différentes ici:

Q: Pourquoi les requêtes ne se répandaient-elles pas auparavant?

Ils l'étaient, mais SQL Server Management Studio n'a pas révélé cela comme une erreur claire avant SQL 2012. C'est un excellent exemple de la raison pour laquelle lorsque vous effectuez un réglage des performances, vous devez aller plus loin que le plan d'exécution graphique.

Q: Pourquoi les requêtes se déversent-elles sur le disque?

Parce que SQL Server ne leur a pas accordé suffisamment de mémoire pour terminer leurs opérations. Peut-être que le plan d'exécution a sous-estimé la quantité de mémoire requise, ou peut-être que la boîte est sous pression de mémoire, ou ce ne sont que de grosses requêtes. (N'oubliez pas, SQL Server utilise la mémoire pour trois choses: la mise en cache des pages de données brutes, la mise en cache des plans d'exécution et l'espace de travail pour les requêtes. Cette mémoire de l'espace de travail finit par être assez petite.)

Q: Comment puis-je réduire les déversements?

En écrivant des instructions T-SQL sargables, en ayant des statistiques à jour, en mettant suffisamment de mémoire sur le serveur, en construisant les bons index et en interprétant les plans d'exécution lorsque les choses ne fonctionnent pas comme prévu. Consultez le livre de Grant Fritchey SQL Server Query Performance Tuning pour des explications détaillées sur tous ces éléments.

— Brent Ozar
source