Quando gli indici non cluster devono essere archiviati in filegroup separati?

Ho sentito che la memorizzazione di indici in un filegroup e un'unità diversi aumenta le prestazioni in un database perché l'unità non deve andare avanti e indietro tra l'indice e i dati a cui si riferisce l'indice. Ho anche sentito che questo è un mito.

Quando è consigliabile archiviare indici non cluster su un filegroup e un'unità separati? Quali prove di perfmon / profiler mi porterebbero ad arrivare a quella conclusione? L'hardware ha un ruolo nella decisione (se un RAID / SAN viene utilizzato su una singola unità)?

La parte più lenta di un sistema DB sono le unità disco. L'eliminazione dei colli di bottiglia a livello del disco migliorerà le prestazioni. Quando i dati vengono cercati e viene utilizzato un indice, l'indice viene prima cercato e quindi vengono recuperati i dati corrispondenti. Se sia l'indice che i dati si trovano sugli stessi dischi, si verifica una contesa. Considerando che, se i dati si trovavano su un altro disco (fisico), allora si verifica un IO più veloce, aumentando così le prestazioni. La parte principale da notare è che i dati o l'indice si trovano su dischi fisici o LUN separati.

Utilizzeresti uno scenario del genere se hai bisogno di ottenere prestazioni migliori dal tuo sistema, a condizione che tu abbia i dischi. Per i vostri contatori Perfmon si potrebbe utilizzare Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec, Physical Disk – Disk Writes/secdi avere un prima e dopo il confronto delle modifiche.

È certamente vero che la diffusione dell'I / O simultaneo tra unità diverse aumenterà le prestazioni, non è un mito. È un mito è che farlo due volte migliorerà di nuovo le prestazioni.

Se sei STESSO , dividere l'array in due partizioni e mettere gli indici su uno e le tabelle su un altro è una perdita di tempo.

Separare gli indici dai dati in filegroup separati = il miglioramento delle prestazioni è altamente discutibile. Il miglioramento delle prestazioni "può" verificarsi se si dispone dell'hardware sottostante per supportarlo, ma solo dal fatto che separarli in diversi filegroup non ti dà il massimo. Inoltre, NON è facile misurare l'incremento di perf per questo motivo.

Rif: http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx

Dovresti prima porre la domanda. Perché hai bisogno di fare questo?

1. Stai cercando di migliorare le prestazioni dei backup NON includendo gli indici?
2. Stai cercando di migliorare le prestazioni di lettura e scrittura su questi indici?
3. Lo stai facendo per una migliore gestibilità del posizionamento degli oggetti sottostanti?
4. Avete grandi volumi di dati con esigenze di prestazione variabili?
5. Stai cercando di utilizzare SSD per indici non cluster per migliorare le prestazioni ecc ...

Ho esaminato questo compito per supportare la necessità del n. 5 nell'elenco sopra e mi sembra una buona proposta anche se non ci siamo ancora impegnati.

Nota che questa decisione NON è così facile da prendere e devi capire cosa stai cercando di fare e assicurarti di avere l'hardware da supportare. Non apportare modifiche come questa a meno che tu non abbia testato bene e non visualizzi un aumento significativo di perf, altrimenti potresti anche abbandonare questa idea. NON ne vale la pena se ti aspetti un potenziamento perf semplicemente separando gli indici in filegroup separati.

Ti racconterò la mia esperienza personale riguardo a questo oggetto. Gli indici non cluster devono essere archiviati in un filegroup separato quando l'unità disco corrente non è abbastanza grande per lo spazio necessario :-). Puoi ridere a riguardo .. ma succede.

Quindi una soluzione di emergenza per noi, quando stavamo per rimanere senza spazio libero su un'unità dati, era creare uno script piacevole per ricreare tutti gli indici non cluster online su un nuovo filegroup su un'unità con spazio libero. Si potrebbe pensare che sia facile e veloce acquistare nuovo spazio di archiviazione .. ma non è così, davvero.

Per quanto riguarda le prestazioni non abbiamo visto nulla di straordinario dopo il trasloco. Ma è una grande scatola di memoria SAN in cui tutto è tenuto insieme :-).

In generale; la suddivisione di dati e indici su dischi separati con prestazioni simili può aumentare le prestazioni per operazioni di scrittura sostanziali su quella tabella o operazioni di lettura di grandi dimensioni che utilizzano tale indice. Una metodologia simile ad alcune altre operazioni I / O, come una tabella partizionata distribuita su più dischi fisici.

Tuttavia, dipende anche in gran parte dall'archiviazione . Per esempio; se hai un server con un bel Fushion ioDrive (o qualcosa di simile) e hai anche singoli dischi rotanti. Potrebbe essere più vantaggioso conservare tutto su ioDrive (a meno che lo spazio non sia limitato). Ci sono anche altre cose da prendere in considerazione: configurazione RAID, configurazione dell'archiviazione di rete.

Esegui dei benchmark su un server di prova con hardware simile o (solo se un server secondario non è un'opzione) durante le ore non di punta con dati temporanei. Il link DBA-Monkey di Sankar sopra è un buon spunto di riflessione.