web-dev-qa-db-fra.com

Récupération de l'espace libre du fichier de données après la suppression d'une grande quantité de données

Je suis un DBA accidentel. Nous avons un cluster sql qui héberge 10 bases de données. Soudain, la taille de l'une des bases de données est passée de 100 Go à 250 Go. Lorsque nous avons vérifié le fichier de données, la taille avait augmenté de plus de deux fois au cours des derniers jours. Nous avons identifié les tables et tronqué les données et supprimé 130 Go de données. Le fichier de données affiche toujours 250 Go. Comment récupérer l'espace?

Merci beaucoup pour toute votre aide.

sql-server-2008-r2
4
Info23

Je vous recommande d'utiliser DBCC SHRINKFILE (). Vous pouvez vérifier l'espace disponible disponible par fichier en utilisant la requête dans la réponse à ce lien Comment déterminer l'espace utilisé/libre dans les fichiers de base de données SQL?

Si vous n'avez qu'un seul fichier de données et un seul fichier journal, ce ne sera probablement que le fichier # 1 et le fichier # 2. Vous devez transmettre le numéro de fichier à la commande SHRINKFILE. Ce n'est pas nécessaire, mais je vous recommande de le faire en petits lots (peut-être 1 ou 10 Go à la fois). Donc, si vous avez un fichier de données de 250 Go mais que les données ne sont que de 100 Go, procédez comme suit

DBCC SHRINKFILE(1, 240000)
GO
DBCC SHRINKFILE(1, 230000)
GO
DBCC SHRINKFILE(1, 220000)
GO
...

Je laisserais une certaine quantité d'espace libre, alors ne descendez pas jusqu'à 100 Go. Laissez peut-être 10 ou 20 Go libres pour les opérations de travail dans le fichier.

Le fichier rétréci ne doit pas se bloquer. Il est généralement suspendu si d'autres opérations fonctionnent sur le fichier de données. Si vous réduisez un gros morceau, le lot peut prendre beaucoup de temps.

Si une partie de l'espace inutilisé provient du fichier journal (fichier n ° 2 généralement), vous pouvez simplement le réduire en une seule fois après sa sauvegarde (si vous êtes en mode de récupération COMPLÈTE). Utilisez DBCC SQLPERF (logspace) pour vérifier l'espace de journal utilisé et le% utilisé. Si le% utilisé est faible, vous pouvez le réduire sans problème. Utilisez simplement DBCC SHRINKFILE (2, 500) pour réduire le journal à un fichier de 500 Mo (choisissez la taille qui vous semble la meilleure pour une utilisation opérationnelle régulière)

5
Alf47

Tout d'abord, êtes-vous sûr que la croissance des données ne se reproduira plus? S'il y a une chance réaliste que cela se produise et que l'espace vide ne vous fasse pas de mal, laissez-le, ne réduisez PAS la base de données.

Cependant, si vous êtes certain que vous souhaitez réduire la taille du fichier de données, vous devez être conscient des pièges de la réduction du fichier de données:

Je me réfère aux conseils de Paul Randal dans son article "Pourquoi vous ne devriez pas réduire vos fichiers de données" (lisez tout l'article pour avoir une idée claire de ce qui se passe avec la fragmentation d'index):

La méthode que j'aime recommander est la suivante:

  • Créer un nouveau groupe de fichiers
  • Déplacez toutes les tables et index affectés dans le nouveau groupe de fichiers à l'aide de la syntaxe CREATE INDEX … WITH (DROP_EXISTING = ON) ON, pour déplacer les tables et en supprimer la fragmentation en même temps
  • Supprimez l'ancien groupe de fichiers que vous alliez réduire de toute façon (ou réduisez-le bien si c'est le groupe de fichiers principal)

Fondamentalement, vous devez fournir un peu plus d'espace avant de pouvoir réduire les anciens fichiers, mais c'est un mécanisme beaucoup plus propre.

Si vous n'avez absolument pas le choix et devez exécuter une opération de réduction du fichier de données, sachez que vous allez provoquer une fragmentation de l'index et vous devez prendre des mesures pour le supprimer par la suite si cela va entraîner des problèmes de performances. La seule façon de supprimer la fragmentation d'index sans provoquer de nouveau la croissance du fichier de données est d'utiliser DBCC INDEXDEFRAG Ou ALTER INDEX … REORGANIZE. Ces commandes ne nécessitent qu'une seule page de 8 Ko d'espace supplémentaire, au lieu d'avoir à créer un tout nouvel index dans le cas d'une opération de reconstruction d'index.

Bottom line - essayez d'éviter à tout prix de réduire le fichier de données!

7
Blaž Dakskobler