Serveur SQL - Meilleures pratiques pour la croissance des fichiers de base de données

16

Je surveille la croissance des fichiers via le collecteur de données dans SQL Server 2008 R2 depuis deux semaines. La base de données croît régulièrement à environ 35 (Mo) / jour. La base de données n'a pas encore atteint la taille initiale de 2 Go.

La croissance automatique des fichiers DB est définie sur 5 Mo et je voudrais essayer une approche différente, donc je recherche des suggestions et / ou des commentaires.

Il y a une tâche de réglage qui s'exécute chaque semaine le dimanche soir à 1h30. La tâche:

  • Vérifier l'intégrité de la base de données
  • Rétrécir le fichier journal - (c'est correct car le mode de journalisation est simple)
  • Réduire la base de données
  • Réorganiser l'index
  • Reconstruire l'index
  • Mettre à jour les statistiques
  • Historique de nettoyage

Je voudrais ajouter deux étapes supplémentaires au plan de réglage hebdomadaire:

  1. Augmentez le fichier de base de données de 500 Mo si l'espace utilisé atteint un certain seuil ou une taille totale.
  2. Augmentez le fichier journal de 250 Mo (après la réduction) si l'espace utilisé atteint un certain seuil de taille totale.

En plaçant le fardeau de la croissance en heures hors ligne, j'espère gagner en performances en réduisant le nombre d'événements de croissance automatique lors de charges lourdes.

J'ai deux questions concernant les fichiers à croissance automatique.

  • Le meilleur endroit pour placer les étapes de croissance du fichier serait avant les étapes actuelles ou après?
  • Si j'utilise le ALTER DATABASE|MODIFY FILEpour agrandir le fichier, comment puis-je déterminer si SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)?
Ross Bush
la source
2
Votre base de données doit avoir une taille suffisante pour ne jamais croître. Néanmoins, assurez-vous que l' initialisation instantanée des fichiers est activée.
Remus Rusanu
3
@Remus est idéal, dites-vous que vous avez parfaitement dimensionné chaque base de données tout au long de votre carrière? Il y aura toujours des devinettes et des ajustements à faire. Je conviendrai que la croissance doit être contrôlée et non pas seulement laissée à le faire 7 fois par jour.
Aaron Bertrand
3
@AaronBertrand: Je privilégie les conseils hyperboles simplistes . Avec le temps, j'ai appris que ça colle mieux. La plupart des utilisateurs ne peuvent pas gérer le "ça dépend" et ceux qui le font peuvent constater par eux-mêmes qu'il y a des nuances de gris entre le noir et le blanc ...
Remus Rusanu
3
@DanAndrews: une surallocation peut avoir des effets «en aval». Imaginez un développeur essayant de restaurer la base de données sur sa machine pour découvrir qu'elle a besoin de deux nouveaux disques de 1 To pour 1 Go de données ...
Remus Rusanu
2
Je ne joue que l'avocat du diable. Cependant, les HD sont bon marché. Le temps perdu en production pour la reconfiguration et la perte de performances sont coûteux.
Dan Andrews

Réponses:

24

Vous devriez viser à croître automatiquement le moins possible. Sept fois par jour est atroce, même avec une initialisation instantanée des fichiers.

Ne faites pas de base de données Shrink. Déjà. Shrinkfile, peut-être, mais seulement après un événement extraordinaire. Le rétrécir juste pour grandir à nouveau est un exercice futile et devrait en fait être appelé auto-fragment.

Si le modèle de récupération est simple, il n'y a aucun moyen sur terre de développer votre fichier journal de 250 Go. L'espace utilisé dans le fichier se nettoiera automatiquement au fil du temps, à moins que vous n'ayez démarré une transaction il y a un mois et que vous n'ayez aucune intention de la valider ou de l'annuler.

Mon conseil serait donc:

Augmentez automatiquement le fichier de données manuellement pendant une période silencieuse à une taille qui pourra accueillir plusieurs mois de croissance. Pour quoi l'économisez-vous en attendant?

Définissez l'incrément de croissance automatique pour le fichier de données sur quelque chose de relativement petit (afin qu'il n'interrompe pas les utilisateurs lorsqu'il se produit), et alertez-le sur cet événement (vous pouvez l'attraper dans la trace par défaut, par exemple, ou via une extension événements). Cela peut vous dire que vous atteignez le point haut que vous avez estimé et qu'il est temps de croître à nouveau manuellement. À ce stade, vous souhaiterez conserver ce manuel au cas où vous souhaiteriez ajouter un nouveau fichier / groupe de fichiers sur un lecteur différent pour accueillir l'espace, car vous finirez par remplir le lecteur actuel.

Faites croître automatiquement le fichier journal pour, disons, le double de son volume. Il ne devrait pas croître davantage à moins qu'il n'y ait une transaction anormale bloquant les choses. Vous devez également surveiller cet événement afin de les connaître.

Aaron Bertrand
la source
Merci pour la contribution ... Je vais utiliser vos conseils pour agrandir le fichier journal et le surveiller pendant un certain temps. J'ai mal utilisé GB pour MB dans la taille de croissance automatique. Je suis d'accord et je ne pense pas que la base de données Shrink fait ce qu'elle était censée faire. À la fin de l'année, la base de données atteint 15 Go, au moment de la création du travail, nous n'avions plus de place pour les sauvegardes.
+1 pour devrait être appelé auto-fragment :-) Avez-vous déjà lancé un problème de connexion pour cela? :-)
marc_s
10

La croissance automatique est quelque chose que vous devriez essayer d'éviter si possible. Le problème est que vous n'avez aucun contrôle sur le moment où la croissance peut se produire et que votre système peut en pâtir sérieusement.

Définissez la taille de votre fichier sur quelque chose de raisonnable pendant un mois environ et surveillez votre taux de croissance à partir de là, déterminez combien d'espace vous estimez pour X quantité de temps et définissez votre taille à cela + une marge d'erreur.

J'ai mis en place un travail de surveillance simple qui m'alerte lorsque la taille du fichier atteint un maximum prédéfini avant la croissance automatique. Vous pouvez utiliser quelque chose comme ceci:

SELECT instance_name,
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
       into ##Logsize
FROM
(
   SELECT *
   FROM sys.dm_os_performance_counters
   WHERE counter_name IN
   (
       'Data File(s) Size (KB)',
       'Log File(s) Size (KB)',
       'Log File(s) Used Size (KB)',
       'Percent Log Used'
   )
     AND instance_name = 'database your interested in' 
) AS Src
PIVOT
(
   MAX(cntr_value)
   FOR counter_name IN
   (
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
   )
) AS pvt 
go
declare @logsize int
Select @logsize = [Percent Log Used] from ##Logsize

If @logsize > the maximum percent you want the log to fill too i.e 90
    BEGIN
        --Do your thing here
    END

Drop table ##Logsize

Cela pourrait bien sûr être programmé comme un travail.

Nick Winstanley
la source
Je supprime la base de données "AND instance_name = 'qui vous intéresse" pour qu'elle renvoie toutes les bases de données. Utilisez ensuite un nombre où la taille du journal est supérieure à un seuil dans l'instruction IF. Si le nombre est supérieur à 1, je fais un sp_send_dbmail avec une instruction select name de la table temporaire pour envoyer par e-mail les noms des journaux au-dessus de la limite.
Nick Winstanley