SQL Server 2005/2008 - plusieurs fichiers / groupes de fichiers - combien? Pourquoi?

Je suis un développeur dans l'âme - mais de temps en temps, un client n'a pas un DBA décent pour faire face à ces problèmes, alors je suis appelé à décider ...

Quelles sont vos stratégies / meilleures pratiques en ce qui concerne le traitement d'une base de données SQL Server de taille raisonnable (quelque chose de plus grand que Northwind ou AdventureWorks; environ 2 à 4 Go de données plus des index, etc.) - utilisez-vous plusieurs fichiers / groupes de fichiers?

Si oui: combien? Et pourquoi?

Quels sont vos critères pour décider quand vous éloigner de l'approche "un groupe de fichiers pour tout":

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

Si vous utilisez plusieurs groupes de fichiers, combien en utilisez-vous? Un pour les données, un pour l'index, un pour le journal? Plusieurs (combien) pour les données? Quelles sont les raisons de votre choix - pourquoi utilisez-vous ce nombre exact de groupes de fichiers :-)

Merci pour tous les conseils, pointeurs, pensées!

À la vôtre, Marc

La règle de base est de séparer les fichiers sur différents volumes pour éviter les conflits, mais le montant du gain de performances que vous obtenez varie énormément selon le sous-système d'E / S et la charge de travail. Par exemple, plusieurs fichiers sur une seule broche physique vont sucer en ce qui concerne les performances, mais le même arrangement avec le volume se trouvant sur un SAN LUN avec plusieurs centaines de disques à partir de matrices RAID 10 peut être très bien. Les compteurs de longueur de file d'attente de disque sont votre ami comme le moyen le plus simple de savoir si vous avez un goulot d'étranglement d'E / S.

Vous regardez les modèles d'E / S dans les bases de données - en lecture seule, en lecture la plupart du temps, en lecture-écriture, en écriture principalement, en écriture seule - et vous basez les choses sur cela. Vous devez également choisir le bon niveau RAID et vous assurer que vos décalages de partition de disque, la taille de la bande RAID et la taille de l'unité d'allocation NTFS sont correctement définis. Certaines personnes aiment séparer les index non clusterisés dans un groupe de fichiers séparé, mais les gains de performances varient ici comme je l'ai expliqué ci-dessus.

En plus des performances, vous devez prendre en compte la gérabilité et la récupérabilité. Avoir un seul fichier de données monolithique pour une base de données de 100 Go signifie que votre unité de restauration est ce fichier. Le diviser en 4 groupes de fichiers de 25 Go signifie que vous pouvez utiliser la disponibilité partielle de la base de données et la restauration fragmentaire pour n'avoir à restaurer qu'un seul groupe de fichiers s'il est endommagé. En partitionnant les tables et les index dans plusieurs groupes de fichiers, vous pouvez également limiter les parties de la base de données qui sont affectées par les opérations de maintenance (par exemple, la suppression de la fragmentation d'index).

Tempdb est un cas spécial, et je vais vous montrer un de mes articles de blog qui explique tout pourquoi et comment diviser tempdb - il y a beaucoup d'idées fausses.

Sans vous donner ici une recommandation de «généralisation radicale», je vais vous montrer un tas de livres blancs et de blogues à lire:

• Livre blanc: Conception de stockage de bases de données physiques
• Livre blanc : Meilleures pratiques d'E / S de pré - déploiement
• Livre blanc: Tables et index partitionnés dans SQL Server 2005

• Livre blanc: Disponibilité partielle de la base de données

• Article de blog: idées fausses sur TF 1118 (disposition tempdb)

• Article de blog: Vos décalages de partition de disque, les tailles de bande RAID et les unités d'allocation NTFS sont-ils correctement définis? (avec lien vers le livre blanc de la partition de disque)

J'espère que cela vous aide!

La décision de diviser une base de données en différents groupes de fichiers doit être prise après avoir analysé la taille actuelle et la croissance future de vos tables. À mon avis, à moins que vous n'ayez une grande base de données ou des tables avec des millions de lignes, vous devriez soigneusement considérer les avantages et les inconvénients, car vous risquez de créer plus de problèmes de performances que vous n'en corrigez.

Il y a quelques scénarios qui pourraient être intéressants sous certaines prémisses:

• 2 groupes de fichiers: données et index
• 3 groupes de fichiers: tables en lecture seule, tables en lecture-écriture, index
• plusieurs groupes de fichiers: lecture seule, lecture-écriture, index, table de clés 1, table de clés 2, ...

Vous devez analyser votre environnement pour décider si les groupes de fichiers vous aideront avec vos besoins de croissance, d'utilisation et de performances SQL Server.

Quelques indicateurs clés pour passer à plusieurs groupes de fichiers (à partir de cet article ):

• Lorsque la mise en file d'attente du disque provoque des problèmes d'application et d'expérience utilisateur
  • Si tel est le cas, envisagez d'utiliser des unités de disque supplémentaires avec de nouveaux groupes de fichiers hébergeant des tables intensives en E / S
• Lorsque des tables particulières représentent 10% ou plus de la base de données
  • Si tel est le cas, envisagez de déplacer ces tables particulièrement volumineuses vers des groupes de fichiers séparés sur des lecteurs de disque sous-jacents distincts
  • En fonction de la taille de la table proportionnellement au reste des tables, envisagez de créer un groupe de fichiers pour chaque table individuelle
• Lorsque l'index non cluster et l'espace de données sont égaux sur de grandes tables
  • Si tel est le cas, envisagez de séparer les données et l'index cluster des index non cluster
• Lorsqu'un pourcentage presque égal de données en lecture seule et en lecture-écriture existe dans la base de données
  • Si tel est le cas, envisagez de fractionner les données en lecture seule dans un groupe de fichiers distinct en tant que données en lecture-écriture
• Quand le temps est insuffisant pour effectuer la maintenance de la base
  • Si tel est le cas, envisagez de diviser les grandes tables en groupes de fichiers distincts sur différents disques sous-jacents et effectuez la maintenance en parallèle
• Quand l'entreprise ou l'application changera considérablement et que les données augmenteront à un rythme beaucoup plus élevé
  • Si tel est le cas, envisagez de travailler avec les utilisateurs pour comprendre la croissance potentielle
• Lorsque les données archivées résident dans la même base de données que les données de production
  • Si tel est le cas, envisagez des groupes de fichiers distincts ou une ou plusieurs des techniques de cette astuce - Archivage des données dans SQL Server

Si vous constatez que les groupes de fichiers pourraient améliorer les performances de votre base de données, écrivez le code et testez le processus dans un environnement intermédiaire avant d'implémenter les modifications sur vos serveurs de production. Préparez quelques mesures avant d'appliquer les modifications et comparez-les avant / après. Étant donné que ces processus peuvent nécessiter beaucoup de ressources et de temps, effectuez ces procédures pendant une période de maintenance.

N'oubliez pas, lors de la création de nouveaux objets (tables et index), assurez-vous que les objets sont créés dans le groupe de fichiers correct pour garantir les performances attendues et valider périodiquement les objets de base de données se trouvent dans les groupes de fichiers corrects et corrigez si nécessaire.