Comment effacer le journal des transactions SQL Server?


577

Je ne suis pas un expert SQL, et je me souviens du fait chaque fois que je dois faire quelque chose au-delà des bases. J'ai une base de données de test qui n'est pas de grande taille, mais le journal des transactions l'est certainement. Comment effacer le journal des transactions?



3
Il devrait y avoir une commande dans Managment Studio: "Cliquez pour réduire le journal" et vous avez terminé.
frenchie

Réponses:


750

La réduction de la taille d'un fichier journal doit vraiment être réservée aux scénarios où il a rencontré une croissance inattendue qui ne devrait pas se reproduire. Si le fichier journal atteint à nouveau la même taille, il n'y a pas grand-chose à faire en le réduisant temporairement. Maintenant, selon les objectifs de récupération de votre base de données, ce sont les actions que vous devez entreprendre.

Tout d'abord, effectuez une sauvegarde complète

Ne modifiez jamais votre base de données sans vous assurer de pouvoir la restaurer en cas de problème.

Si vous vous souciez de la récupération ponctuelle

(Et par récupération ponctuelle, je veux dire que vous vous souciez de pouvoir restaurer sur autre chose qu'une sauvegarde complète ou différentielle.)

Vraisemblablement, votre base de données est en FULLmode de récupération. Sinon, assurez-vous que c'est:

ALTER DATABASE testdb SET RECOVERY FULL;

Même si vous effectuez des sauvegardes complètes régulières, le fichier journal augmentera et augmentera jusqu'à ce que vous effectuiez une sauvegarde de journal - c'est pour votre protection, pour ne pas ronger inutilement votre espace disque. Vous devez effectuer ces sauvegardes de journaux assez fréquemment, selon vos objectifs de récupération. Par exemple, si vous avez une règle d'entreprise qui stipule que vous pouvez vous permettre de ne pas perdre plus de 15 minutes de données en cas de sinistre, vous devez avoir un travail qui sauvegarde le journal toutes les 15 minutes. Voici un script qui générera des noms de fichiers horodatés en fonction de l'heure actuelle (mais vous pouvez également le faire avec des plans de maintenance, etc., ne choisissez pas l'une des options de réduction dans les plans de maintenance, elles sont horribles).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Notez que cela \\backup_share\devrait être sur une machine différente qui représente un périphérique de stockage sous-jacent différent. Les sauvegarder sur la même machine (ou sur une machine différente qui utilise les mêmes disques sous-jacents ou une machine virtuelle différente qui se trouve sur le même hôte physique) ne vous aide pas vraiment, car si la machine explose, vous avez perdu votre base de données et ses sauvegardes. Selon votre infrastructure réseau, il peut être plus judicieux de sauvegarder localement, puis de les transférer vers un autre emplacement en arrière-plan; dans les deux cas, vous souhaitez les retirer de la machine de base de données principale le plus rapidement possible.

Maintenant, une fois que vous avez des sauvegardes de journaux régulières en cours d'exécution, il devrait être raisonnable de réduire le fichier journal à quelque chose de plus raisonnable que ce qu'il a explosé jusqu'à présent. Cela ne signifie pas d' exécuter SHRINKFILEindéfiniment jusqu'à ce que le fichier journal soit de 1 Mo. Même si vous sauvegardez fréquemment le journal, il doit toujours prendre en compte la somme des transactions simultanées qui peuvent se produire. Les événements de croissance automatique des fichiers journaux sont coûteux, car SQL Server doit mettre à zéro les fichiers (contrairement aux fichiers de données lorsque l'initialisation instantanée des fichiers est activée), et les transactions utilisateur doivent attendre pendant que cela se produit. Vous voulez faire cette routine de croissance-rétrécissement-croissance-rétrécissement le moins possible, et vous ne voulez certainement pas faire payer vos utilisateurs.

Notez que vous devrez peut-être sauvegarder le journal deux fois avant qu'une réduction ne soit possible (merci Robert).

Donc, vous devez trouver une taille pratique pour votre fichier journal. Personne ici ne peut vous dire ce que c'est sans en savoir beaucoup plus sur votre système, mais si vous avez fréquemment réduit le fichier journal et qu'il a de nouveau augmenté, un bon filigrane est probablement 10 à 50% plus élevé que le plus gros qu'il ait été. . Supposons que cela représente 200 Mo et que vous souhaitiez que les événements de croissance automatique ultérieurs soient de 50 Mo, vous pouvez ajuster la taille du fichier journal de cette façon:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Notez que si le fichier journal est actuellement> 200 Mo, vous devrez peut-être exécuter ceci en premier:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Si vous ne vous souciez pas de la récupération ponctuelle

S'il s'agit d'une base de données de test et que vous ne vous souciez pas de la récupération ponctuelle, vous devez vous assurer que votre base de données est en SIMPLEmode de récupération.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Le fait de mettre la base de données en SIMPLEmode de récupération garantit que SQL Server réutilise des parties du fichier journal (essentiellement en supprimant progressivement les transactions inactives) au lieu de croître pour conserver un enregistrement de toutes les transactions (comme la FULLrécupération le fait jusqu'à ce que vous sauvegardiez le journal). CHECKPOINTLes événements aideront à contrôler le journal et à s'assurer qu'il n'a pas besoin de croître, sauf si vous générez beaucoup d'activité de journal entre les CHECKPOINTs.

