Database
 sql >> Base de données >  >> RDS >> Database

Présentation de la commande DBCC SHRINKFILE

L'exécution de commandes DBCC Shrink est un problème assez controversé dans la communauté SQL Server. Dans cet article, nous passerons en revue les détails de cette commande et fournirons un bref aperçu de son utilisation et vous avertirons également des risques liés à l'exécution de cette commande. En tant que DBA, un certain nombre de bases de données ont été transmises à d'autres équipes ou fournisseurs, et ce n'est pas toujours nous qui gérons les bases de données que nous avons créées. En tant que DBA, chaque fois que nous sommes impliqués dans des migrations ou de nouveaux projets, nous devons nous assurer que nous planifions soigneusement une transition en douceur de la base de données vers la production et l'utilisation régulière. C'est à ce stade que nous devons prendre en compte la taille de la base de données. Pouvez-vous imaginer que vous configurez une application de base de données sans tenir compte des prévisions de croissance pour la première année environ. Que diriez-vous de créer une base de données SQL Server avec une taille si petite qu'elle doit s'agrandir tous les deux jours, ce qui déclenche des alertes de capacité de disque au milieu de la nuit ? Cela peut sembler idiot, mais en réalité, la vérité est que cela se produit, et cela peut parfois ne pas être sous votre contrôle.

Quelques points à considérer pour le DBA proactif

Avant de prendre en charge le support des bases de données de production, assurez-vous de vérifier auprès de votre prédécesseur quelles sont les prévisions en termes de croissance des bases de données. La taille initiale des bases de données que vous allez gérer est-elle adéquate ? Ne vous inquiétez pas trop si la taille actuelle de la base de données est bien plus grande que les données dont elle dispose actuellement. N'oubliez pas que vous ne voulez pas ces appels de capacité de disque à 3h00 du matin alors que vous auriez pu l'éviter totalement en ayant une base de données correctement dimensionnée. C'est une tendance générale pour les administrateurs de bases de données à travers l'industrie de sacrifier leur vie tard dans la nuit sur des problèmes banals qui auraient bien dû ne pas se produire en premier lieu. De plus, en plus de la taille de la base de données, gardez à l'esprit la capacité du disque du serveur. Vous ne voulez pas que la taille du disque soit bien trop petite par rapport à ce qu'une base de données peut accueillir. Ce sont toutes des choses simples qui sont utiles au moment de la planification. Cependant, comme vous le savez, ce n'est pas toujours un professionnel des bases de données qui installe ou configure les bases de données en premier lieu. Le point important à noter est d'obtenir les bases correctes avec votre base de données en termes de dimensionnement et vous n'aurez peut-être jamais besoin d'exécuter cette commande. Cependant, comme toujours, en tant que DBA, il y a des moments où les choses peuvent ne pas être sous votre contrôle et pendant ce temps, vous pouvez utiliser les commandes de fichier DBCC Shrink pour une utilisation efficace.

Quand puis-je utiliser DBCC ShrinkFile ?

Vous venez de recevoir une alerte d'espace disque en plein milieu de votre sommeil et vous avez des SLA stricts à respecter. Le niveau de priorité est un P2 et le SLA pourrait être violé très bientôt. Et vous réalisez que l'expansion du disque ne se produira pas de sitôt, eh bien, dans ce cas, gardez vos commandes DBCC ShrinkFile à portée de main afin de pouvoir les utiliser pour récupérer de l'espace. Comme son nom l'indique, il réduit le fichier des données ou le fichier journal de la base de données. Mais avant de commencer à exécuter les commandes DBCC ShrinkFile, essayez de vérifier pourquoi le fichier de base de données augmente en premier lieu.

  • Le fichier a-t-il grossi en raison d'une longue transaction ?
  • Existe-t-il une sorte de blocage sur le serveur ?
  • Existe-t-il une version majeure de l'application dont vous n'avez pas été informé ? (Cela arrive la plupart du temps)
  • Existe-t-il un type de problème de réplication ou de mise en miroir de la base de données entraînant une croissance de la base de données ?

