Memoria interna del espacio de trabajo

Según mis libros de lectura sobre Internals y solución de problemas de SQL Server 2008 (tomados de la biblioteca local en Illinois) por Christian Bolton, Brent Ozar, etc. Estoy tratando de buscar comprensión y confirmación en el servidor SQL y muchas búsquedas en la web que agradecería si alguien Puede confirmar o corregir mi comprensión.

Cada consulta u operación que requiera la concesión de memoria de consulta necesitará memoria de espacio de trabajo. En general, las consultas que utilizan Ordenar, Unir coincidencia de hash, Paralelismo (no estoy seguro de esto), Insertar en bloque (no estoy seguro), Reconstruir índice, etc. necesitarán memoria de espacio de trabajo de consulta.

La memoria del espacio de trabajo es parte del grupo de búferes de SQL Server (se asigna como parte del grupo de búferes) y la memoria máxima del espacio de trabajo es el 75% de la memoria asignada al grupo de búferes. De forma predeterminada, una sola consulta no puede obtener más del 25% de la memoria del espacio de trabajo (en SQL 2008 / SQL 2012, controlado por el grupo de carga de trabajo predeterminado de Resource Governor).

Buscando una confirmación de mi comprensión

1) Tener en cuenta el sistema con 48 GB de RAM y la memoria máxima del servidor configurada en 40 GB significa que la memoria máxima del espacio de trabajo está limitada a 30 GB y una sola consulta no puede obtener más de 10 GB de memoria del espacio de trabajo (memoria de consulta). Entonces, si tiene una consulta incorrecta que funciona con mil millones de filas que está haciendo una unión hash masiva y necesita más de 10 GB de memoria (memoria del espacio de trabajo), ¿le importaría pasar por esta cola de concesión de memoria o derramarla de inmediato al disco?

2) Si a una consulta que realiza una operación de clasificación masiva se le ha asignado una memoria de espacio de trabajo de 5 MB y durante la ejecución de la consulta, si el optimizador de consultas se da cuenta de que debido a estadísticas erróneas o índices faltantes, esta consulta realmente necesitará 30 MB de memoria de espacio de trabajo. se derramará inmediatamente a tempdb. Incluso si el sistema tiene suficiente memoria de espacio de trabajo disponible durante la ejecución una vez que la consulta excedió la memoria de espacio de trabajo otorgada durante la ejecución, deberá derramarse en el disco. ¿Mi comprensión es correcta?

¿Le importaría pasar por esta cola de concesión de memoria o derramarlo inmediatamente al disco?

No funciona de esa manera. Una vez que se eligió un plan que requiere una concesión de memoria, la consulta debe obtener la concesión para que pase por la cola. El derrame, si lo hay, ocurre mucho más tarde en el ciclo de ejecución. Una consulta no puede decidir seguir adelante sin la concesión y el "derrame" en su lugar. Debe obtener la subvención y, como base, iniciar la ejecución. Si la subvención resulta ser insuficiente (debido a una mala estimación o debido a la obtención de una subvención mucho menor que la solicitada), la consulta se verá obligada a derramarse.

si el optimizador de consultas se da cuenta de eso debido a estadísticas incorrectas o índices faltantes

Estrictamente hablando no es el optimizador, es la ejecución de la consulta. Query Optimizer solo tiene algo que decir al decidir el plan, pero una vez que el plan se elige y se ejecuta, el optimizador queda fuera de la imagen. Además, los 'índices faltantes' no juegan ningún papel aquí. Un índice faltante puede forzar un plan malo, pero no puede influir en cómo se ejecuta ese plan 'malo' ya que ese plan fue construido considerando exactamente qué índices existen realmente para que sepa exactamente lo que puede y no puede hacer. Los derrames ocurren casi siempre debido a malas estimaciones, es decir. estadísticas malas o algoritmos de estimación de cardinalidad incorrecta en el optimizador y en la ejecución (se vuelve realmente complejo si profundizas en los detalles, así que me detendré aquí).

Incluso si el sistema tiene suficiente memoria de espacio de trabajo disponible durante la ejecución una vez que la consulta excedió la memoria de espacio de trabajo otorgada durante la ejecución, deberá derramarse en el disco

Por desgracia sí. Sin embargo, el optimizador debería tener un plan que aproveche la RAM disponible.

Recomiendo leer Entender la concesión de memoria del servidor SQL es la mejor información sobre el tema por un amplio margen.