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?

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 .

-- 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.

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!

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:

• Comment afficher les journaux de transactions dans SQL Server 2008

• Lire le fichier journal (* .LDF) dans SQL Server 2008

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.

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.

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é.

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.

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)

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.

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.

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 .

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.

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".

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é.

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

É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é

É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

Essaye ça:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

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. 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.

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);

Exemple:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

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.

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