Ensuite, vous devez vous assurer que cette croissance du journal est vraiment due à un événement anormal (par exemple, un nettoyage de printemps annuel ou la reconstruction de vos plus gros indices), et non à une utilisation quotidienne normale. Si vous réduisez le fichier journal à une taille ridiculement petite et que SQL Server n'a qu'à le développer à nouveau pour s'adapter à votre activité normale, qu'avez-vous gagné? Avez-vous pu utiliser l'espace disque que vous avez libéré temporairement? Si vous avez besoin d'un correctif immédiat, vous pouvez exécuter ce qui suit:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

Sinon, définissez une taille et un taux de croissance appropriés. Comme dans l'exemple du cas de récupération ponctuelle, vous pouvez utiliser le même code et la même logique pour déterminer la taille de fichier appropriée et définir des paramètres de croissance automatique raisonnables.

Certaines choses que vous ne voulez pas faire

  • Sauvegardez le journal avec l' TRUNCATE_ONLYoption, puisSHRINKFILE . D'une part, cette TRUNCATE_ONLYoption est obsolète et n'est plus disponible dans les versions actuelles de SQL Server. Deuxièmement, si vous êtes dans le FULLmodèle de récupération, cela détruira votre chaîne de journaux et nécessitera une nouvelle sauvegarde complète.

  • Détachez la base de données, supprimez le fichier journal et rattachez-le . Je ne peux pas souligner à quel point cela peut être dangereux. Votre base de données peut ne pas remonter, elle peut apparaître comme suspecte, vous devrez peut-être revenir à une sauvegarde (si vous en avez une), etc. etc.

  • Utilisez l'option "réduire la base de données" . DBCC SHRINKDATABASEet l'option du plan de maintenance pour faire de même sont de mauvaises idées, surtout si vous n'avez vraiment besoin que de résoudre un problème de journal. Ciblez le fichier que vous souhaitez ajuster et ajustez-le indépendamment, en utilisant DBCC SHRINKFILEou ALTER DATABASE ... MODIFY FILE(exemples ci-dessus).

  • Réduction de la taille du fichier journal 1 Mo . Cela semble tentant car, hé, SQL Server me laisse le faire dans certains scénarios, et regarde tout l'espace qu'il libère! À moins que votre base de données ne soit en lecture seule (et c'est le cas, vous devez la marquer comme telle en utilisant ALTER DATABASE), cela entraînera absolument de nombreux événements de croissance inutiles, car le journal doit prendre en charge les transactions actuelles quel que soit le modèle de récupération. Quel est l'intérêt de libérer temporairement cet espace, juste pour que SQL Server puisse le récupérer lentement et douloureusement?

  • Créez un deuxième fichier journal . Cela soulagera temporairement le lecteur qui a rempli votre disque, mais cela revient à essayer de réparer un poumon perforé avec un pansement. Vous devez traiter le fichier journal problématique directement au lieu d'ajouter simplement un autre problème potentiel. Outre la redirection d'une activité du journal des transactions vers un autre lecteur, un deuxième fichier journal ne fait vraiment rien pour vous (contrairement à un deuxième fichier de données), car un seul des fichiers peut être utilisé à la fois. Paul Randal explique également pourquoi plusieurs fichiers journaux peuvent vous mordre plus tard .

Etre pro-actif

Au lieu de réduire votre fichier journal à une petite quantité et de le laisser constamment se développer automatiquement à un petit taux, définissez-le sur une taille raisonnablement grande (qui acceptera la somme de votre plus grand ensemble de transactions simultanées) et définissez une croissance automatique raisonnable en tant que solution de repli, de sorte qu'il ne doive pas croître plusieurs fois pour satisfaire des transactions uniques et qu'il soit relativement rare qu'il doive jamais croître pendant les opérations commerciales normales.

Les pires paramètres possibles sont une croissance de 1 Mo ou une croissance de 10%. Assez drôle, ce sont les valeurs par défaut pour SQL Server (dont je me suis plaint et que j'ai demandé des modifications en vain ) - 1 Mo pour les fichiers de données et 10% pour les fichiers journaux. Le premier est beaucoup trop petit de nos jours et le second conduit à des événements de plus en plus longs à chaque fois (par exemple, votre fichier journal est de 500 Mo, la première croissance est de 50 Mo, la prochaine croissance est de 55 Mo, la prochaine croissance est de 60,5 Mo , etc. etc. - et sur les E / S lentes, croyez-moi, vous remarquerez vraiment cette courbe).

Lectures complémentaires

S'il vous plaît ne vous arrêtez pas ici; Bien que la plupart des conseils que vous voyez sur la réduction des fichiers journaux soient intrinsèquement mauvais et même potentiellement désastreux, certaines personnes se soucient davantage de l'intégrité des données que de la libération d'espace disque.

Un article de blog que j'ai écrit en 2009, quand j'ai vu quelques articles "voici comment réduire le fichier journal" .

Un article de blog écrit par Brent Ozar il y a quatre ans, pointant vers plusieurs ressources, en réponse à un article de SQL Server Magazine qui n'aurait pas dû être publié .

Un article de blog de Paul Randal expliquant pourquoi la maintenance des journaux est importante et pourquoi vous ne devriez pas non plus réduire vos fichiers de données .

Mike Walsh a une excellente réponse couvrant également certains de ces aspects, y compris les raisons pour lesquelles vous ne pourrez peut-être pas réduire immédiatement votre fichier journal .


5
La récupération ponctuelle n'est pas la seule raison d'utiliser le modèle de récupération complète. La raison principale est d'empêcher la perte de données. Votre potentiel de perte de données est la longueur entre les sauvegardes. Si vous ne faites qu'une sauvegarde quotidienne, votre risque de perte de données est de 24 heures. Si vous ajoutez ensuite des sauvegardes de journal toutes les demi-heures, votre risque de perte de données devient 30 minutes. De plus, des sauvegardes de journaux sont nécessaires pour effectuer toute sorte de restauration fragmentaire (comme pour récupérer d'une corruption).
Robert L Davis

9
Cela mis à part, c'est la réponse la plus complète et correcte donnée sur cette page.
Robert L Davis

11
Je voudrais également ajouter que l'effacement du journal se fait en sauvegardant le journal (en récupération complète ou en bloc) ou un point de contrôle (en récupération simple). Cependant, si vous êtes dans une situation où vous devez réduire le fichier journal, cela ne suffit pas. Vous devez obliger le VLF actuellement actif à revenir au début du fichier journal. Vous pouvez forcer cela dans SQL 2008 et versions ultérieures en émettant deux sauvegardes de journal ou points de contrôle consécutifs. Le premier l'efface et le second le ramène au début du fichier.
Robert L Davis

2
@Doug_Ivison car à tout moment, les enregistrements du journal peuvent être purgés. À quoi servirait de vous permettre de sauvegarder un journal incomplet? Dans une récupération simple, le journal n'est vraiment utilisé que pour permettre des annulations de transactions. Une fois qu'une transaction a été validée ou annulée, la seconde suivante, elle peut être supprimée du journal.
Aaron Bertrand

3
@zinczinc Ok, merci pour vos commentaires. Le problème que je vois avec mettre la réponse en premier et l'explication plus tard est qu'ils ne liront jamais les parties importantes. La conférence avec laquelle je noie le lecteur est en réalité beaucoup plus importante que la réponse à la fin, et à mon humble avis, le contexte que je fournis est assez important pour faire ces choix. Mais bon, si vous voulez soumettre une réponse sur une seule ligne parce que vous pensez que c'est mieux pour le PO, n'hésitez pas à utiliser cette partie de ma réponse pour en faire une meilleure dont nous pouvons tous apprendre.
Aaron Bertrand

200
-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

De: DBCC SHRINKFILE (Transact-SQL)

Vous voudrez peut-être d'abord sauvegarder.


merci Maimonides, c'est de la documentation, donc je dirais que c'est le meilleur: P surtout parce que ça n'a pas été inventé par moi :)
Rui Lima

1
après cela, ma taille de journal n'a pas changé un peu. est-ce que j'ai fait quelque chose de mal?
chester89

1
Cette approche définit le type de récupération sur "PLEIN", même si le type de récupération était autre chose auparavant
Vil

1
Fonctionné comme par magie! Notez que le nom du fichier journal est en fait son nom logique (qui peut être trouvé dans db-> propriétés-> fichiers)
Bizhan

2
J'inclurais une clause BACKUP DATABASE dans ce script, donc personne n'oublie cette partie. Je dis cela, car il y a quelques années, j'ai réduit une base de données sur un disque où il y a trop peu d'espace libre. Dans le processus de réduction, les fichiers devenaient plus gros et une erreur Out of Space a été levée. Résultat: j'ai perdu la base de données. Heureusement, c'était une base de données de journaux qui avait perdu sa tolérance.
Cesar

185

AVERTISSEMENT: Veuillez lire attentivement les commentaires ci-dessous, et je suppose que vous avez déjà lu la réponse acceptée. Comme je l'ai dit il y a près de 5 ans:

si quelqu'un a des commentaires à ajouter pour des situations où ce n'est PAS une solution adéquate ou optimale, veuillez commenter ci-dessous


  • Faites un clic droit sur le nom de la base de données.

  • Sélectionnez Tâches → Rétrécir → Base de données

  • Cliquez ensuite OK!

J'ouvre généralement le répertoire de l'Explorateur Windows contenant les fichiers de base de données, afin que je puisse immédiatement voir l'effet.

J'étais en fait assez surpris que cela fonctionne! Normalement, j'ai utilisé DBCC auparavant, mais je l'ai juste essayé et cela n'a rien rétréci, j'ai donc essayé l'interface graphique (2005) et cela a très bien fonctionné - libérant 17 Go en 10 secondes

En mode de récupération complète, cela peut ne pas fonctionner, vous devez donc d'abord sauvegarder le journal ou passer à la récupération simple, puis réduire le fichier. [merci @onupdatecascade pour cela]

-

PS: J'apprécie ce que certains ont commenté concernant les dangers de cela, mais dans mon environnement, je n'ai eu aucun problème à le faire moi-même, d'autant plus que je fais toujours une sauvegarde complète en premier. Veuillez donc prendre en considération ce qu'est votre environnement et comment cela affecte votre stratégie de sauvegarde et la sécurité de l'emploi avant de continuer. Je ne faisais que diriger les gens vers une fonctionnalité fournie par Microsoft!


50
En mode de récupération complète, cela peut ne pas fonctionner, vous devez donc d'abord sauvegarder le journal ou passer à la récupération simple, puis réduire le fichier.
onupdatecascade

7
@onupdatecascade - bon appel sur une astuce de récupération complète. avait une autre base de données avec un énorme journal: passé à simple, puis réduire la base de données et repasser à plein. fichier journal jusqu'à 500 Ko!
Simon_Weaver

26
Désolé. Mais cette réponse ne pouvait tout simplement PAS être plus fausse. En réduisant la base de données, vous augmenterez le fichier journal des transactions. À chaque fois que vous déplacez des données dans une base de données SQL Server, vous aurez besoin d'une journalisation - gonfler le fichier journal. Pour réduire la taille du journal, définissez la base de données sur Simple Recovery OU (si vous vous souciez / avez besoin de données enregistrées - et vous le faites presque toujours en production), sauvegardez le journal. Plus de détails dans ces vidéos simples et gratuites: sqlservervideos.com/video/logging-essentials sqlservervideos.com/video/sql2528-log-files
Michael K. Campbell

30
Wow, bravo pour avoir 1300+ rep pour cette réponse, mais c'est vraiment un conseil terrible.
Aaron Bertrand

8
Voici une exagération pour montrer ce qui se passe et pourquoi le rétrécissement est absolument critique sur une base périodique: L'enregistrement A est modifié 1 million de fois avant qu'une sauvegarde ne soit effectuée. Qu'y a-t-il dans le journal? 999 999 éléments de données non pertinents. Si les journaux ne sont jamais réduits, vous ne saurez jamais quelles sont les véritables dépenses d'exploitation de la base de données. En outre, vous monopolisez probablement des ressources précieuses sur un SAN. Le rétrécissement est un bon entretien et vous permet de rester en contact avec votre environnement. Montrez-moi quelqu'un qui pense que vous ne devriez jamais rétrécir et je vous montrerai quelqu'un ignorant son environnement.
Newclique

54

Vous trouverez ci-dessous un script pour réduire le journal des transactions, mais je recommanderais certainement de sauvegarder le journal des transactions avant de le réduire.

Si vous réduisez simplement le fichier, vous allez perdre une tonne de données qui peuvent vous sauver la vie en cas de catastrophe. Le journal des transactions contient de nombreuses données utiles qui peuvent être lues à l'aide d'un lecteur de journal des transactions tiers (il peut être lu manuellement mais avec un effort extrême cependant).

Le journal des transactions est également un must lorsqu'il s'agit de récupération ponctuelle, alors ne le jetez pas simplement, mais assurez-vous de le sauvegarder au préalable.

Voici plusieurs articles où les gens ont utilisé des données stockées dans le journal des transactions pour effectuer la récupération:

 

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

Vous pouvez obtenir une erreur qui ressemble à ceci lorsque les commandes d'exécution ci-dessus

"Impossible de réduire le fichier journal (nom du fichier journal) car le fichier journal logique situé à la fin du fichier est en cours d'utilisation"

Cela signifie que TLOG est en cours d'utilisation. Dans ce cas, essayez de l'exécuter plusieurs fois de suite ou trouvez un moyen de réduire les activités de la base de données.


30

Voici une manière simple et très inélégante et potentiellement dangereuse .

  1. DB de sauvegarde
  2. Détacher la base de données
  3. Renommer le fichier journal
  4. Attacher DB
  5. Un nouveau fichier journal sera recréé
  6. Supprimer le fichier journal renommé.

Je suppose que vous ne faites pas de sauvegardes de journaux. (Qui tronque le journal). Mon conseil est de changer le modèle de récupération de complet à simple . Cela empêchera le ballonnement des journaux.


15
Respectueusement, supprimer / renommer / recréer / remplacer le journal est une très mauvaise idée. Le rétrécissement est moins risqué, et c'est assez simple à faire.
onupdatecascade

12
+1 - Inélégant ou non, cette méthode m'a fait sortir de l'eau chaude plusieurs fois avec des journaux de base de données qui ont rempli tout le disque, de sorte que même une commande de réduction ne peut pas s'exécuter.
Shaul Behr

3
N'y a-t-il pas un risque de transactions non vérifiées existant dans le journal?
Paul

Cela peut également convenir aux petites bases de données, mais si vous avez une base de données de 3 ou 4 To, ce n'est peut-être pas la meilleure solution.
Jaques

Cela semble correct si vous développez un système depuis longtemps et que vous chargez / supprimez des milliers d'enregistrements pendant la période de développement. Ensuite, lorsque vous souhaitez utiliser cette base de données pour déployer en direct, les données de test / développement qui ont été enregistrées sont redondantes et n'ont donc pas d'importance si elles sont perdues, non?
JsonStatham

28

Si vous n'utilisez pas les journaux de transactions pour les restaurations (c'est-à-dire que vous ne faites que des sauvegardes complètes), vous pouvez définir le mode de récupération sur "Simple", et le journal de transactions rétrécira très rapidement et ne se remplira plus jamais.

Si vous utilisez SQL 7 ou 2000, vous pouvez activer "tronquer le journal au point de contrôle" dans l'onglet des options de la base de données. Cela a le même effet.

Cela n'est évidemment pas recommandé dans les environnements de production, car vous ne pourrez pas restaurer à un moment donné.


1
Définir le mode de récupération sur simple ne réduira pas à lui seul le journal des transactions.
Aaron Bertrand

@Aaron Pas tout seul, non. J'ai supposé que l'OP utiliserait leur base de données de test, et donc "le journal des transactions rétrécira très prochainement", mais vous avez raison en ce sens qu'il s'agit plus d'un effet secondaire: le mode de récupération simple vous fera probablement vous retrouver avec un rétréci journal des transactions bientôt
Jonathan

" Simple... et ne refaites jamais le plein" - ce n'est pas vrai. Je l'ai vu se produire (au cours des dernières 48 heures) sur une base de données où le modèle de récupération était réglé sur "SIMPLE". La croissance du fichier du fichier journal était réglée sur "restreinte", et nous avions fait une immense activité dessus ... Je comprends que c'était une situation inhabituelle. (Dans notre situation, où nous avions beaucoup d'espace disque, nous avons augmenté la taille du fichier journal et défini la croissance du fichier journal sur "non restreint" ... qui, soit dit en passant - bug d'interface - apparaît, après le changement, comme "restreint" "avec une taille maximale de 2 097 152 Mo.)
Doug_Ivison

2
@Doug_Ivison Oui, le journal des transactions contiendra des transactions ouvertes, mais elles seront supprimées en mode simple une fois qu'un point de contrôle aura eu lieu. Cette réponse est uniquement destinée à un rapide "ma boîte de développement / test a un gros journal des transactions, et je veux qu'il disparaisse donc je n'ai pas besoin de m'en soucier trop souvent", plutôt que jamais destiné à entrer dans une production environnement. Pour réitérer: Ne faites pas cela en production .
Jonathan

1
C'est vrai, et je comprends que c'était une approche rapide uniquement pour le développement. Pourquoi j'ai commenté: jusqu'à ce que cela m'arrive, je pensais en fait que le modèle de récupération simple ne pourrait JAMAIS se remplir ... et je pense qu'il m'a fallu plus de temps pour comprendre / résoudre, alors que j'ai compris que des transactions inhabituellement importantes pouvaient le faire.
Doug_Ivison

9

Cette technique que John recommande n'est pas recommandée car il n'y a aucune garantie que la base de données se joindra sans le fichier journal. Changez la base de données de complète à simple, forcez un point de contrôle et attendez quelques minutes. SQL Server effacera le journal, que vous pourrez ensuite réduire à l'aide de DBCC SHRINKFILE.


... mais je l'ai fait des dizaines de fois sans problème. vous pourriez peut-être expliquer pourquoi la base de données peut ne pas se reconnecter.
Johnno Nolan

J'ai parfois (pas très souvent) vu que SQL Server ne pouvait pas rattacher la base de données à la base de données lorsque le fichier journal a été supprimé. Cela vous laisse un fichier MDF inutile. Il existe plusieurs possibilités qui peuvent provoquer le problème. Les transactions en attente de restauration me viennent à l'esprit.
mrdenny

4
Je suis d'accord avec cette tactique, mais elle devrait être réservée aux cas où le journal a explosé en raison d'un événement imprévu et / ou extraordinaire. Si vous établissez un travail pour le faire chaque semaine, vous le faites très, très mal.
Aaron Bertrand

2
Très, très vrai Aaron.
mrdenny

Oui, cela vient de nous arriver. Nous voulions abandonner 20G de fichier journal car nous venions de sauvegarder les données avant de déplacer la base de données. MSSQL ne nous permettrait pas de rattacher la nouvelle base de données sans le gigantesque fichier journal.
George M Réinstalle Monica le

9

Jusqu'à présent, la plupart des réponses supposent que vous n'avez pas réellement besoin du fichier journal des transactions, mais si votre base de données utilise le FULLmodèle de récupération et que vous souhaitez conserver vos sauvegardes au cas où vous auriez besoin de restaurer la base de données, ne tronquez pas ou ne supprimez pas le fichier journal comme le suggèrent bon nombre de ces réponses.

L'élimination du fichier journal (en le tronquant, en le supprimant, en l'effaçant, etc.) interrompra votre chaîne de sauvegarde et vous empêchera de restaurer à tout moment depuis votre dernière sauvegarde complète, différentielle ou de journal des transactions, jusqu'à la prochaine sauvegarde complète. ou une sauvegarde différentielle est effectuée.

De l' article de Microsoft surBACKUP

Nous vous recommandons de ne jamais utiliser NO_LOG ou TRUNCATE_ONLY pour tronquer manuellement le journal des transactions, car cela rompt la chaîne du journal. Jusqu'à la prochaine sauvegarde complète ou différentielle de la base de données, la base de données n'est pas protégée contre les pannes de média. N'utilisez la troncature manuelle des journaux que dans des circonstances très particulières et créez immédiatement des sauvegardes des données.

Pour éviter cela, sauvegardez votre fichier journal sur le disque avant de le réduire. La syntaxe ressemblerait à ceci:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

3
Je suis d'accord avec votre réponse, sauf pour la , 1)partie. Le problème est que si vous le réduisez à 1 Mo, les événements de croissance conduisant à une taille de journal normale seront assez coûteux, et ils seront nombreux si le taux de croissance est laissé à la valeur par défaut de 10%.
Aaron Bertrand

9

Le journal des transactions SQL Server doit être correctement entretenu afin d'empêcher sa croissance indésirable. Cela signifie que les sauvegardes du journal des transactions sont exécutées suffisamment souvent. En ne faisant pas cela, vous risquez que le journal des transactions soit plein et commence à croître.

Outre les réponses à cette question, je recommande de lire et de comprendre les mythes courants du journal des transactions. Ces lectures peuvent aider à comprendre le journal des transactions et à décider des techniques à utiliser pour le "vider":

Des 10 mythes les plus importants du journal des transactions SQL Server :

Mythe: Mon SQL Server est trop occupé. Je ne souhaite pas effectuer de sauvegardes du journal des transactions SQL Server

L'une des opérations les plus gourmandes en performances de SQL Server est un événement de croissance automatique du fichier journal des transactions en ligne. En ne réalisant pas assez souvent les sauvegardes du journal des transactions, le journal des transactions en ligne sera plein et devra se développer. La taille de croissance par défaut est de 10%. Plus la base de données est occupée, plus le journal des transactions en ligne augmentera rapidement si les sauvegardes du journal des transactions ne sont pas créées. La création d'une sauvegarde du journal des transactions SQL Server ne bloque pas le journal des transactions en ligne, mais un événement de croissance automatique le fait. Il peut bloquer toute activité dans le journal des transactions en ligne

Des mythes du journal des transactions :

Mythe: La réduction régulière du journal est une bonne pratique de maintenance

FAUX. La croissance des grumes est très coûteuse car le nouveau morceau doit être mis à zéro. Toute activité d'écriture s'arrête sur cette base de données jusqu'à la fin de la mise à zéro, et si l'écriture sur votre disque est lente ou que la taille de la croissance automatique est grande, cette pause peut être énorme et les utilisateurs le remarqueront. C'est une des raisons pour lesquelles vous voulez éviter la croissance. Si vous réduisez le journal, il augmentera à nouveau et vous gaspillerez simplement l'opération du disque sur un jeu inutile de rétrécissement et de croissance.


5

Vérifiez d'abord le modèle de récupération de la base de données. Par défaut, SQL Server Express Edition crée une base de données pour le modèle de récupération simple (si je ne me trompe pas).

Journal de sauvegarde DatabaseName avec Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile vous donnera le nom du fichier journal logique.

Faire référence à:

Récupérer à partir d'un journal de transactions complet dans une base de données SQL Server

Si votre base de données est dans le modèle de récupération complète et si vous ne prenez pas de sauvegarde TL, changez-la en SIMPLE.


C'est ainsi que j'efface les fichiers journaux de mes boîtes de développement. Environnements de production avec toutes les stratégies de sauvegarde associées, etc. Je laisse aux DBA :-)
Joon

