Avantage des groupes de fichiers et paramétrage des groupes de fichiers en lecture seule

Quelqu'un peut-il me citer un scénario du monde réel lorsque le changement de plusieurs groupes de fichiers en lecture seule est une bonne option et quand les utiliser? Quels sont les avantages si vous le définissez en lecture seule?

Sur une base de données avec plusieurs groupes de fichiers, devez-vous effectuer des sauvegardes pour l'ensemble de la base de données et également sauvegarder chacun des fichiers de ce groupe de fichiers? Pouvez-vous également me donner un exemple d'utilisation des sauvegardes de groupes de fichiers? Je ne vois pas pourquoi il serait avantageux de sauvegarder un groupe de fichiers alors que vous pouvez simplement sauvegarder toute la base de données. En espérant que je pourrais obtenir une expérience du monde réel où cette sauvegarde de groupe de fichiers serait idéale

Votre question est un peu large, mais certains des principaux points sont les suivants.

Plusieurs groupes de fichiers, en général:

• peut être une amélioration des performances, en supposant qu'ils sont physiquement isolés. En règle générale, vous pouvez créer un groupe de fichiers pour les index clusterisés, un groupe de fichiers pour les index non clusterisés et un groupe de fichiers pour les segments. Ou vous pouvez créer plusieurs groupes de fichiers dans une situation de partitionnement.

• peut améliorer la récupérabilité en activant la restauration à la pièce . La restauration à la pièce peut être utilisée pour mettre rapidement en ligne les données de production critiques tout en permettant à la restauration des données d'archivage de ne pas affecter les activités en ligne. Soyez conscient que la restauration en ligne à la pièce est une option "réservée aux entreprises". J'ai écrit un article de blog montrant comment effectuer des restaurations à la pièce sur SQLServerScience.com

• n'ont pas besoin d'être sauvegardés individuellement, mais ils peuvent être sauvegardés individuellement, ce qui peut être nécessaire pour les VLDB. Remarque: lors de la sauvegarde de groupes de fichiers individuels, vous devez également sauvegarder le groupe de fichiers principal.

Groupes de fichiers en lecture seule:

• Peut être utilisé pour réduire les conflits pour les données de rapports uniquement.

• Peut être utilisé, évidemment, pour empêcher les modifications des données.

• Il n'est pas nécessaire d'exécuter le processus de récupération lorsque la base de données est mise en ligne. Cela peut considérablement améliorer le temps de récupération des VLDB.

• En outre, bien que les groupes de fichiers en lecture-écriture ne puissent pas être utilisés avec la compression basée sur le système de fichiers NTFS, les groupes de fichiers en lecture seule le peuvent . L'implication ici est que pour un ensemble très limité de systèmes, vous pouvez voir une légère amélioration des performances pour les données VLDB qui résident sur des disques plus lents en compressant les fichiers de groupe de fichiers en lecture seule sur le disque. Cela devrait bien sûr être évalué au cas par cas par rapport à la surcharge du processeur nécessaire pour décompresser les clusters NTFS lors de leur lecture sur le disque.

Mythes entourant les groupes de fichiers en lecture seule:

• "Les statistiques ne seront jamais mises à jour pour les tables stockées dans un groupe de fichiers en lecture seule." Ceci est totalement incorrect et peut être prouvé en créant un banc d'essai comme indiqué dans mon article de blog sur SQLServerScience.com . Merci à @PaulWhite de me l' avoir signalé.

• "Aucun verrouillage ne se produit dans les bases de données en lecture seule. Cela peut accélérer les performances des requêtes ". Ceci est incorrect, sauf si la base de données entière est en lecture seule. Un groupe de fichiers en lecture seule ne permet pas d'ignorer les verrous partagés .