¿Los índices consumen memoria?


10

Estoy empezando a aprender sobre el uso de memoria en SQL Server. Cuando se utiliza la consulta en la respuesta a la pregunta SQL Server 2008 R2 "Memoria fantasma"? , Descubrí que una sola base de datos está ocupando la mayor parte del espacio en el grupo de búferes. Mirando más allá, usando sys.allocation_unitsy sys.indexes, confirmé que esto probablemente sea causado por el uso intensivo de índices en la base de datos. La mayoría de los índices están agrupados.

Otro desarrollador de bases de datos cree que tenemos problemas de memoria en el servidor, que las consultas comienzan a durar mucho porque no hay memoria disponible.

Mi pregunta aquí es: ¿el uso de estos índices y su existencia en el grupo de búferes elimina la memoria disponible para otros procesos?


2
"Another database developer believes we are having memory issues on the server"-- ¿basado en que? ¿Cuánta RAM tiene el servidor, cuáles son las configuraciones de memoria de la instancia y cuánta memoria está consumiendo la memoria caché del procedimiento?
Jon Seigel

Basado en tiempos de consulta extendidos y mirando el Administrador de tareas, que según mi investigación es un "mentiroso sucio y sucio" (gracias Brent Ozar - brentozar.com/archive/2011/09/… ). Es posible que no haya problemas de memoria. ¡Estoy siguiendo todas las sugerencias proporcionadas en estos comentarios y respuestas!
JHFB

2
Dado que estamos lanzando la bola 8 aquí, creo que las consultas corren lentamente porque fueron escritas por ese "otro" desarrollador de bases de datos ...
Remus Rusanu

Respuestas:


12

Sí, las páginas de datos de un índice usado que se almacenan en caché en el grupo de búferes ocuparán espacio en el caché de datos . Pero no permita que eso le impida usar índices (en primer lugar, un índice agrupado son los datos reales de la tabla, así que tenga esto en cuenta también). El uso de índices (diseñados e implementados adecuadamente, por supuesto) es algo bueno.

Lo más probable es que sus problemas de memoria no tengan índices en sus tablas . Sumérgete en los problemas de memoria, ¿cuáles son exactamente los problemas? ¿Tiene una expectativa de vida de página baja ? ¿Cómo se configura su memoria en el servidor? ¿La memoria máxima del servidor es baja y restringe el tamaño de la agrupación de almacenamiento intermedio?

Para obtener un desglose de las páginas de índice en su caché de datos, puede ejecutar la siguiente consulta:

select
    count(*) as total_page_count,
    count(*) * 8 as total_consumption_kb,
    sum(row_count) as total_row_count
from sys.dm_os_buffer_descriptors
where page_type = 'INDEX_PAGE'
group by page_type

Para obtener estas estadísticas por base de datos:

select
    db_name(database_id) as database_name,
    count(*) as total_page_count,
    count(*) * 8 as total_consumption_kb,
    sum(row_count) as total_row_count
from sys.dm_os_buffer_descriptors
where page_type = 'INDEX_PAGE'
group by database_id
order by total_consumption_kb desc

Esperanza de vida de página decente (?) - 4234. Necesito investigar la proporción de aciertos de la memoria caché del búfer y analizar las otras partes.
JHFB

Ese PLE no muestra presión de memoria en absoluto. Cualquier cosa por encima de 1000 como regla general (por supuesto, siempre hay "depende") es aceptable.
Thomas Stringer

La relación de aciertos de la memoria caché del búfer puede ser muy engañosa o inútil. Consulte Grandes debates de SQL Server: Proporción de aciertos de memoria caché de búfer por @JonathanKehayias.
Mark Storey-Smith

@ MarkStorey-Smith Nota, gracias por el puntero!
Thomas Stringer

@JHFB Retrocedamos un paso. ¿Qué te hace pensar que tienes presión de memoria?
Thomas Stringer

7

Los índices consumen espacio de agrupación de almacenamiento intermedio, sí. Esta es una razón más por la que debe tener cuidado con su estrategia de indexación y minimizar los duplicados.

Confirmé que esto probablemente sea causado por el uso intensivo de índices en la base de datos. La mayoría de los índices están agrupados.

Recuerde que un índice agrupado es la tabla . La única sobrecarga que existe para un índice agrupado más allá de eso para un montón (que generalmente no es deseable) es para las páginas de índice no hoja y la inclusión de la clave del clúster en todos los índices no agrupados para esa tabla. Es por eso que se prefieren las claves de clúster estrecho.

Los artículos de Kimberley Tripp sobre opciones clave agrupadas son una excelente referencia para esto.


+1 Que los artículos de la Sra. Tripp son EPIC en clustering keys ...
Fabricio Araujo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.