TRUNCATE_ONLYn'est plus une option dans les versions actuelles de SQL Server et n'est pas recommandé sur les versions qui le prennent en charge (voir la réponse de Rachel ).
Aaron Bertrand

5

Utilisez la DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)commande. S'il s'agit d'une base de données de test et que vous essayez d'économiser / récupérer de l'espace, cela vous aidera.

Rappelez-vous cependant que les journaux TX ont une sorte de taille minimale / stable qu'ils atteindront. En fonction de votre modèle de récupération, vous ne pourrez peut-être pas réduire le journal - s'il est COMPLET et que vous n'émettez pas de sauvegardes de journal TX, le journal ne peut pas être réduit - il augmentera pour toujours. Si vous n'avez pas besoin de sauvegardes de journaux TX, basculez votre modèle de récupération sur Simple .

Et rappelez-vous, jamais jamais en aucun cas supprimer le fichier journal (LDF)! Vous aurez à peu près une corruption de base de données instantanée. Cuit! Terminé! Des données perdues! S'il n'est pas réparé, le fichier MDF principal peut être corrompu de façon permanente.

Ne supprimez jamais le journal des transactions - vous perdrez des données! Une partie de vos données se trouve dans le journal TX (quel que soit le modèle de récupération) ... si vous détachez et "renommez" le fichier journal TX qui supprime efficacement une partie de votre base de données.

