SQL Server 2005/2008 - più file / filegroup - quanti? Perché?

Sono uno sviluppatore a cuore - ma ogni tanto, un cliente non ha un DBA decente per affrontare questi problemi, quindi sono chiamato per decidere ...

Quali sono le tue strategie / buone pratiche quando si tratta di gestire un database SQL Server di dimensioni ragionevoli (qualcosa di più grande di Northwind o AdventureWorks; circa 2-4 GB di dati più indici ecc.) - usi più file / filegroup?

In tal caso: quanti? E perché?

Quali sono i tuoi criteri per decidere quando abbandonare l'approccio "un filegroup per tutto":

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

Se usi più gruppi di file, quanti ne usi? Uno per i dati, uno per l'indice, uno per il registro? Diversi (quanti) per i dati? Quali sono i motivi della tua scelta - perché usi quel numero esatto di filegroup :-)

Grazie per eventuali suggerimenti, suggerimenti, pensieri!

Saluti, Marc

La regola empirica di base è quella di separare i file su volumi diversi per evitare contese, tuttavia la quantità di prestazioni ottenute varia notevolmente a seconda del sottosistema I / O e del carico di lavoro. Ad esempio, più file su un singolo mandrino fisico risucchiano per quanto riguarda le prestazioni, ma la stessa disposizione con il volume su un LUN SAN con diverse centinaia di unità dagli array RAID 10 potrebbe andare bene. I contatori della lunghezza della coda del disco sono i tuoi amici come il modo più semplice per sapere se hai un collo di bottiglia I / O.

Stai osservando i modelli I / O sui database - sola lettura, lettura, scrittura, scrittura, scrittura - e basandoti su questo. È inoltre necessario scegliere il giusto livello RAID e assicurarsi che gli offset della partizione del disco, la dimensione dello striping RAID e la dimensione dell'unità di allocazione NTFS siano impostati correttamente. Ad alcune persone piace separare gli indici non cluster in un filegroup separato, ma i miglioramenti delle prestazioni qui variano proprio come ho spiegato sopra.

Oltre alle prestazioni, è necessario considerare la gestibilità e la recuperabilità. Avere un singolo file di dati monolitici per un database da 100 GB significa che l'unità di ripristino è quel file. La suddivisione in 4 filegroup da 25 GB significa che è possibile utilizzare la disponibilità parziale del database e il ripristino frammentario per ripristinare solo un singolo filegroup nel caso in cui venga danneggiato. Partizionando tabelle e indici in più filegroup è anche possibile limitare le parti del database interessate dalle operazioni di manutenzione (ad es. Rimozione della frammentazione dell'indice).

Tempdb è un caso del tutto speciale, e ti indicherò un mio post sul blog che spiega tutto sul perché e come dividere tempdb: ci sono molte idee sbagliate là fuori.

Senza darti una raccomandazione di "generalizzazione generale" qui, ti indicherò un sacco di white paper e post di blog che puoi leggere:

• White paper: progettazione dell'archiviazione di database fisici
• White paper: Best Practices I / O Predeployment
• White paper: tabelle e indici partizionati in SQL Server 2005

• White paper: disponibilità parziale del database

• Post del blog: idee sbagliate intorno a TF 1118 (layout tempdb)

• Post di blog: gli offset della partizione del disco, le dimensioni dello striping RAID e le unità di allocazione NTFS sono impostati correttamente? (con collegamento al white paper sulla partizione del disco)

Spero che questo ti aiuti!

La decisione di suddividere un database in diversi filegroup dovrebbe essere presa dopo aver analizzato le dimensioni attuali e la crescita futura delle tabelle. A mio avviso, a meno che tu non abbia un database di grandi dimensioni o tabelle con milioni di righe, dovresti considerare attentamente i pro e i contro, poiché potresti finire per creare più problemi di prestazioni di quelli che risolvi.

Esistono alcuni scenari che potrebbero essere interessanti in determinate premesse:

• 2 filegroup: dati e indice
• 3 filegroup: tabelle di sola lettura, tabelle di lettura-scrittura, indice
• più filegroup: sola lettura, lettura-scrittura, indice, tabella chiavi 1, tabella chiavi 2, ...

Devi analizzare il tuo ambiente per decidere se i filegroup aiuteranno le tue esigenze di crescita, utilizzo e prestazioni di SQL Server.

Alcuni indicatori chiave per passare a più filegroup (da questo articolo ):

• Quando l'accodamento del disco causa problemi relativi all'applicazione e all'utente
  • In tal caso, prendere in considerazione la possibilità di sfruttare unità disco aggiuntive con nuovi filegroup che ospitano tabelle ad alta intensità di I / O
• Quando determinate tabelle rappresentano il 10% o più del database
  • In tal caso, considerare di spostare queste tabelle particolarmente grandi in filegroup separati su unità disco sottostanti separate
  • A seconda delle dimensioni della tabella in proporzione al resto delle tabelle, prendere in considerazione la creazione di un filegroup per le singole tabelle
• Quando l'indice e lo spazio dati non cluster sono uguali su tabelle di grandi dimensioni
  • In tal caso, prendere in considerazione la suddivisione dei dati e dell'indice cluster dagli indici non cluster
• Quando nel database esiste una percentuale quasi uguale di dati di sola lettura e di lettura / scrittura
  • In tal caso, considerare la suddivisione dei dati di sola lettura in un filegroup separato come dati di lettura / scrittura
• Quando non è disponibile tempo sufficiente per eseguire la manutenzione del database
  • In tal caso, prendere in considerazione la suddivisione delle tabelle di grandi dimensioni in filegroup separati su diversi dischi sottostanti ed eseguire la manutenzione in parallelo
• Quando l'azienda o l'applicazione cambieranno in modo significativo e i dati cresceranno a un ritmo molto più elevato
  • In questo caso, considera di collaborare con gli utenti per comprendere la potenziale crescita
• Quando i dati archiviati risiedono nello stesso database dei dati di produzione
  • In questo caso, prendere in considerazione gruppi di file separati o una o più tecniche in questo suggerimento: archiviazione dei dati in SQL Server

Se si ritiene che i filegroup possano migliorare le prestazioni del database, scrivere il codice e testare il processo in un ambiente di gestione temporanea prima di implementare le modifiche sui server di produzione. Preparare alcune misurazioni prima di implementare le modifiche e confrontarle prima / dopo. Poiché questi processi possono richiedere molte risorse e richiedere molto tempo, eseguire queste procedure durante un periodo di manutenzione.

Non dimenticare, durante la creazione di nuovi oggetti (tabelle e indici), assicurarsi che gli oggetti vengano creati nel filegroup corretto per garantire le prestazioni previste e convalidare periodicamente gli oggetti del database nei filegroup corretti e correggere secondo necessità.