C'è qualche vantaggio nella deframmentazione degli indici SQL in un ambiente SAN?

16

Il nostro server SQL vive su una SAN. Contiene dozzine di database OLTP, alcuni con diverse tabelle contenenti oltre 1 milione di record.

Abbiamo eseguito settimanalmente gli script di manutenzione dell'indice di Ola Hallengren , che funzionano per diverse ore ogni volta. In base alla soglia di frammentazione, lo script riorganizza o reindicizza un indice. Abbiamo osservato che durante la reindicizzazione, i file di registro diventano enormi, il che comporta un consumo eccessivo di larghezza di banda durante la spedizione dei registri.

Poi arriva un articolo di Brent Ozar in cui dice di smettere di preoccuparsi degli indici SQL :

I tuoi dischi rigidi sono condivisi con altri server che fanno anche richieste di unità contemporaneamente, quindi le unità salteranno sempre ovunque per ottenere dati. La deframmentazione degli indici è solo un lavoro occupato senza senso.

Cercare su Google questa domanda porta a opinioni diverse, la maggior parte supportate da argomenti che sembrano troppo brevi o deboli. Il nostro piano provvisorio è di regolare la soglia di frammentazione nel nostro script di manutenzione in modo che si riorganizzi molto più spesso di quanto reindicizzi.

Qual è il verdetto finale? Vale la pena deframmentare gli indici SQL su una SAN tenendo conto degli oneri associati all'esecuzione di lavori di manutenzione settimanali?

— dev_etter
fonte

10

Le strategie di deframmentazione aiutano a migliorare la velocità di scansione da / verso il disco .

L'ampia varietà di opinioni è dovuta al fatto che la strategia di deframmentazione ideale di un ambiente dovrebbe dipendere da molti fattori diversi. Ci sono anche più livelli potenziali di frammentazione in gioco.

Dire che i tuoi database sono archiviati su una SAN non è abbastanza informazioni. Per esempio:

I file di database sono archiviati su gruppi RAID fisici separati o sullo stesso gruppo RAID? Quali altri processi sono attivi sullo stesso dispositivo? Anche i tuoi file di backup finiscono qui? Potrebbe essere necessario chiedere queste informazioni al proprio amministratore SAN, poiché non è sempre trasparente.
Quali sono i modelli di accesso per i database? OLTP è generalmente un accesso casuale, ma a volte un'applicazione è felice della scansione della tabella e non è possibile modificarne il comportamento (app ISV). Le applicazioni sono per lo più in lettura, per lo più in scrittura o da qualche parte nel mezzo?
Esistono SLA delle prestazioni in gioco durante un periodo di recupero / failover ?

Il post di Brent presuppone che ci sia un gigantesco pool di archiviazione e tutto lo condivide. Ciò significa che i dischi fisici sono raramente inattivi e quindi la maggior parte dell'accesso è casuale. Se questa è la tua situazione, allora si applica il consiglio e per la maggior parte sono d'accordo. Sebbene questo tipo di strategia sia molto più facile da gestire, non è necessariamente (a) quello che hai nel tuo ambiente, o (b) qual è la soluzione migliore per il tuo ambiente.

Se la manutenzione dell'indice è onerosa, considerare di farlo in modo meno aggressivo e / o ammortizzare il costo nel corso della settimana (ad esempio, eseguire una manutenzione leggera una volta al giorno, anziché una manutenzione pesante una volta alla settimana).

È inoltre possibile attivare l' SortInTempdbopzione per ridurre potenzialmente la quantità di registrazione che avviene nei database degli utenti.

— Jon Seigel
fonte

Caspita, risposta approfondita. Probabilmente ci vorrà del tempo per fare tutte le ricerche, ma non dubito che mi stai portando sulla strada giusta. La nostra attuale strategia è infatti quella di eseguire la manutenzione in modo meno aggressivo sia dal punto di vista della ricostruzione che del rimpatrio, penso di averlo frainteso nella domanda. Da lì farò ulteriori ricerche sul resto dei fattori che hai citato.