Il est important d'obtenir des réponses à ces questions le plus rapidement possible. Généralement, il y a une réponse à toutes ces questions et c'est un excellent outil gratuit appelé sp_whoisactive. Il n'y a pas de mots pour décrire l'énorme utilisation de cet outil et je l'ai utilisé à plusieurs reprises pour résoudre de nombreux problèmes liés à la production. Vous pouvez télécharger le dernier code à partir de ce lien :http://whoisactive.com/ . Il est facile et simple à utiliser et renvoie la sortie en un rien de temps. Si vous êtes DBA chevronné, vous l'aurez déjà à votre disposition.

DBCC ShrinkFile avec des exemples

La syntaxe de DBCC ShrinkFile est simple et directe, reportez-vous à cet exemple ci-dessous.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

L'exemple ci-dessus réduit FileName appartenant à YOURDATABASE à 1024 Mo. Vous pouvez effectuer la même opération à l'aide de SQL Server Management Studio (SSMS). Cliquez avec le bouton droit sur la base de données, accédez à Tâches , sélectionnez Réduire , puis Fichiers .

Une fois que vous avez cliqué sur Fichiers , vous obtiendrez cette fenêtre.

Ici, vous avez la possibilité de sélectionner le type de fichier :données, journal ou données de flux de fichiers et d'effectuer l'action "Réduire" selon les besoins. Il est plus facile d'utiliser la commande DBCC elle-même à des fins de réduction.

Utilisation de DBCC ShrinkFile avec des options supplémentaires

Vous pouvez exécuter la commande DBCC ShrinkFile avec des options supplémentaires :emptyfile, notruncate ou truncateonly.

Fichier vide

Vous pouvez utiliser la commande emptyfile comme ci-dessous.

use YOURDATABASE
go
dbcc shrinkfile(FileName,emptyfile)

Cela aidera à déplacer les données vers d'autres fichiers au sein du même groupe de fichiers. Une fois cela fait, vous pourrez supprimer un fichier de base de données s'il n'est plus nécessaire. Cependant, il y a peu de choses à noter avec cette option emptyfile car vous ne pourriez pas faire grand-chose pour vider le contenu du fichier de données principal avec l'ID de fichier 1. Afin d'obtenir le numéro d'ID de fichier, exécutez ce script.

select file_id, name,physical_name from sys.database_files

Ici, dans cet exemple, le nom de fichier est "mo" et file_id est 1. Lorsque vous essayez de vider le fichier mo qui a file_id 1, vous rencontrerez ce message d'erreur.

C'est parce qu'il y a des informations système dans le fichier d'origine, qui ne peuvent pas être vidées. Mais, si vous essayez la même commande sur l'autre fichier de données "mo2data", la commande de fichier vide réussira.

Non tronqué

Comme son nom l'indique, il n'y a pas d'espace libéré vers le système d'exploitation. Cela ressemble plus à une opération interne dans le fichier où les pages sont redistribuées dans le fichier lui-même sans modifier la taille globale du fichier de base de données. Pour cette raison, il existe une énorme possibilité d'introduction de fragmentation. Voir l'exemple ci-dessous.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,notruncate);  
GO

Tronquer uniquement

Comme son nom l'indique, l'espace libre sera restitué au système d'exploitation à partir de la fin du fichier. Il s'agit de loin de l'opération la plus sûre que vous puissiez exécuter à l'aide de DBCC ShrinkFile. Voir l'exemple ci-dessous.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,truncateonly);  
GO

Que faire lorsque DBCC ShrinkFile dans le journal des transactions ne fonctionne pas comme prévu ? Reportez-vous à cette méthode sûre pour résoudre le problème

