Perché non ricostruire gli indici con numero di pagine <1000?

Uso lo script di Ola Hallengrens per la manutenzione dell'Indice. Prima di farlo, ho usato la seguente query per vedere quali indici sono maggiormente frammentati:

SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
ORDER BY indexstats.avg_fragmentation_in_percent desc

Nel mio caso, avg_fragmentation ha superato il 70% per 15 indici e oltre il 30% per 28 indici.

Quindi, ricostruisco ogni indice usando la soluzione di Ola Hallengren. Quando ho eseguito nuovamente la query, questo era il risultato:

Frammentazione oltre il 70% per 12 indici, oltre il 30% per 15 indici.

Ho pensato, il motivo era a causa del page_count, che era inferiore a 1000 per ciascuno degli indici che erano ancora molto frammentati. Ad esempio, uno degli indici con un valore page_count di 967 ha una percentuale di frammentazione del 98,98% ! Per me, vale la pena ricostruire quell'indice! L'ho fatto e, successivamente, la frammentazione è stata dello 0% . Inoltre, un indice con a page_countdi 132 è passato dal 95% allo 0%

Quindi, la mia domanda è: quali motivi ci sarebbero per NON ricostruire quegli indici? Una ragione potrebbe essere che la ricostruzione costa tempo e risorse, ma poiché gli indici sono piccoli, ciò non significa che costa relativamente poche risorse e sarebbe comunque ben ricostruibile ricostruirla?

Ci sono più domande correlate su questo sito, ma tutte rispondono alla domanda sul perché un indice non deframmenterebbe o se gli indici sono ancora utili se sono piccoli e non li deframmentate, mentre qui l'affermazione diminuisce la frammentazione, con la domanda è, perché non farlo comunque?

La guida relativa al numero minimo di pagine è in qualche modo arbitraria . I maggiori vantaggi della riduzione della frammentazione sono:

1. Può migliorare le prestazioni read-ahead per le scansioni ad ampio raggio; e
2. Potrebbe migliorare la densità della pagina (numero di righe per pagina)

Entrambi questi fattori sono meno importanti per i piccoli indici, per definizione.

Il contro-argomento per ricostruire piccoli indici è essenzialmente:

"Perché preoccuparsi? Non hai cose più importanti di cui preoccuparti?".

Detto questo, la ricostruzione / riorganizzazione non è gratuita. In alcuni casi può essere utile evitare lo sforzo aggiuntivo e la generazione dei registri (ad esempio, se il registro viene spedito / copiato su una WAN per un numero qualsiasi di possibili motivi: mirroring, gruppi di disponibilità, replica ...). Inoltre, a meno che (o anche se, in alcuni casi) non si stia ricostruendo online, la ricostruzione potrebbe influire su altri processi simultanei attraverso il blocco. Infine, per gli indici di piccole dimensioni, la ricostruzione potrebbe anche non ridurre la frammentazione comunque, a causa delle allocazioni da estensioni miste (a meno che non si stia eseguendo il flag di traccia 1118 abilitato).

Se ti senti ancora più felice a ricostruire questi piccoli indici e non ti dispiace le conseguenze, allora cambia il valore del @PageCountLevelparametro passato alla procedura di Ola.

Vedi la registrazione PASS TV della presentazione di Paul Randal sulla frammentazione dell'indice per tutti i dettagli.

Potresti anche guardare Brent Ozar parlare del perché la frammentazione dell'indice non ha importanza in SQL Server.