Comment réduire la taille d'un fichier journal SQL Server

Je ne peux pas comprendre comment réduire la taille du fichier ldf des bases de données.

Le DBA dit que je devrais utiliser backup log dbname with truncate_only

Et bien que cela semble s'exécuter correctement dans SQL Query Analyzer, le fichier ldf est toujours supérieur à 2 Go.

** Clarification basée sur certains commentaires et certaines réponses ci-dessous. *** La base de données spécifique en question est une base de données sur mon ordinateur portable et je l'utilise uniquement pour les processus de développement. Le fichier journal se développait à un point où il semblait provoquer un disque plein. Il n'y a aucun risque de production impliqué. Je comprends que la méthode dans la question que j'ai posée et la réponse que j'ai acceptée sont risquées dans un environnement de production. *

sql-server log-files shrink

— Ron Tuffin
source

c'est sûrement une question en double?

— JamesRyan

J'ai regardé et n'ai trouvé qu'un seul qui posait une question sur l'échec du SHRINKFILE. À l'époque, cela n'avait pas de sens, alors j'ai posé cette question. J'ai envisagé de supprimer la question, mais j'ai pensé qu'il y en aurait d'autres dans le même bateau. Si vous pouvez trouver une question en double (qui pose en fait la même question, pas une question similaire), je serai heureux de supprimer celle-ci.

— Ron Tuffin du

Il y a environ 8 réponses sur la première page d'une recherche qui l'incluent, mais je suppose que vous devez savoir ce que vous recherchez. Je le vois si régulièrement dans le cadre d'une réponse, j'ai été surpris qu'il n'ait pas été posé de manière aussi simple.

— JamesRyan

La réponse dépend beaucoup de l'option de récupération de la base de données: simple ou complète?

— Richard

Merci d'avoir clarifié, Ron. Comme il s'agit d'une base de données de développement, vous voudrez changer le modèle de récupération en SIMPLE en plus de réduire le fichier journal, sinon votre problème se reproduira.

— BradC

Réponses:

Oh, l'horreur! Veuillez cesser de dire aux gens qu'ils devraient réduire leurs fichiers journaux!

Si vous vous êtes retrouvé dans cette situation, alors l'un des cas suivants est extrêmement probable:

Votre base de données est en mode de récupération complète, et elle devrait vraiment être en mode simple
Votre base de données est en mode de récupération complète et vous devez effectuer des sauvegardes de journal régulières
Votre base de données est en mode de récupération complète et vos sauvegardes de journaux échouent pour une raison quelconque
Vous exécutez des transactions massivement énormes qui font exploser le fichier journal à des tailles massives

La réponse pour chacun d'eux est la suivante:

Si (1), passez la base de données en mode simple
If (2), puis planifiez des sauvegardes de journaux régulières
If (3), puis corrigez vos sauvegardes de journaux planifiées
If (4), alors ne faites pas cela :) Au lieu de cela, faites travailler en lots plus petits.

Notez que AUCUN de ceux-ci ne nécessite l'utilisation du "dbname (obsolète) du journal de sauvegarde avec truncate_only"

Au lieu de cela, une fois que vous avez effacé le fichier journal en utilisant l'une des techniques ci-dessus, réduisez ensuite le journal (maintenant vide) avec:

DBCC SHRINKFILE ('log logical name', 2000)

Spécifiez toujours une taille finale raisonnable, sinon elle diminuera à près de 0, et la prochaine fois qu'elle sera nécessaire, devra prendre le temps de grandir.

— BradC
source

c'est dommage que la réponse acceptée ait été si rapide. C'est l'une des questions que j'utilise pour éliminer les administrateurs SQL lors des entretiens. S'ils reviennent avec une sauvegarde avec truncate_only, cela compte pour 2 frappes.

— Jim B

Je suis d'accord que c'est la dernière chose absolue à faire, réduire le fichier. Une maintenance correcte élimine la nécessité de cela. Mais une fois qu'il est grand et que vous le voulez plus petit, vous devez le rétrécir. Cependant, lors de la réduction, il est préférable de réduire le fichier aussi petit que possible, puis d'agrandir le fichier à la taille correcte par incréments de 8 Go. Cela optimisera le nombre de VLF dans le fichier. Voir - sqlskills.com/BLOGS/KIMBERLY/post/… .

— Brian Knight

Lien intéressant, il semble que cela ne s'applique que si votre journal de trans est supérieur à 8 Go. Je pense que le point de BradC (ou du moins le mien) est que oui, il y a des urgences qui vous amèneront à réduire votre fichier journal, mais vous devez reconnaître que si vous exécutez le tronc de sauvegarde / w notoire, suivi du fichier rétractable, vous venez d'arroser votre chaîne de sauvegarde (espérons que ce n'était pas quelque chose d'important), et à part les problèmes d'espace disque, vous avez probablement de sérieux problèmes de serveur SQL, probablement du point de vue de la conception de la base de données ou de l'architecture. Sans fixer la caue sous-jacente, vous vous êtes au mieux acheté du temps.

— Jim B

après avoir fait la "sauvegarde avec truncate_only", vous devez émettre la commande suivante pour réduire

dbcc SHRINKFILE (logfilename,shrink_tosize)

par exemple

dbcc SHRINKFILE (mydatabase_Log,512)

— Mani
source

Le script que vous avez écrit ci-dessus marquera le contenu du journal pour une réutilisation. Suivez ce script avec:

USE <database>;

DBCC SHRINKFILE (<log logical file name>)

Cela le réduira pour vous.

— Brian Knight
source