SQL Server: groupe de fichiers pour les tables système uniquement?

11

L'une de nos normes d'entreprise est d'avoir un groupe de fichiers / fichier séparé pour les tables / index utilisateur. Il s'agit de la valeur par défaut, il n'est donc pas nécessaire de qualifier les instructions CREATE TABLE.

Donc ça ressemble à ça

  • fileid 1 = tables système, MDF
  • fileid 2 = t-log = LDF
  • fileid 3 = user stuff = NDF

Quelqu'un ici peut-il m'aider à comprendre la justification originale de la raison pour laquelle cela a été mandaté?

Je reviendrai net et dirai que je pense que c'est du vaudou. Ai- je tort ...?

Edit: je sais comment utiliser les groupes de fichiers pour la séparation des index / partitions / archives, ainsi que comment restaurer au coup par coup. Cette question concerne l'utilisation d'un groupe de fichiers distinct sur le même volume pour les tables système uniquement.

sql-server filegroups disk-structures gbn
la source

Réponses:

9

Le livre de formation 70-432 de Microsoft indique: "La principale raison pour ne placer aucun de vos objets sur le groupe de fichiers principal est de fournir autant d'isolation que possible dans les E / S. Les données dans les objets système ne changent pas aussi fréquemment que les données dans vos objets. En minimisant l'activité d'écriture dans le fichier de données principal, vous réduisez la possibilité d'introduction de corruption due à des pannes matérielles. En outre, étant donné que l'état du groupe de fichiers principal détermine également l'état de la base de données, vous pouvez augmenter la disponibilité de la base de données, je minimise les modifications apportées au groupe de fichiers principal. "

Alors, prenez cela comme vous le feriez. D'autres disent que ce n'est pas nécessaire dans certaines circonstances et bien sûr, c'est plus à maintenir. Je pensais juste fournir le raisonnement de Microsoft.

Jared
la source
Raisonnable, une justification écrite pour cela. J'accepte
gbn
1
Une autre raison est qu'une restauration de base de données PARTIELLE permet la restauration du groupe de fichiers PRIMAIRE ainsi que d'autres groupes de fichiers sélectionnés permettant une récupération plus rapide d'un VLDB correctement conçu. Permettre aux groupes de fichiers archivés / secondaires d'être restaurés ultérieurement.
MartinC
@MartinC: Je connais les restaurations partielles, etc., mais je n'ai jamais compris la logique de séparer explicitement les tables système. Groupes de fichiers pour la performance, l'archivage, la maintenance, le partitionnement, etc. Mais les tables système? Jared a offert la meilleure explication jusqu'à présent ..
gbn
Si la base de données dans son ensemble est très volumineuse, le groupe de fichiers principal pourrait avoir une sauvegarde plus régulière que les données principales. La restauration ne nécessiterait qu'une sauvegarde du journal de queue et une restauration du groupe de fichiers principal et des journaux de transactions depuis la sauvegarde du groupe de fichiers plus la queue. Comme les tables système sont petites, ce serait un processus de récupération plus rapide que de le faire pour l'ensemble de la base de données afin de réduire les temps d'arrêt en cas de problème.
MartinC
12

Ce n'est pas un gain de performances, il y a un gain de récupération à faire. Si une corruption de fichier se produit dans les tables système, la base de données est perdue. Si vous conservez les données utilisateur dans un ou plusieurs groupes de fichiers distincts, vous pouvez restaurer uniquement les fichiers en conservant le reste de la base de données en ligne pendant la restauration (en supposant ici l'édition Enterprise).

Si c'est pourquoi ils le disent, je ne peux pas le dire, mais ce serait un avantage d'avoir plusieurs groupes de fichiers avec uniquement les objets système dans le groupe de fichiers PRIMARY.

Vous devriez cependant lancer dans la jonque pour avoir dit que le rétrécissement automatique devrait être activé.

mrdenny
la source
Pour en savoir plus à ce sujet, vous pouvez rechercher la restauration en ligne fragmentaire dans la documentation en ligne.
Brent Ozar
1
J'ai toujours pensé que c'était aussi du vaudou étant donné que les 2 groupes de fichiers sont sur le même volume (sur un SAN). Le risque de corruption est-il si élevé? (Les DBA opérationnels réels définissent AutoShrink sur faux)
gbn
Il y a de fortes chances que s'il y a corruption, il y aura une seule page dans un seul fichier, car le stockage sera houblonné lors de l'écriture de la page sur le disque. Quelque chose comme 99,9999% de la corruption de la base de données est un problème de stockage. La moitié du reste des problèmes est une mauvaise mémoire, les autres sont des bogues SQL. À mesure que les bases de données s'agrandissent (multi-TB), cela devient plus important, car la restauration d'une base de données multi-TB prendra plusieurs jours.
mrdenny
Ne serais-je pas en droit de penser que si les objets système se trouvent uniquement dans le groupe de fichiers principal si vous en avez besoin à l'avenir, vous pourrez effectuer les opérations suivantes. Créez x fichiers supplémentaires dans un autre groupe de fichiers. Remplissez ces fichiers proportionnellement en migrant vos données depuis votre fichier de données existant?
Ally Reilly
4

Je ne suis pas sûr de comprendre, demandez-vous quelqu'un pour justifier votre norme d'entreprise? Je pense que celui qui a écrit ce document sur les normes pour votre entreprise pourrait faire la lumière sur les raisons pour lesquelles cela serait fait.

Cela étant dit, il n'est pas rare que certains magasins veuillent séparer les données système des données utilisateur. Et s'il est utilisé en conjonction avec des ensembles de disques dédiés, vous pouvez obtenir des gains de performances.

SQLRockstar
la source
Merci. Pas le justifier, mais l'expliquer. Il s'agit de la même équipe DB Engineering qui a déclaré AutoShrink. Étant donné que les tables système occupent quelques Mo et seront de toute façon en mémoire, croyez-vous à un gain de performances?
gbn