Internes de la mémoire de l'espace de travail

D'après mes livres sur SQL Server 2008 Internals and Troubleshooting (empruntés à une bibliothèque locale de l'Illinois) par Christian Bolton, Brent Ozar etc. peut confirmer ou corriger ma compréhension.

Chaque requête ou opération qui nécessite une allocation de mémoire de requête aura besoin de mémoire d'espace de travail. Dans les requêtes générales utilisant Sort, Hash Match Join, Parallelism (Pas sûr à ce sujet), Bulk Insert (pas sûr), Index Rebuild etc. auront besoin de la mémoire de l'espace de travail de requête.

La mémoire de l'espace de travail fait partie du pool de tampons SQL Server (elle est allouée en tant que partie du pool de tampons) et la mémoire maximale de l'espace de travail est de 75% de la mémoire allouée au pool de tampons. Par défaut, une seule requête ne peut pas obtenir plus de 25% de la mémoire de l'espace de travail (dans SQL 2008 / SQL 2012 - contrôlé par le groupe de charges de travail par défaut du gouverneur de ressources).

Je cherche une confirmation de ma compréhension

1) En considérant un système avec 48 Go de RAM et une mémoire de serveur maximale configurée à 40 Go, cela signifie que la mémoire maximale de l'espace de travail est limitée à 30 Go et qu'une seule requête ne peut pas obtenir une mémoire de l'espace de travail (mémoire de requête) supérieure à 10 Go. Donc, si vous avez une mauvaise requête avec un milliard de lignes qui fait une jointure de hachage massive et avez besoin de plus de 10 Go de mémoire (mémoire de l'espace de travail), cela aurait-il même le souci de passer par cette file d'attente de mémoire ou de se déverser immédiatement sur le disque?

2) Si une requête effectuant une opération de tri massive a reçu une mémoire d'espace de travail de 5 Mo et pendant l'exécution de la requête si l'optimiseur de requête se rend compte qu'en raison de mauvaises statistiques ou d'index manquants, cette requête aura en fait besoin de 30 Mo de mémoire d'espace de travail. se déversera immédiatement sur tempdb. Même si le système dispose de beaucoup de mémoire d'espace de travail disponible pendant l'exécution une fois que la requête a dépassé la mémoire d'espace de travail accordée pendant l'exécution, elle devra se déverser sur le disque. Ma compréhension est-elle correcte?

serait-il même soucieux de passer par cette file d'attente de mémoire ou de renverser immédiatement sur le disque?

Cela ne fonctionne pas de cette façon. Une fois qu'un plan a été choisi qui nécessite une allocation de mémoire, la requête doit obtenir l'allocation pour qu'elle passe par la file d'attente. Le déversement, le cas échéant, se produit beaucoup plus tard dans le cycle d'exécution. Une requête ne peut pas décider d'aller de l'avant sans l'octroi et le «déversement» à la place. Il doit obtenir la subvention et, sur cette base, commencer l'exécution. Si la subvention s'avère insuffisante (en raison d'une mauvaise estimation ou en raison de l'obtention d'une subvention bien inférieure à celle demandée), la requête sera forcée de déborder.

si l'optimiseur de requêtes se rend compte qu'en raison de mauvaises statistiques ou d'index manquants

À proprement parler, ce n'est pas l'optimiseur, c'est l'exécution de la requête. L'optimiseur de requête n'a qu'un mot à dire pour décider du plan, mais une fois le plan choisi et lancé en exécution, l'optimiseur est hors de vue. aussi, les «index manquants» ne jouent aucun rôle ici. Un index manquant peut forcer un mauvais plan, mais il ne peut pas influencer la façon dont ce `` mauvais '' plan est exécuté, car ce plan a été construit en tenant compte exactement des index existants afin qu'il sache exactement ce qu'il peut et ne peut pas faire. Les déversements se produisent presque toujours en raison de mauvaises estimations, c.-à-d. mauvaises statistiques ou mauvais algorithmes d'estimation de la cardinalité dans l'optimiseur et dans l'exécution (cela devient vraiment complexe si vous fouillez dans les détails donc je m'arrêterai ici).

Même si le système dispose de beaucoup de mémoire d'espace de travail disponible pendant l'exécution une fois que la requête a dépassé la mémoire d'espace de travail accordée pendant l'exécution, elle devra se répandre sur le disque.

Malheureusement oui. Cependant, l'optimiseur doit proposer un plan qui tire parti de la RAM disponible.

Je recommande de lire Comprendre l'allocation de mémoire du serveur SQL est la meilleure information sur le sujet par une large marge.