lorsqu'il n'y a plus de mémoire physique pour les données, SQL Server déplace les données déjà existantes dans TEMPDB
L'article auquel vous avez lié est au mieux trompeur et incorrect à certains endroits. Je pense que l'auteur tentait de simplifier à l'excès certaines choses compliquées et, ce faisant, est allé un peu trop loin.
SQL Server ne déplace pas les données de la mémoire (le pool de tampons) dans tempdb de cette façon. Il utilise une stratégie de mise en cache "la moins récemment utilisée" (en général), donc s'il y a une pression mémoire et que de nouvelles données doivent être extraites en mémoire, SQL Server supprimera les données LRU du pool de mémoire tampon pour accueillir les nouvelles données. Ce comportement est souvent surveillé par un compteur perfmon appelé «Page Life Expectancy» (PLE) :
La définition de PLE est le temps attendu, en secondes, qu'une page de fichier de données lue dans le pool de mémoire tampon (le cache en mémoire des pages de fichiers de données) restera en mémoire avant d'être poussée hors de la mémoire pour faire de la place pour des données différentes page de fichier. Une autre façon de penser au PLE est une mesure instantanée de la pression sur le pool de mémoire tampon pour libérer de l'espace pour les pages lues sur le disque. Pour ces deux définitions, un nombre plus élevé est préférable.
Pendant l'exécution de la requête, SQL Server peut utiliser tempdb pour certaines opérations. Cela se fait généralement si les estimations sont mauvaises, mais la faible mémoire disponible peut influencer ce comportement.
Certaines des opérations qui peuvent «se répandre» dans tempdb de cette manière sont le hachage de lignes (pour les jointures ou les agrégats, etc.), le tri des lignes en mémoire et la mise en mémoire tampon des lignes lors de l'exécution de requêtes parallèles.
Les requêtes des utilisateurs peuvent également utiliser explicitement tempdb (avec des tables temporaires globales ou locales) et implicitement utiliser tempdb (avec un instantané ou lire des niveaux d'isolement de snapshot validés).
Aucune de ces situations ne semble vraiment correspondre à la déclaration que vous avez citée.
lorsqu'il n'y a pas assez de mémoire physique, le système d'exploitation peut utiliser le FICHIER DE PAGE et y déplacer des données de la mémoire physique
Cela peut certainement se produire et échappe en grande partie au contrôle de SQL Server. Il y a un bouton que vous pouvez tourner pour essayer d'empêcher certains types de pagination au niveau du système d'exploitation, à savoir l'activation de "Lock Pages in Memory" (LPIM) :
Cette stratégie Windows détermine quels comptes peuvent utiliser un processus pour conserver les données dans la mémoire physique, empêchant le système de paginer les données vers la mémoire virtuelle sur le disque.
Alors, que pouvons-nous empêcher d'être paginé sur le disque?
Avant SQL Server 2012, les pages allouées via un composant appelé «Single Page Allocator» étaient verrouillées en mémoire (ne pouvaient pas être paginées). Cela comprenait le pool de mémoire tampon (pages de base de données), le cache de procédures et d'autres zones de mémoire.
Voir Fun with Locked Pages, AWE, Task Manager et Working Set… pour plus de détails, en particulier la section «4. Maintenant que je sais que SQL Server sur x64 peut utiliser des« pages verrouillées », qu'est-ce qui est verrouillé exactement? Vous pouvez trouver des informations complémentaires ici: Great SQL Server Debates: Lock Pages in Memory
Dans SQL Server 2012 et versions ultérieures, il n'y a pas d'allocateur de page unique (les allocateurs de page unique et de plusieurs pages ont été fusionnés, selon un examen approfondi de la mémoire - SQL Server 2012/2014 ). Les détails de ce qui, exactement, peut et ne peut pas être paginé ne sont pas documentés en détail partout où j'ai vu. Vous pouvez utiliser une requête comme celle-ci pour voir ce qui est verrouillé:
select osn.node_id, osn.memory_node_id, osn.node_state_desc, omn.locked_page_allocations_kb
from sys.dm_os_memory_nodes omn
inner join sys.dm_os_nodes osn on (omn.memory_node_id = osn.memory_node_id)
where osn.node_state_desc <> 'ONLINE DAC'
Selon le même article de support MS, vous pouvez également utiliser DBCC MEMORYSTATUSpour voir la quantité de mémoire «verrouillée».
En guise de remarque, vous pouvez voir la preuve que l'ensemble de travail de SQL Server est paginé par le système d'exploitation dans le journal des erreurs. Il y aura des messages qui ressemblent à ceci:
2019-09-02 10: 19: 27.29 spid11s Une partie importante de la mémoire de processus du serveur SQL a été paginée. Cela peut entraîner une dégradation des performances. Durée: 329 secondes. Ensemble de travail (Ko): 68780, engagé (Ko): 244052, utilisation de la mémoire: 28%.