Pour ceux qui ont supprimé le journal TX, vous souhaiterez peut-être exécuter quelques commandes checkdb et corriger la corruption avant de perdre plus de données.

Consultez les articles de blog de Paul Randal sur ce sujet, mauvais conseils .

De même, en général, n'utilisez pas de fichier rétractable sur les fichiers MDF car cela peut considérablement fragmenter vos données. Consultez sa section Bad Advice pour plus d'informations ("Pourquoi vous ne devriez pas réduire vos fichiers de données")

Consultez le site Web de Paul - il couvre ces mêmes questions. Le mois dernier, il a abordé bon nombre de ces problèmes dans sa série Myth A Day .


+1 Pour être la première réponse à mentionner que ce n'est peut-être pas une bonne idée! L'OP spécifie une base de données de test, mais c'est un point qui mérite d'être souligné pour le cas plus général.
Martin Smith

J'aurais dû ajouter - Si vous supprimez le journal TX - Mettre à jour le CV!
ripvlan

4

Pour tronquer le fichier journal:

  • Sauvegarder la base de données
  • Détachez la base de données, à l'aide d'Enterprise Manager ou en exécutant: Sp_DetachDB [DBName]
  • Supprimez le fichier journal des transactions. (ou renommez le fichier, au cas où)
  • Rattachez à nouveau la base de données à l'aide de: Sp_AttachDB [DBName]
  • Lorsque la base de données est attachée, un nouveau fichier journal des transactions est créé.

