web-dev-qa-db-fra.com

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

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 FILE Pour agrandir le fichier, comment puis-je déterminer si SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)?
sql-serversql-server-2008sql-server-2008-r2transaction-logbest-practices
16
Ross Bush

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éduire juste pour repousser 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 quand il se produit), et alerter sur cet événement (vous pouvez l'attraper dans la trace par défaut, par exemple, ou via étendu é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.

24
Aaron Bertrand

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 l'espace que vous estimez pour X durée et définissez votre taille sur 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.

10
Nick Winstanley