Il arrive que cette commande ne fonctionne pas comme prévu. En supposant que vous ayez une situation où vous essayez de réduire le fichier journal d'une base de données et que cela ne semble pas fonctionner. Vous trouverez ci-dessous quelques-unes des étapes que vous pouvez suivre pour comprendre pourquoi le psy ne fonctionne pas comme prévu. Vous remarquerez que le fichier de réduction s'affichera comme réussi, cependant, il n'y a pas de réduction de la taille du fichier journal. Dans ce cas, exécutez cette commande pour vérifier quelques éléments sur l'utilisation du fichier journal.

select name,log_reuse_wait_desc,* from sys.databases

À partir de la capture d'écran, vous pouvez voir que la colonne log_reuse_wait_desc attend la sauvegarde du journal.

Ici, vous pouvez voir que la sauvegarde du journal de la base de données doit être effectuée avant de pouvoir vraiment réduire le fichier journal. S'il s'agit d'une base de données de production, essayez d'effectuer la sauvegarde du journal sur un autre lecteur où il y a de l'espace disponible. Pour effectuer la sauvegarde du journal, utilisez l'exemple de commande ci-dessous.

backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn'
with init,stats,compression

Après avoir exécuté la commande de sauvegarde, exécutez à nouveau la commande ci-dessous pour voir l'état de la colonne log_reuse_wait_desc.

select name,log_reuse_wait_desc,* from sys.databases

À partir de la capture d'écran, vous pouvez voir que le statut de la colonne log_reuse_wait_desc est passé à "Rien".

Ici, vous pouvez voir que le statut de la colonne « log_reuse_wait_desc » est passé à « Rien ». Dans votre cas, il peut toujours s'afficher sous la forme "LOG_BACKUP". Continuez à effectuer les sauvegardes du journal pour la base de données jusqu'à ce que l'état passe à « Rien ». La raison pour laquelle vous pouvez toujours voir l'état "LOG_BACKUP" même après avoir effectué des sauvegardes du journal des transactions est qu'aucun VLF n'a peut-être été effacé après l'exécution de la sauvegarde du journal des transactions. VLF signifie fichiers journaux virtuels et fait partie de l'architecture interne du journal des transactions. Les fichiers journaux des transactions sont constitués de ces VLF. Vous pouvez obtenir des informations sur les VLF en exécutant cette commande.

select * from sys.dm_db_log_info(5)

Ici, 5 représente le database_id. La capture d'écran de la sortie s'affiche. Le nombre de lignes renvoyées représente le nombre réel de fichiers journaux virtuels (VLF) dans la base de données. Vous pouvez vérifier la colonne "vlf_status" pour vérifier l'état du fichier journal virtuel. La valeur 2 signifie qu'il est actif. Avec cette commande, vous pouvez vérifier les indicateurs internes dans le fichier journal des transactions pour comprendre pourquoi le journal des transactions n'est pas libéré même après avoir effectué des sauvegardes du journal.

Auparavant, la commande utilisée était DBCC LOGINFO qui fournissait des informations similaires.

Que faire lorsque DBCC ShrinkFile dans le journal des transactions ne fonctionne pas comme prévu ? Quelque chose que vous pouvez effectuer dans un environnement non pro. Cependant, non recommandé sur l'environnement de production

Vous auriez rencontré sur plusieurs sites Web des personnes recommandant de changer le modèle de récupération en un modèle simple, puis d'exécuter un fichier de réduction afin de libérer de l'espace pour le système d'exploitation. Gardez à l'esprit que le fait de changer le modèle de récupération en un modèle simple affectera la récupération de votre base de données car vous ne pourrez pas récupérer à un moment précis. Cela dépend encore une fois du SLA de votre entreprise. Vous pouvez modifier le modèle de récupération à l'aide de T-SQL (ci-dessous) ou à l'aide de l'interface graphique.

alter database DB_NAME set recovery simple

À l'aide de l'interface graphique, modifiez le modèle de récupération comme indiqué. Faites un clic droit sur la base de données, allez dans "Propriétés", cliquez sur "Options". Sous "Options", sélectionnez le "Modèle de récupération".

