The last page insert latch contention issue. Cos'è?

Cari lettori eccoci di nuovo qui!

Solitamente preferisco titolare l'articolo in italiano tant'è che di blog in materia scritti in inglese ce ne sono già tanti.
Oggi facciamo un eccezione perchè la problematica che vi presenterò è conosciuta in tutto il mondo con il nome indicato nel titolo.
Non credo sareste mai riusciti a trovare questo articolo cercandolo su google con la sua traduzione in italiano!

Detto questo in italiano suonerebbe più o meno così: Problema di contesa dei latch durante l'inserimento in ultima pagina.

The last page insert latch contention issue

Parleremo in realtà anche di prestazioni perchè evitare questo tipo di problematica vi consentirà di operare in modo più performante.
Aspettate però la fine dell'articolo e capirete tutto!

Siete pronti? Via!

Supponiamo ad esempio che abbiate sviluppato una procedura che inserisce dei dati in una tabella SQL.
Supponiamo anche la vostra procedura sia utilizzata contemporaneamente da tanti utenti.
Vi ci ritrovate tutti vero?

Supponiamo adesso che la vostra tabella abbia una colonna identità (identity) sulla quale sia presente anche indice clustered.
Vi ci ritrovare quasi tutti vero?

Bhe allora potreste trovarvi quasi tutti nella condizione di essere soggetti alla problematica detta "Last page Insert Contention"

Se sulla vostra tabella i dati sono inseriti solamente da pochi utenti contemporaneamente probabilmente non accorgerete di questo fenomeno.

Per misurarlo vi consiglio comunque di valutare le statistiche d'attesa (wait state) guardando ai blocchi di tipo pagelatch exclusive.

Quello che invece è molto più certo è che la vostra procedura non scalerà molto bene in funzione del numero di utenti che inseriscono contemporaneamente dati.

Davvero? Purtroppo si!

Ma vediamone il perchè.

Come detto in precedenza abbiamo una tabella in cui è presente un indice clustered su un campo identità.

Quando è presente un indice clustered abbiamo che i dati che via via che vengono inseriti sono memorizzati all'interno della tabella in modo ordinato.
Se è presente una identità abbiamo che gli inserimenti di nuovi dati avvengono sempre sulla stessa pagina che si trova alla fine dell'indice.

Proprio la concomitanza di queste due specifiche a fare si che, in caso di carico elevato, l'inserimento contemporaneo causi un conflitto a livello dell'ultima pagina detta foglia (leaf) della struttura b-tree.

La nostra tabella con l'indice clustered sarà fatta in questo modo:

Ora scendiamo ancora più in dettaglio e vediamo cosa accade quando scriviamo la nostra pagina di memoria.

Diciamo subito che non possiamo scrivere in modo concorrente la stessa pagina in memoria.
Ovvero, quando un thread scrive all'interno di una pagina tutti gli altri non posso leggere la stessa pagina nello stesso tempo.

E come fa SQL Server a garantire questo funzionamento?
Semplice! Lo realizza tramite una procedura di sincronizzazione.

Le pagine di memoria (e le relative strutture che servono a gestirle) vengono sincronizzate attraverso degli oggetti detti latch.
Ogni volta che viene letta una pagina, il thread acquisisce un latch di tipo Shared (SH).
Ogni volte che invece viene scritta una pagina il thread acquisische una latch di tipo esclusivo (EX).
I due tipi di Latch sono incompatili.

Quindi, quando eseguiamo uno statement di insert il thread pone un Latch di tipo EX sulla pagina in cui stiamo inserendo i dati.
In questo momento nessun altro potrà leggere o scrivere dentro a questa pagina.

Per questo motivo se la nostra tabella ha un indice clustered su un campo autoincrementante, come dicevo prima, l'operazione di INSERT non scalerà in funzione del numero di utenti che inseriscono dati.
Tutti gli utenti cercheranno infatti di inserire dati alla fine dell'indice clustered e accadrà alla fine che tutti inseriranno i dati, ma uno dopo l'altro serialmente.
Siamo arrivati a capire quindi cos'è il famoso effetto detto "Last Page Insert Latch Contention"!

Come evitarlo?

Bhe ci sono metodi che permettono di limitare questo effetto e metodi per evitarlo.
Ma di tutto questo parleremo al prossimo artico!


ciao,

Luca Biondi @ SQLServerPerformance blog!

Next post: The last page insert latch contention issue. Come Evitarla! parte 2

Previous post: Come cambiare il tipo di autenticazione di SQL Server