— dev_etter,

1

@dev_etter: ho elencato solo alcuni fattori; ce ne sono molti altri. Il punto principale è la prima frase. Se lo tieni a mente quando pensi attraverso il tuo ambiente, dirigerà correttamente la tua decisione. Tutto deriva da quello. (Inoltre, tutto ciò presuppone che non siano coinvolti SSD.)

— Jon Seigel,

FWIW, avevo trascurato qualcosa completamente: lo script effettivo nella fase di lavoro (piuttosto che l'origine) era configurato per indirizzare tutti gli indici che avevano una percentuale minima di frammentazione di 1. Ho superato quello fino a 15 e anche aumentato la soglia di ricostruzione da 30 a 35. Il lavoro ora viene eseguito in poco più di 3 ore anziché 8. Il tuo suggerimento di essere meno aggressivo era corretto. La mia colpa risiedeva nel fatto che pensavo che il lavoro fosse già stato implementato per essere meno aggressivo. Questo approccio è probabilmente il migliore per noi, ancora toccare e andare ma ha già alleviato un po 'di dolore.

— dev_etter,

@JonSeigel Concordo pienamente con questa risposta. Nei miei viaggi vedo la maggior parte dei DBA che condividono un singolo pool, o almeno un array allo stesso livello RAID. Ho avuto DBA su 3AM 24x7 solo per deframmentare singoli filegroup di database da 100 + TB ... e per cosa esattamente? Avevamo un IO totalmente casuale sui dischi e la latenza era di 15ms. A quel punto dovrei solo puntare a 15ms e dire agli sviluppatori di lasciarmi in pace.

— outwire

2

Idealmente, dovresti riorganizzare / reindicizzare SOLO quegli indici che richiedono attenzione, altrimenti stai sprecando risorse e potenzialmente causando altri problemi.

È necessario stabilire una baseline delle prestazioni e ogni volta che si apportano modifiche confrontare la modifica delle prestazioni con la baseline per determinare se vale la pena implementare la modifica.

— Jimbo
fonte

La nostra strategia immediata è di fare proprio questo: andremo a modificare le impostazioni per le variabili minFragmentation e rebuildThreshold in questo script: sqlfool.com/2011/06/index-defrag-script-v4-1

— dev_etter

0

Va bene, la domanda riguarda gli indici di database, che sono un costrutto di un file o un insieme di file. Leggere le risposte sopra induce una persona a credere che stiamo parlando di frammentazione a livello del disco e non degli indici all'interno di un file. Questi soggetti totalmente separati.

L'approccio miope qui è che le prestazioni durante il recupero dei dati all'interno e il database OLTP miglioreranno se gli indici sono frammentati o ricostruiti. La risposta è si! Tuttavia, è importante notare che anche la frammentazione del disco è un fattore.

Il "costo" più basso nel complesso? Fai la tua manutenzione del database. Secondo costo più basso, scollegare il database, spostarlo altrove, riformattare i dischi e seguire le migliori pratiche per l'allineamento delle partizioni del disco http://msdn.microsoft.com/en-us/library/dd758814.aspx . Ultimo ma non meno importante, utilizzare una deframmentazione avanzata di terze parti come Diskkeeper.

Tieni presente che questo è consigliato SOLO per l'archiviazione di tipo NTFS (ad es. Sistema operativo Windows) e non costituisce un'approvazione per alcun prodotto né sono affiliato a Condusiv Technologies o alle sue filiali.

— IryDBA2791
fonte

2

Probabilmente vuoi evitare di dire categoricamente "La risposta è SÌ!" agli spazi problematici che sono stati discussi a lungo da altri poster. Mentre può essere vero che a volte la risposta è "Sì", come ha mostrato Brent Ozar nel suo post sul blog, non è sempre così.

— Max Vernon