Gli indici consumano memoria?


10

Sto appena iniziando a conoscere l'utilizzo della memoria su SQL Server. Quando si utilizza la query nella risposta alla domanda "Ghost Memory" di SQL Server 2008 R2? , Ho scoperto che un singolo database sta occupando la parte dello spazio del leone nel pool di buffer. Guardando oltre, usando sys.allocation_unitse sys.indexes, ho confermato che ciò è probabilmente causato dal forte uso di indici nel database. La maggior parte degli indici sono raggruppati.

Un altro sviluppatore di database ritiene che stiamo riscontrando problemi di memoria sul server: le query stanno iniziando a funzionare a lungo perché non c'è memoria disponibile.

La mia domanda qui è: l'uso di questi indici e la loro esistenza nel pool di buffer, porta via la memoria disponibile per altri processi?


2
"Another database developer believes we are having memory issues on the server"- basato su cosa? Quanta RAM ha il server, quali sono le impostazioni di memoria dell'istanza e quanta memoria viene consumata dalla cache delle procedure?
Jon Seigel,

Basato su tempi di interrogazione estesi e guardando Task Manager - che la mia ricerca ha indicato è un "bugiardo sporco e sporco" (grazie Brent Ozar - brentozar.com/archive/2011/09/… ). Potrei scoprire che non c'è nessun problema di memoria - sto seguendo tutti i suggerimenti forniti in questi commenti e risposte!
JHFB,

2
Dal momento che stiamo lanciando la palla 8 qui, penso che le query siano lente perché sono state scritte da quel "altro" sviluppatore di database ...
Remus Rusanu,

Risposte:


12

Sì, le pagine di dati di un indice utilizzato che sono memorizzate nella cache nel pool di buffer occuperanno spazio nella cache di dati . Ma non lasciare che ti allontani dall'uso degli indici (prima di tutto, un indice cluster è i dati effettivi della tabella, quindi tienilo a mente). L'uso degli indici (correttamente progettato e implementato, ovviamente) è una buona cosa.

Molto probabilmente i problemi di memoria non derivano dall'indice sui tavoli . Immergiti nei problemi di memoria, quali sono esattamente i problemi? Hai una bassa aspettativa di vita nella pagina ? Come viene configurata la tua memoria sul server? La memoria massima del server è troppo bassa limitando la dimensione del pool di buffer?

Per ottenere una suddivisione delle pagine dell'indice nella cache dei dati, è possibile eseguire la query seguente:

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

Per ottenere queste statistiche dal database:

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

Aspettativa di vita della pagina decente (?) - 4234. Devo ricercare il rapporto di risultati della cache del buffer e esaminare le altre parti.
JHFB,

Quel PLE non mostra affatto la pressione della memoria. Qualcosa di più di 1000 come regola generale (ovviamente, c'è sempre "dipende") è accettabile.
Thomas Stringer,

La percentuale di riscontri nella cache del buffer può essere molto fuorviante o completamente inutile. Guarda i grandi dibattiti su SQL Server: rapporto di hit della cache del buffer di @JonathanKehayias.
Mark Storey-Smith,

@ MarkStorey-Smith Notato, grazie per il puntatore!
Thomas Stringer,

@JHFB Facciamo un passo indietro. Cosa ti fa pensare di avere una pressione della memoria?
Thomas Stringer,

7

Gli indici consumano spazio nel pool buffer, sì. Questo è un altro motivo per cui dovresti occuparti della tua strategia di indicizzazione e minimizzare i duplicati.

Ho confermato che ciò è probabilmente causato dall'uso intenso di indici nel database. La maggior parte degli indici sono raggruppati.

Ricorda che un indice cluster è la tabella . L'unico overhead esistente per un indice cluster oltre a quello per un heap (che è generalmente indesiderabile) è per le pagine di indice non foglia e l'inclusione della chiave cluster in tutti gli indici non cluster per quella tabella. Questo è il motivo per cui si preferiscono le chiavi a cluster ristretto.

Gli articoli di Kimberley Tripp sulle scelte chiave raggruppate sono un eccellente riferimento per questo.


+1 Che gli articoli della sig.ra Tripp sono EPICI sulle chiavi di raggruppamento ...
Fabricio Araujo,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.