Discussion :

[olysmar2]

Bonjour,

Je cherche à réduire la taille d’un fichier .mdf
Pour cela, je vide une table qui est très très grosse et qui ne me sert plus.
Une fois cela fait, mon fichier mdf n’a pas bougé...

Y a t’il une commande pour réduire le fichier mdf ? Comme une défragmentation, par exemple ?

Merci pour vos retours

Sylo

[aieeeuuuuu]

Bonjour,

Oui, c'est la commande SHRINK DATABASE, accessible par SSMS (clic-droit sur la BDD -->tâche-->réduire...)

C'est cependant à éviter en temps normal, cela risque de fortement impacter les perofmances. Avez vous vraiment besoin de récupérer l'espace disque ?

[mikedavem]

Hello,

Je dirais qu'un DBCC SHRINKFILE est plus approprié qu'un DBCC SHRINKDATABASE dans le cas présent si on cherche simplement à réduire la taille du fichier de données après avoir vidé une très grosse table.

En admettant que le journal des transactions ait beaucoup grossi pendant l'opération (DELETE ou lieu de TRUNCATE par exemple), il est vrai que j'ai une préférence pour réduire les fichiers individuellement avec un SHRINKFILE (plutôt que SHRINKDATABASE qui opère sur les 2 types de fichiers) et de redimensionner le journal comme il faut par le suite.

++

[olysmar2]

J’avais essayé cette commande mais cela n’avait rien changé.
Jai du mal faire
Je vais réessayer et je vous tiens au courant...
Merci

[SQLpro]

ATTENTION : on ne peut réduire un fichier que s'il y a quelque chose à supprimer de ce fichier. S'il est plein d'informations, il ne se réduira jamais....

A +

[StringBuilder]

Traduction : si votre LDF est énorme et ne veut pas réduire à coup de SHRINK, c'est peut-être que vous êtes en mode de récupération "complet" et que vous n'avez pas sauvegardé le log !

[elsuket]

Identiquement à Mikedavem, je n'utilise que DBCC SHRINKFILE, et de façon exceptionnelle :

1. Soit après une purge de données comme on l'évoque au début de ce thread, sur le fichier de données
2. Soit après qu'une transaction énorme ait provoqué le gonflement démesuré du fichier du journal des transactions, ou qu'un événement ait empêché la troncature de celui-ci (Réplication, CDC, AlwaysOn, ...), sur le fichier du journal des transactions

Pour les raisons évoquées au 2, il n'est pas tout à fait vrai que, si l'on ne peut pas tronquer le fichier du journal des transactions, c'est parce qu'on ne l'a pas sauvegardé. Il reste encore un cas.
En effet, le fichier du journal des transactions est découpé en Virtual Log Files, et ils sont utilisés tour à tour, de manière cyclique.
Lorsque la base de données est dans le modèle de récupération FULL, lorsqu'un VLF détient les informations de transactions qui n'ont pas encore été sauvegardées, on dit qu'il est actif.
Une fois que ce VLF a été sauvegardé, il est marqué pour réutilisation.

Suppons que notre fichier du journal des transactions est découpé en 16 VLF.
Le VLF 1 est utilisé, puis le 2, puis le 3, et enfin le 4, puis on sauvegarde du fichier du journal des transactions, et, de façon purement circonstancielle, aucune transaction active n'est en cours d'exécution jusque dans les dernières femtosecondes de cette sauvegarde. Alors les VLFs 1 à 4 sont marqués pour réutilisation; la vie de la base de données continue : de nouvelles transactions débutent, sont validées, ... elles sont écrites non pas dans le VLF 1 à nouveau, mais dans le VLF 5. Si on exécute DBCC SHRINKFILE maintenant sur le fichier du journal des transactions, alors il ne peut être réduit que du VLF 16 vers le VLF 6.

Il se peut aussi que nous débutions une transaction alors que le VLF actif est le 16. Comme la transaction est un peu costaud, et que le fichier du journal des transactions n'est pas plein (auquel cas il devrait croître), la suite des enregistrements nécessaires à consignation de la transaction dans le fichier est écrite dans le VLF 1, qui a été marqué pour réutilisation plus tôt. Si nous exécutons DBCC SHRINKFILE sur le fichier du journal des transactions maintenant, alors il ne sera aucunement rétréci.

On peut contrôler l'état des VLFs à l'aide :

• de l'instruction (non documentée) DBCC LOGINFO jusqu'à SQL Server 2016 inclus : la colonne Status indique 2 si le VLF est actif
• de la DMF sys.dm_db_log_info à partir de SQL Server 2017, à l'aide de sa colonne vlf_active

On a alors deux possibilités :

1. Attendre que le seul le VLF 1 soit utilisé, puis prendre une sauvegarde du fichier du journal des transactions, et immédiatement ensuite, rétrécir celui-ci
2. Exécuter une manoeuvre de sagouin : passer la base de données sous le modèle de récupération SIMPLE, réduire le fichier du journal des transactions, puis passer de nouveau sous le modèle FULL.
   Très clairement vous et vous seul êtes l'unique responsable d'une telle manipulation, et vous ne pouvez en aucun cas, et pour quelque raison que ce soit, m'accuser de vous l'avoir recommandée.

Attention : Si on se trouve dans le cas 2, c'est une manoeuvre désespérée, donc à n'utiliser qu'en cas d'extrême urgence (style disque plein et pas de disque supplémentaire à portée du serveur pour créer ajouter un fichier au journal des transactions, quitte à supprimer l'ancien ou le nouveau plus tard), et qui doit impérativement être immédiatement suivie d'une sauvegarde complète de la base de données. Dans le cas contraire, comme la chaîne des sauvegardes du fichier du journal des transactions est interrompue, on ne peut pas restaurer la base de données à un point particulier dans le temps entre le passage sous le modèle de récupération SIMPLE et la fin de la sauvegarde complète sous le mode de récupération FULL. Donc pendant cette sauvegarde, on n'a plus qu'à prier pour qu'un crash ou une manipulation de données non souhaitée (style UPDATE sans clause WHERE sur plusieurs millions de lignes) ne se produise pas .

@++