Vous remarquerez que le simple fait de changer le modèle de récupération en Simple ne libérera pas l'espace vers le système d'exploitation. Vous devez exécuter explicitement la commande DBCC ShrinkFile pour réduire le fichier et récupérer l'espace. Voir l'exemple de script ci-dessous. Cette commande réduira votre FileName à 1024 Mo.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

Option de base de données de réduction automatique

Vous remarquerez qu'il existe une option appelée "Auto Shrink" dans les propriétés de la base de données. Faites un clic droit sur la base de données pour afficher la propriété de la base de données. Sous la section des options, vous verrez cette option comme indiqué. À partir du paramètre de base de données de modèles, vous pouvez voir que l'option "Auto Shrink" est désactivée par défaut. Ainsi, chaque fois qu'une nouvelle base de données est créée, cette option est également désactivée. Il peut y avoir des cas où les professionnels des bases de données peuvent, sans le savoir, laisser cette option activée sans être conscients des conséquences négatives de la laisser activée.

Exécutez cette commande pour vérifier l'état de cette option pour les bases de données sur le serveur.

select name,is_auto_shrink_on,* from sys.databases

Vous verrez cette sortie.

Si par hasard, vous voyez qu'il est activé, vous pouvez le désactiver soit en utilisant l'interface graphique, soit en exécutant la commande ci-dessous sur la base de données.

ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF

Autres suggestions d'entretien

Reportez-vous à ces quelques conseils supplémentaires pour éviter le problème de croissance de la base de données, à cause duquel vous devez exécuter les commandes DBCC ShrinkFile.

  • Assurez-vous que le modèle de récupération de vos bases de données est aligné sur les contrats de niveau de service de l'entreprise. Si votre entreprise n'a pas besoin d'une récupération ponctuelle pour les bases de données de test, laissez-les simplement dans un modèle de récupération simple. J'ai vu plusieurs fois où le modèle de récupération des bases de données était complet alors que tout allait bien avec la récupération à l'aide de la dernière sauvegarde complète
  • Assurez-vous qu'une surveillance appropriée est en place, en particulier avec la croissance de la base de données. Vous devriez être alerté lorsque l'utilisation du fichier journal atteint 85 %. Cela vous donnera un peu de temps pour résoudre le problème d'espace
  • Assurez-vous que des sauvegardes de journaux régulières sont effectuées si la base de données est dans le modèle de récupération complète et vous devriez être alerté si l'une des sauvegardes de journaux échoue
  • Assurez-vous qu'il y a suffisamment d'espace sur les lecteurs de base de données afin d'éviter les problèmes de manque d'espace
  • Pour les bases de données qui peuvent être archivées, développez des stratégies d'archivage afin de pouvoir déplacer des données plus anciennes vers une autre base de données pour créer des rapports et rendre cette base de données en lecture seule. Cela vous donnera plus de contrôle en termes de dimensionnement de la base de données
  • Assurez-vous d'effectuer régulièrement des contrôles d'intégrité sur votre base de données à l'aide de DBCC CheckDB. Pour plus d'informations, consultez cet article :https://codingsight.com/dbcc-checkdb-overview/

Conclusion

  • Grâce à cet article, vous avez une bonne compréhension de l'utilisation de la commande DBCC ShrinkFile
  • Vous avez pris connaissance des risques liés à l'exécution des commandes DBCC ShrinkFile
  • Vous avez appris les différentes options que nous pouvons fournir à l'aide des commandes DBCC ShrinkFile
  • Vous avez vu les options que nous pouvons essayer si le journal des transactions ne se réduit pas à l'aide des commandes DBCC ShrinkFile
  • Vous avez découvert le paramètre de réduction automatique par défaut dans la propriété de la base de données
  • Vous avez également appris d'autres suggestions de maintenance de base de données afin de maintenir vos bases de données en bonne santé
  • Enfin, assurez-vous d'être prêt dans tous les cas pour les jours OFF qui peuvent ne pas être sous votre contrôle