Vantaggi dei filegroup e impostazione dei filegroup in sola lettura

Qualcuno può citarmi uno scenario del mondo reale su quando cambiare più filegroup in sola lettura è una buona opzione e quando usarli? Quali sono i vantaggi se lo imposti in sola lettura?

Su un database con più filegroup, è necessario eseguire backup per l'intero database e eseguire il backup di ciascuno dei file di quel filegroup? Potete darmi anche un esempio di quando verranno utilizzati i backup di filegroup? Non vedo perché sarebbe utile eseguire il backup di un filegroup quando è possibile eseguire il backup dell'intero database. Spero di poter vivere un'esperienza reale in cui questo backup di filegroup sarebbe l'ideale

La tua domanda è un po 'ampia, tuttavia alcuni dei punti principali includono quanto segue.

Più gruppi di file, in generale:

• può essere un miglioramento delle prestazioni, supponendo che siano fisicamente isolate. In genere, è possibile creare un filegroup per gli indici cluster, un filegroup per gli indici non cluster e un filegroup per gli heap. Oppure potresti creare più filegroup in una situazione di partizionamento.

• può migliorare la recuperabilità consentendo il ripristino pezzo-pasto . Il ripristino dei singoli pasti può essere utilizzato per portare rapidamente online dati critici sulla produzione, consentendo al contempo di ripristinare i dati di archivio senza influire sulle attività online. Tenere presente che il ripristino dei pasti online è un'opzione "Solo Enterprise". Ho scritto un post sul blog che mostra come eseguire ripristini pezzo-pasto su SQLServerScience.com

• non è necessario eseguire il backup individualmente, tuttavia possono essere sottoposti a backup individualmente, il che potrebbe essere necessario per i VLDB. Nota, quando si esegue il backup di singoli filegroup è necessario eseguire anche il backup del filegroup primario.

Gruppi di file di sola lettura:

• Può essere utilizzato per ridurre la contesa per i dati di sola segnalazione.

• Può essere utilizzato, ovviamente, per impedire modifiche ai dati.

• Non è necessario eseguire il processo di ripristino quando il database viene portato in linea. Ciò può migliorare sostanzialmente i tempi di recupero per i VLDB.

• Inoltre, mentre gruppi di file di lettura-scrittura non possono essere utilizzati con la compressione basata su file system NTFS, di sola lettura filegroup can . L'implicazione qui è che per un insieme molto limitato di sistemi potresti essere in grado di vedere un leggero miglioramento delle prestazioni per i dati VLDB che risiedono su dischi più lenti comprimendo i file di filegroup di sola lettura su disco. Questo dovrebbe ovviamente essere valutato caso per caso rispetto al sovraccarico della CPU necessario per decomprimere i cluster NTFS mentre vengono letti dal disco.

Miti che circondano i filegroup di sola lettura:

• "Le statistiche non verranno mai aggiornate per le tabelle archiviate in un filegroup di sola lettura." Questo è totalmente errato e può essere dimostrato creando un banco di prova come mostrato nel mio post sul blog su SQLServerScience.com . Grazie a @PaulWhite per avermelo segnalato.

• "Non si verifica alcun blocco nei database di sola lettura. Ciò può causare prestazioni delle query più rapide ". Ciò non è corretto a meno che l' intero database non sia di sola lettura. Un solo filegroup di sola lettura non consente di saltare i blocchi condivisi .