Dans SQL Server, quand devez-vous fractionner votre PRIMARY Data FileGroup en fichiers de données secondaires?
11
Notre base de données n'a actuellement qu'un seul FileGroup, PRIMARY, qui contient environ 8 Go de données (lignes de table, index, catalogue de texte intégral).
Quel est le bon moment pour le diviser en fichiers de données secondaires? Quels sont les critères que je devrais connaître?
Cette question comporte deux parties: quand ajouter un nouveau FILEGROUP et quand ajouter un nouveau FILE dans un groupe de fichiers. Parlons d'abord de la théorie:
Mark a raison sur la principale raison d'être de la performance.
La raison secondaire est la reprise après sinistre. Avec SQL Server 2005 et versions ultérieures, vous pouvez effectuer des restaurations de groupes de fichiers. En cas de catastrophe, vous pouvez d'abord restaurer uniquement votre groupe de fichiers principal et mettre la base de données partiellement en ligne pour les requêtes. Les utilisateurs peuvent exécuter des requêtes pendant que vous restaurez d'autres groupes de fichiers. Ceci est utile pour les bases de données contenant une grande quantité de données historiques qui peuvent ne pas être nécessaires immédiatement, ou les entrepôts de données qui doivent charger des données dans les tables actuelles sans avoir besoin de données historiques pour l'accès.
Une autre raison est le profil de lecture / écriture de groupes de données. Si vous avez des données qui sont constamment écrites et d'autres données qui nécessitent une activité de lecture intense, vous pouvez créer différents types de stockage pour répondre à ces besoins. Vous pouvez mettre les trucs lourds sur le raid 10 et laisser les trucs biaisés en lecture sur le raid 5 moins cher.
Parlons maintenant des fichiers par rapport aux groupes de fichiers. Lorsque vous placez des objets dans SQL Server, vous devez les placer au niveau du groupe de fichiers. Vous pouvez atterrir une table ou un index dans un groupe de fichiers, mais vous ne pouvez pas choisir un fichier spécifique. Donc, tout ce dont nous avons discuté jusqu'à présent concernait l'ajout d'un groupe de fichiers - mais quand ajoutez-vous un fichier?
Si vous concevez du stockage et que vous disposez de 80 disques durs, vous pouvez le répartir de plusieurs manières:
Un pool de 80 disques
Deux pools de 40 disques
Quatre pools de 20 disques, etc ...
Différents sous-systèmes de stockage ont des profils de performances différents. J'ai travaillé avec certains réseaux SAN qui fonctionnaient le mieux avec des baies de disques 12-16, et tout ce qui était plus grand que cela n'a pas amélioré les performances. Un autre exemple est celui des SAN avec multichemin: si vous avez plusieurs HBA connectant votre serveur à votre stockage, et si votre logiciel de multichemin n'est pas réellement actif / actif, vous devrez peut-être une baie par chemin pour répartir la charge. Quatre chemins, quatre pools de lecteurs obtiendront de meilleures performances sur ces types de lecteurs.
Dans ces cas, vous vous retrouvez avec quatre tableaux différents, quatre lecteurs différents sous Windows (sauf si vous utilisez des points de montage, et même alors ce sont des dossiers différents) et vous aurez besoin de quatre fichiers distincts dans SQL Server. Ces fichiers séparés peuvent être dans le même groupe de fichiers.
Yup ... analyse ponctuelle des avantages. La seule chose que j'ajouterais, c'est que vous pouvez également souvent décharger des index de tables fortement accédées vers leurs propres broches / groupes de fichiers pour améliorer les performances d'async / lecture anticipée. Je l'ai fait dans quelques cas avec des déploiements plus importants et j'ai aidé les entreprises à économiser des dizaines de milliers de dollars de coûts matériels dont leurs fournisseurs de SAN avaient juré avoir besoin pour obtenir le débit souhaité.
Michael K Campbell
6
La raison principale est la performance. Lorsque vous manquez de capacité IOPS sur votre lecteur de disque de groupe de fichiers principal, vous devrez vous étendre sur un deuxième groupe de fichiers pour diviser les IOPS sur plusieurs disques / LUN en fonction de la configuration de stockage.
EDIT: Brad Wilson a fait un bon commentaire concernant les SSD. Si vous utilisez un système de stockage composite SSD / SATA / FC, vous souhaiterez peut-être avoir différents groupes de fichiers sur différents types de stockage. Vous pouvez ensuite placer vos tableaux d'exigences IOPS extrêmes sur le groupe de fichiers SSD, tandis que les tableaux d'historique / statistiques peuvent être stockés sur des groupes de fichiers SATA bon marché.
Les SSD ont une chance de faire un énorme changement dans notre façon de penser à diviser les données, étant donné qu'il est plus difficile de les saturer en raison de leur latence ultra-faible.
Brad Wilson
En effet, bon point!
Mark S. Rasmussen
1
Je voudrais également souligner qu'il existe également un aspect de récupération / disponibilité des données à cette question. En utilisant plusieurs groupes de fichiers et en ne plaçant aucun objet défini par l'utilisateur sur le groupe de fichiers principal, vous avez plus de flexibilité pour activer les restaurations en ligne. cela permet une restauration fragmentaire au niveau du groupe de fichiers.
La restauration en ligne est disponible dans les éditions Enterprise et Developer de SQL Server après 2005
Une autre pensée qui vient à l'esprit est de séparer les données de référence statiques en lecture seule des données transactionnelles. Pour les bases de données plus volumineuses, cela pourrait réduire le temps et / ou l'espace nécessaires pour effectuer une sauvegarde.
La raison principale est la performance. Lorsque vous manquez de capacité IOPS sur votre lecteur de disque de groupe de fichiers principal, vous devrez vous étendre sur un deuxième groupe de fichiers pour diviser les IOPS sur plusieurs disques / LUN en fonction de la configuration de stockage.
EDIT: Brad Wilson a fait un bon commentaire concernant les SSD. Si vous utilisez un système de stockage composite SSD / SATA / FC, vous souhaiterez peut-être avoir différents groupes de fichiers sur différents types de stockage. Vous pouvez ensuite placer vos tableaux d'exigences IOPS extrêmes sur le groupe de fichiers SSD, tandis que les tableaux d'historique / statistiques peuvent être stockés sur des groupes de fichiers SATA bon marché.
la source
Je voudrais également souligner qu'il existe également un aspect de récupération / disponibilité des données à cette question. En utilisant plusieurs groupes de fichiers et en ne plaçant aucun objet défini par l'utilisateur sur le groupe de fichiers principal, vous avez plus de flexibilité pour activer les restaurations en ligne. cela permet une restauration fragmentaire au niveau du groupe de fichiers.
La restauration en ligne est disponible dans les éditions Enterprise et Developer de SQL Server après 2005
Une autre pensée qui vient à l'esprit est de séparer les données de référence statiques en lecture seule des données transactionnelles. Pour les bases de données plus volumineuses, cela pourrait réduire le temps et / ou l'espace nécessaires pour effectuer une sauvegarde.
la source