cuando no queda memoria física para los datos, SQL Server mueve los datos ya existentes a TEMPDB
El artículo al que se vinculó es, en el mejor de los casos, engañoso e incorrecto en algunos lugares. Creo que el autor estaba tratando de simplificar en exceso algunas cosas complicadas, y al hacerlo fue un poco demasiado lejos.
SQL Server no mueve los datos de la memoria (el grupo de búferes) a tempdb de esa manera. Utiliza una estrategia de almacenamiento en caché "menos utilizada recientemente" (en general), por lo que si hay presión de memoria y es necesario extraer nuevos datos en la memoria, SQL Server expulsará los datos LRU del grupo de búferes para acomodar los nuevos datos. Este comportamiento a menudo es monitoreado por un contador de rendimiento llamado "Page Life Expectancy" (PLE) :
La definición de PLE es el tiempo esperado, en segundos, que una página de archivo de datos leída en la agrupación de almacenamiento intermedio (el caché en memoria de las páginas de archivos de datos) permanecerá en la memoria antes de ser expulsada de la memoria para dejar espacio para datos diferentes página de archivo Otra forma de pensar en PLE es una medida instantánea de la presión sobre el grupo de búferes para dejar espacio libre para las páginas que se leen desde el disco. Para ambas definiciones, un número más alto es mejor.
Durante la ejecución de la consulta, SQL Server puede usar tempdb para ciertas operaciones. Esto generalmente se hace si las estimaciones son malas, pero la poca memoria disponible puede influir en este comportamiento.
Algunas de las operaciones que pueden "derramarse" a tempdb de esta manera son las filas de hash (para uniones o agregados, etc.), la clasificación de filas en la memoria y las filas de almacenamiento en búfer durante la ejecución de consultas paralelas.
Las consultas de los usuarios también pueden usar explícitamente tempdb (con tablas temporales globales o locales), e implícitamente usar tempdb (con niveles de aislamiento de instantáneas confirmadas de instantánea o lectura).
Ninguna de estas situaciones realmente parece ajustarse a la afirmación que citó.
cuando no queda suficiente memoria física, el sistema operativo puede usar el ARCHIVO DE PÁGINA y mover datos de la memoria física a él
Esto definitivamente puede suceder, y está fuera del control de SQL Server en su mayor parte. Hay una perilla que puede girar para tratar de evitar algunos tipos de paginación a nivel del sistema operativo, a saber, activar "Bloquear páginas en la memoria" (LPIM) :
Esta política de Windows determina qué cuentas pueden usar un proceso para mantener los datos en la memoria física, evitando que el sistema pagine los datos a la memoria virtual en el disco.
Entonces, ¿qué podemos evitar que se pagine al disco?
Antes de SQL Server 2012, las páginas que se asignaban a través de un componente llamado "Asignador de página única" estaban bloqueadas en la memoria (no se podían paginar). Esto incluía el grupo de búferes (páginas de la base de datos), el caché de procedimientos y algunas otras áreas de memoria.
Consulte Diversión con páginas bloqueadas, AWE, Administrador de tareas y el conjunto de trabajo ... para obtener detalles, especialmente la sección "4. Ahora sé que SQL Server en x64 puede usar" Páginas bloqueadas ", ¿qué está bloqueado exactamente?" Puede encontrar lecturas relacionadas adicionales aquí: Grandes debates de SQL Server: bloquear páginas en la memoria
En SQL Server 2012 y versiones posteriores, no existe un "Asignador de página única" (los asignadores de una o varias páginas se fusionaron, de acuerdo con un análisis detallado de la memoria: SQL Server 2012/2014 ). Los detalles de qué, exactamente, puede y no puede ser paginado no está documentado en detalle en ninguna parte que haya visto. Puede usar una consulta como esta para ver qué está bloqueado:
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'
Según el mismo artículo de MS Support, también puede usar DBCC MEMORYSTATUSpara ver cuánta memoria está "bloqueada".
Como nota al margen, puede ver evidencia del conjunto de trabajo de SQL Server que está siendo paginado por el sistema operativo en el registro de errores. Habrá mensajes que se verán así:
2019-09-02 10: 19: 27.29 spid11s Se ha eliminado una parte significativa de la memoria de proceso del servidor sql. Esto puede resultar en una degradación del rendimiento. Duración: 329 segundos. Conjunto de trabajo (KB): 68780, comprometido (KB): 244052, utilización de memoria: 28%.