Il nostro database attualmente ha solo un FileGroup, PRIMARY, che contiene circa 8 GB di dati (righe di tabella, indici, catalogo full-text).
Quando è un buon momento per dividerlo in file di dati secondari? Quali sono alcuni criteri di cui dovrei essere a conoscenza?
Risposte:
Ci sono due parti in questa domanda: quando aggiungere un nuovo FILEGROUP e quando aggiungere un nuovo FILE in un filegroup. Per prima cosa parliamo di teoria:
Mark ha ragione sul motivo principale per cui le prestazioni.
Il motivo secondario è il ripristino di emergenza. Con SQL Server 2005 e versioni successive, è possibile eseguire ripristini di filegroup. Quando si verifica un disastro, è possibile ripristinare prima solo il filegroup primario e rendere parzialmente online il database per le query. Gli utenti possono eseguire query mentre ripristini altri filegroup. Ciò è utile per i database con una grande quantità di dati storici che potrebbero non essere richiesti immediatamente o per i data warehouse che devono caricare i dati nelle tabelle correnti senza bisogno di dati storici per l'accesso.
Un altro motivo è il profilo di lettura / scrittura di gruppi di dati. Se si dispone di alcuni dati su cui viene costantemente scritto e altri dati che richiedono attività di lettura pesanti, è possibile creare diversi tipi di archiviazione per soddisfare tali esigenze. Potresti mettere le cose pesanti nel raid 10 e lasciare le cose distorte in lettura nel raid 5 più economico.
Ora parliamo di file rispetto a filegroup. Quando si posizionano oggetti in SQL Server, è necessario posizionarli a livello di filegroup. È possibile inserire una tabella o un indice in un filegroup, ma non è possibile selezionare un file specifico. Quindi tutto ciò di cui abbiamo discusso finora riguardava quando aggiungere un filegroup - ma quando aggiungi un file?
Se stai progettando spazio di archiviazione e hai 80 dischi rigidi, ci sono alcuni modi in cui puoi romperlo:
Diversi sottosistemi di archiviazione hanno profili delle prestazioni diversi. Ho lavorato con alcune SAN che si sono comportate meglio con array di unità 12-16 e qualsiasi cosa più grande di così non ha avuto un miglioramento delle prestazioni. Un altro esempio sono le SAN con multipath: se hai diversi HBA che collegano il tuo server alla tua memoria e se il tuo software multipath non è realmente attivo / attivo, potresti aver bisogno di un array per percorso per distribuire il carico. Quattro percorsi, quattro pool di unità offriranno prestazioni migliori su questi tipi di unità.
In questi casi, si ottengono quattro array diversi, quattro unità diverse in Windows (a meno che non si utilizzino punti di montaggio e anche in questo caso si tratti di cartelle diverse) e saranno necessari quattro file separati in SQL Server. Quei file separati possono essere nello stesso filegroup.
Il motivo principale è la prestazione. Quando si esaurisce la capacità IOPS sull'unità disco del filegroup primario, è necessario espandersi in un secondo filegroup per dividere gli IOP su più dischi / LUN a seconda della configurazione dell'archiviazione.
EDIT: Brad Wilson ha fatto un buon commento in merito agli SSD. Se si utilizza un sistema di archiviazione SSD / SATA / FC composito, è possibile che si desideri disporre di filegroup diversi su diversi tipi di archiviazione. È quindi possibile inserire le tabelle dei requisiti IOPS estremi su filegropus SSD, mentre le tabelle cronologiche / statistiche possono essere archiviate in filegroup SATA economici.
Vorrei anche sottolineare che esiste un aspetto di recuperabilità / disponibilità dei dati anche a questa domanda. Utilizzando più gruppi di file e non posizionando oggetti definiti dall'utente nel gruppo di file primario, si dispone di una maggiore flessibilità nell'abilitazione dei ripristini online. ciò consente il ripristino frammentario a livello di gruppo di file.
Il ripristino online è disponibile nelle edizioni Enterprise e Developer del server sql successive al 2005
Un altro pensiero che viene in mente è quello di separare i dati di riferimento statici di sola lettura dai dati transazionali. Per database di dimensioni maggiori, ciò potrebbe ridurre la quantità di tempo e / o spazio necessario per eseguire un backup.