Pour réduire le fichier journal:

  • Journal de sauvegarde [DBName] avec No_Log
  • Réduisez la base de données en:

    En utilisant Enterprise Manager: - Faites un clic droit sur la base de données, Toutes les tâches, Réduire la base de données, Fichiers, Sélectionner le fichier journal, OK.

    Utilisation de T-SQL: - Dbcc Shrinkfile ([Log_Logical_Name])

Vous pouvez trouver le nom logique du fichier journal en exécutant sp_helpdb ou en recherchant dans les propriétés de la base de données dans Enterprise Manager.


Ne supprimez jamais le journal des transactions. Une partie de vos données se trouve dans le journal. Supprimez-le et la base de données sera corrompue. Je n'ai pas de représentant pour voter contre.
ripvlan

4

D'après mon expérience sur la plupart des serveurs SQL, il n'y a pas de sauvegarde du journal des transactions. Les sauvegardes complètes ou les sauvegardes différentielles sont une pratique courante, mais les sauvegardes du journal des transactions sont vraiment rares. Le fichier journal des transactions se développe donc pour toujours (jusqu'à ce que le disque soit plein). Dans ce cas, le modèle de récupération doit être défini sur " simple ". N'oubliez pas de modifier également les bases de données système "model" et "tempdb".

Une sauvegarde de la base de données "tempdb" n'a aucun sens, donc le modèle de récupération de cette base de données doit toujours être "simple".


Le simple fait de définir la base de données sur simple ne réduira pas le fichier journal, quel que soit l'état dans lequel il se trouve actuellement.
Aaron Bertrand

4
  1. Faites une sauvegarde du fichier MDB.
  2. Arrêter les services SQL
  3. Renommez le fichier journal
  4. Démarrez le service

(Le système créera un nouveau fichier journal.)

Supprimez ou déplacez le fichier journal renommé.


3

C'est arrivé avec moi où le fichier journal de la base de données était de 28 Go.

Que pouvez-vous faire pour réduire cela? En fait, les fichiers journaux sont ces données de fichier que le serveur SQL conserve lorsqu'une transaction a eu lieu. Pour une transaction à traiter, le serveur SQL alloue des pages pour le même. Mais après l'achèvement de la transaction, ceux-ci ne sont pas libérés soudainement en espérant qu'une transaction arrive comme la même. Cela tient l'espace.

Étape 1: exécutez d'abord cette commande dans le point de contrôle de la requête de base de données explorée

Étape 2: Faites un clic droit sur la base de données Tâche> Sauvegarder Sélectionnez le type de sauvegarde comme journal des transactions Ajoutez une adresse de destination et un nom de fichier pour conserver les données de sauvegarde (.bak)

Répétez cette étape à nouveau et donnez à ce moment un autre nom de fichier

entrez la description de l'image ici

Étape 3: Maintenant, allez dans la base de données Faites un clic droit sur la base de données

Tâches> Rétrécir> Fichiers Choisissez le type de fichier comme action de réduction du journal pour libérer de l'espace inutilisé

entrez la description de l'image ici

Étape 4:

Vérifiez votre fichier journal normalement dans SQL 2014, vous pouvez le trouver sur

C: \ Program Files \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

Dans mon cas, sa réduction de 28 Go à 1 Mo


2

Essaye ça:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

TRUNCATE_ONLYn'est plus une option dans les versions actuelles de SQL Server et n'est pas recommandé sur les versions qui le prennent en charge (voir la réponse de Rachel ).
Aaron Bertrand

Cela fonctionne pour moi en utilisant l'édition standard de MSSQL Server 2005
bksi

2

Base de données → cliquez avec le bouton droit sur Propriétés → fichier → ajoutez un autre fichier journal avec un nom différent et définissez le chemin d'accès comme l'ancien fichier journal avec un nom de fichier différent.

La base de données récupère automatiquement le fichier journal nouvellement créé.


1
  1. DB de sauvegarde
  2. Détacher la base de données
  3. Renommer le fichier journal
  4. Attacher la base de données (tout en attachant supprimer .ldf renommé (fichier journal) .Sélectionnez-le et supprimez en appuyant sur le bouton Supprimer)
  5. Un nouveau fichier journal sera recréé
  6. Supprimer le fichier journal renommé.

Cela fonctionnera mais il est suggéré de faire une sauvegarde de votre base de données en premier.


1

Certaines des autres réponses n'ont pas fonctionné pour moi: il n'était pas possible de créer le point de contrôle pendant que la base de données était en ligne, car le journal des transactions était plein (ironique). Cependant, après avoir mis la base de données en mode d'urgence, j'ai pu réduire le fichier journal:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

0

Exemple:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

TRUNCATE_ONLYn'est plus une option dans les versions actuelles de SQL Server et n'est pas recommandé sur les versions qui le prennent en charge (voir la réponse de Rachel ).
Aaron Bertrand

La question ne concerne pas le débordement de pile tel que défini dans le centre d'aide . Veuillez ne pas répondre à ces questions; au lieu de cela, vous devez les signaler à l'attention et ils seront fermés ou migrés de manière appropriée.
Toby Speight

0

Réponse légèrement mise à jour, pour MSSQL 2017, et utilisant le studio de gestion de serveur SQL. Je suis principalement allé de ces instructions https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

J'ai eu une sauvegarde récente de la base de données, j'ai donc sauvegardé le journal des transactions. Ensuite, je l'ai sauvegardé à nouveau pour faire bonne mesure. Finalement, j'ai réduit le fichier journal et je suis passé de 20G à 7MB, beaucoup plus en ligne avec la taille de mes données. Je ne pense pas que les journaux de transactions aient été sauvegardés depuis qu'ils ont été installés il y a 2 ans .. donc mettre cette tâche sur le calendrier d'entretien.


-1

Réduire le journal des transactions DB à la taille minimale :

  1. Sauvegarde: journal des transactions
  2. Réduire les fichiers: journal des transactions
  3. Sauvegarde: journal des transactions
  4. Réduire les fichiers: journal des transactions

J'ai fait des tests sur plusieurs DB: cette séquence fonctionne .

Il habituellement réduit à 2MB .

OU par un script:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO

1
TRUNCATE_ONLYn'est plus une option dans les versions actuelles de SQL Server et n'est pas recommandé sur les versions qui le prennent en charge (voir la réponse de Rachel ).
Aaron Bertrand
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.