Comment voulez-vous effacer le journal des transactions SQL Server?

https://stackoverflow.com/questions/56628

09-06-2019
|

Question

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

La solution

Faire un fichier journal de plus petite doit vraiment être réservés pour les scénarios où il a rencontré la croissance inattendue de laquelle vous ne vous attendez pas à se produire de nouveau.Si le fichier journal va croître à la même taille, pas beaucoup est accompli par la réduction temporaire.Maintenant, selon les objectifs de récupération de votre base de données, ce sont les mesures que vous devez prendre.

Tout d'abord, prendre une sauvegarde complète

Ne jamais apporter des modifications à votre base de données sans s'assurer de pouvoir les restaurer si quelque chose va mal.

Si vous vous souciez de point-à-temps de récupération

(Et par point-à-temps de récupération, je veux dire que vous vous souciez d'être en mesure de restaurer à rien d'autre qu'une sauvegarde complète ou différentielle.)

Sans doute votre base de données est en FULL mode de récupération.Si non, alors assurez-vous qu'il est:

ALTER DATABASE testdb SET RECOVERY FULL;

Même si vous prenez régulièrement des sauvegardes complètes, le fichier journal grandir et grandir jusqu'à ce que vous effectuez une journal sauvegarde - c'est pour votre protection, de ne pas inutilement de les ronger votre espace disque.Vous devez effectuer ces sauvegardes du journal assez fréquemment, en fonction de vos objectifs de rétablissement.Par exemple, si vous avez une entreprise de règle que les états que vous pouvez vous permettre de perdre pas plus de 15 minutes de données en cas de sinistre, vous devez avoir un emploi qui sauvegarde le journal toutes les 15 minutes.Voici un script qui va générer horodaté des noms de fichiers basés sur l'heure actuelle (mais vous pouvez aussi le faire avec des plans de maintenance, etc., il suffit de ne pas choisir tout de la réduction des options dans les plans de maintenance, ils sont affreux).

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 \\backup_share\ devrait être sur une autre machine que représente un autre périphérique de stockage sous-jacent.La sauvegarde de ces à la même machine (ou à une autre machine qui utilise le même sous-jacent disques, ou une autre VM sur le même hôte physique) n'a pas vraiment vous aider, car si la machine explose, vous avez perdu votre base de données et ses sauvegardes.En fonction de votre infrastructure réseau, il peut faire plus de sens de la sauvegarde en local, puis de les transférer vers un autre emplacement en coulisses;dans les deux cas, vous souhaitez obtenir hors de la base de données primaire de la machine le plus rapidement possible.

Maintenant, une fois que vous avez régulièrement des sauvegardes du journal cours d'exécution, il doit être raisonnable de réduire le fichier journal pour quelque chose de plus raisonnable que ce que c'est soufflé jusqu'à maintenant.Ce n' pas signifie l'exécution de SHRINKFILE encore et encore jusqu'à ce que le fichier journal est de 1 MO - même si vous êtes la sauvegarde du journal fréquemment, il doit continuer à s'adapter à la somme de toutes les transactions simultanées qui peuvent se produire.Fichier journal de croissance automatique des événements sont coûteux, étant donné que SQL Server a pour mettre à zéro les fichiers (contrairement aux fichiers de données lors de l'initialisation de fichier instantanée est activée), et de l'utilisateur opérations doivent attendre que tout cela se passe.Vous souhaitez faire croître-shrink-grow-shrink routine aussi peu que possible, et vous ne voulez certainement pas à faire vos utilisateurs à payer pour cela.

Notez que vous devrez peut-être sauvegarder le journal à deux fois avant d'un psy est possible (merci Robert).

Donc, vous devez venir avec un format pratique pour votre fichier de log.Personne ici ne peut vous dire ce qui est, sans le savoir beaucoup plus sur votre système, mais si vous avez été fréquemment réduction du fichier journal et il a été de plus en plus de nouveau, une bonne filigrane est probablement de 10 à 50% plus élevé que le plus important c'est l'été.Disons que vient de 200 MO, et vous voulez une ultérieure croissance automatique des événements à 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 pouvez avoir besoin pour exécuter cette première:

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

Si vous ne se soucient pas de point-à-temps de récupération

Si c'est une base de données de test, et vous ne se soucient pas de point-à-temps de récupération, alors vous devez vous assurer que votre base de données est en SIMPLE mode de récupération.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Mettre la base de données en SIMPLE récupération de mode, assurez-vous que SQL Server ré-utilise des portions du fichier de log (essentiellement l'élimination progressive des transactions inactives) au lieu de tenir un registre de tous transactions (comme FULL la récupération est jusqu'à vous sauvegardez le journal). CHECKPOINT les événements de vous aider à contrôler le journal et assurez-vous qu'il n'a pas besoin de grandir, à moins de vous générer beaucoup de t-journal de l'activité entre les CHECKPOINTs.

Ensuite, vous devez faire absolue assurez-vous que ce journal de la croissance est dû à un événement anormal (par exemple, une annuelle de nettoyage de printemps ou la reconstruction de votre plus grand index), et n'est pas due à la normale, l'utilisation de tous les jours.Si vous réduisez la taille du fichier journal à l'ridiculement petite taille, et SQL Server a juste à pousser à nouveau pour accueillir votre activité normale, qu'avez-vous à y gagner?Avez-vous été en mesure de faire usage de l'espace disque libéré seulement temporairement?Si vous avez besoin d'une solution immédiate, alors vous pouvez exécuter les opérations suivantes:

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 appropriée et le taux de croissance.Comme pour l'exemple dans le point-à-temps de récupération cas, vous pouvez utiliser le même code et de la logique pour déterminer ce que la taille du fichier est approprié et ensemble raisonnable de croissance automatique des paramètres.

Certaines choses que vous ne voulez pas faire

Sauvegarder le journal avec TRUNCATE_ONLY option, puis SHRINKFILE.Pour l'un, ce TRUNCATE_ONLY option a été supprimée et n'est plus disponible dans les versions actuelles de SQL Server.Deuxièmement, si vous êtes dans FULL modèle de récupération, cela va détruire votre journal et de la chaîne d'exiger une nouvelle sauvegarde complète.
Détachez la base de données, supprimez le fichier journal, et re-joindre.Je ne peux pas souligner à quel point dangereux, cela peut être.Votre base de données ne peut pas revenir, il peut venir comme suspect, vous pourriez avoir à revenir à une sauvegarde (si vous en avez un), etc.etc.
Utiliser le "rétrécissement de la base de données" option. DBCC SHRINKDATABASE et l'option de plan de maintenance à faire la même chose sont de mauvaises idées, surtout si vous avez vraiment besoin pour résoudre un journal de problème de problème.Cible le fichier que vous voulez régler et ajuster de façon indépendante, à l'aide de DBCC SHRINKFILE ou ALTER DATABASE ... MODIFY FILE (exemples ci-dessus).
Réduire le journal de fichiers de 1 MO.Cela semble tentant parce que, hé, SQL Server laissez-moi le faire dans certains scénarios, et de regarder tout l'espace qu'il libère!À moins que votre base de données est en lecture seule (et c'est, vous devez marquer comme tels à l'aide de ALTER DATABASE), ce sera absolument simplement conduire à de nombreux inutile de croissance d'événements, le journal a pour accueillir les transactions en cours quel que soit le modèle de récupération.Quel est le point de libérer l'espace temporairement, juste pour SQL Server peut reprendre lentement et douloureusement?
Créer un deuxième fichier journal.Cela donnera soulagement temporaire pour le lecteur qui a rempli votre disque dur, mais c'est comme essayer de réparer une perforation du poumon avec un band-aid.Vous devriez traiter avec la problématique de fichier journal directement au lieu de simplement ajouter un autre problème potentiel.Autres que de rediriger un journal des transactions d'activité à un autre lecteur, un deuxième fichier journal n'a vraiment rien pour vous (à la différence d'un deuxième fichier de données), car un seul des fichiers peut jamais être utilisé à la fois. Paul Randal explique aussi pourquoi plusieurs fichiers journaux peuvent vous mordre plus tard.

Être proactif

Au lieu de la réduction de votre fichier de log pour un petit montant et de le laisser en permanence la croissance automatique à un taux faible sur son propre, affectez-lui une assez grande taille (celui qui va accueillir la somme de votre plus grand ensemble de transactions simultanées) et d'un raisonnable paramètre d'étendue automatique comme un secours, de sorte qu'il n'a pas à pousser plusieurs fois pour satisfaire des transactions uniques et donc qu'il sera relativement rare pour qu'il ait à croître au cours normal de ses activités.

Le pire des paramètres possibles sont ici 1 MO de croissance ou croissance de 10%.Assez drôle, ce sont les valeurs par défaut de SQL Server (dont je me suis plaint et demandé des modifications en vain) - 1 MO pour les fichiers de données, et de 10% pour les fichiers journaux.L'ancien est beaucoup trop petit, dans cette journée et l'âge, et celle-ci conduit à de plus en plus longtemps les événements de tous les temps (par exemple, votre fichier de log est de 500 MO, d'abord la croissance est de 50 MO, suivant la croissance est de 55 MO, suivant la croissance est de 60,5 MO, etc.etc.- et sur d'e/S lent, croyez-moi, vous aurez vraiment l'avis de cette courbe).

Lectures complémentaires

S'il vous plaît ne vous arrêtez pas ici;tandis que la plupart des conseils que vous voyez là-bas sur la réduction des fichiers journaux est intrinsèquement mauvais et même potentiellement désastreux, il y a des gens qui se soucient plus de l'intégrité des données que de libérer de l'espace disque.

Un blog que j'ai écrit en 2009, quand j'ai vu quelques "voici comment faire pour réduire le fichier journal" postes printemps jusqu'.

Un blog Brent Ozar a écrit il y a quatre ans, en pointant à de multiples ressources, en réponse à un Serveur SQL server Magazine de l'article qui devrait pas ont été publiés.

Un post de blog de Paul Randal expliquant pourquoi t-journal de l'entretien est important et pourquoi vous ne devriez pas réduire vos fichiers de données, soit.

Mike Walsh, qui a une grande réponse couvrant certains de ces aspects, y compris les raisons pour lesquelles vous pourriez ne pas être en mesure de réduire votre fichier de log immédiatement.

Autres conseils

AVERTISSEMENT: Merci de lire les commentaires ci-dessous attentivement, et je suppose que vous avez déjà lu la accepté de répondre.Comme je l'ai dit presque 5 ans:

si quelqu'un a des commentaires à ajouter pour les situations où ce n'est PAS un adéquat ou une solution optimale, alors s'il vous plaît commentaire ci-dessous

Clic droit sur le nom de base de données.
Sélectionnez Les Tâches → Rétrécir → Base De Données
Puis cliquez sur OK!

J'ai l'habitude d'ouvrir l'Explorateur Windows, le répertoire contenant les fichiers de base de données, afin que je puisse voir immédiatement l'effet.

J'ai été très surpris de voir que cela a fonctionné!Normalement, j'ai utilisé la commande DBCC avant, mais j'ai juste essayé et ça n'a pas de rétrécissement de rien, donc j'ai essayé de l'interface graphique (2005) et il a très bien fonctionné - libérant de 17 GO de 10 secondes

En mode de récupération Complet cela pourrait ne pas fonctionner, donc vous devez sauvegarder le journal, ou de changer de récupération Simple, puis réduire le fichier.[merci @onupdatecascade pour cette]

PS:J'apprécie ce que certains ont fait des observations sur les dangers de ce, mais dans mon environnement, je n'ai pas de problèmes à faire cela moi-même, surtout depuis que je fais toujours une sauvegarde complète de la première.Merci donc de prendre en considération ce que votre environnement est, et comment cela affecte votre stratégie de sauvegarde et de sécurité d'emploi avant de continuer.Tout ce que je faisais en pointant les gens à une fonctionnalité fournie par Microsoft!

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 pouvez sauvegarder en premier.

Ci-dessous est un script pour réduire le journal des transactions, mais je serais certainement vous conseillons de sauvegarder le journal des transactions avant de la faire diminuer.

Si vous venez de réduire le fichier que vous allez perdre une tonne de données qui peut venir comme une bouée de sauvetage en cas de catastrophe.Le journal des transactions contient un grand nombre de données utiles qui peuvent être lus à l'aide d'un tiers des transactions de lecture du journal (il peut être lu à la main, mais avec un effort extrême, quoique).

Le journal des transactions est également un must quand il s'agit de point dans le temps de récupération, donc, ne pas le jeter, mais assurez-vous de sauvegarder au préalable.

Voici plusieurs posts où les gens ont utilisé des données stockées dans le journal des transactions pour accomplir 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 lors de l'exécution des commandes ci-dessus

“Ne peut pas réduire le fichier journal (log file name) en raison de la logique fichier journal se trouvant à la fin du fichier est en cours d'utilisation“

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

Si vous n'utilisez pas les journaux des transactions pour les restaurations (c'est à direVous ne jamais effectuer des sauvegardes complètes), vous pouvez définir le Mode de Récupération "Simple", et le journal des transactions très peu de temps à rétrécir et à ne jamais remplir de nouveau.

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

Ce n'est pas recommandé dans les environnements de production evidemment, puisque vous ne serez pas en mesure de restaurer à un point dans le temps.

Voici un simple et très inélégant & potentiellement dangereux façon.

Sauvegarde de la DB
Détacher DB
Renommer le fichier Journal
Joindre DB
Nouveau fichier journal sera recréé
Supprimer Renommé le fichier de Log.

Je devine que vous n'êtes pas de faire des sauvegardes du journal.(Qui tronquer le journal).Mon conseil est de changer de modèle de récupération de plein pour simple.Cela permettra d'éviter journal de la météorisation.

La plupart des réponses ici jusqu'à présent sont en supposant que vous n'avez pas réellement besoin du fichier du Journal des Transactions, cependant si votre base de données à l'aide de la FULL modèle de récupération, et vous voulez garder vos sauvegardes dans le cas où vous avez besoin de restaurer la base de données, puis ne pas tronquer ou de supprimer le fichier journal de la façon dont beaucoup de ces réponses suggèrent.

Éliminer le fichier journal (par le biais de la tronquant, de s'en débarrasser, de l'effacer, etc) va briser votre chaîne de sauvegarde, et vous évitera de les restaurer à tout moment depuis votre dernière complète, différentielle ou de la sauvegarde du journal des transactions, jusqu'à la prochaine sauvegarde complète ou différentielle est faite.

À partir de la L'article Microsoft surBACKUP

Nous vous recommandons de ne jamais utiliser NO_LOG ou TRUNCATE_ONLY manuellement tronquer le journal des transactions, car cela rompt avec le journal de la chaîne.Jusqu'à ce que le prochain complète ou différentielle sauvegarde de base de données, la base de données n'est pas protégé de l'incapacité des médias.Utiliser la troncature du journal dans très des circonstances particulières, et de créer des sauvegardes de données immédiatement.

Pour éviter cela, de sauvegarde de votre fichier de log sur le disque avant d'en réduire la taille.La syntaxe ressemble à 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 maintenue, afin d'empêcher ses indésirables de la croissance.Cela signifie que l'exécution de sauvegardes du journal des transactions assez souvent.En ne faisant pas cela, vous risquez de le journal des transactions pour devenir complet et commencer à croître.

Outre les réponses pour cette question, je vous recommande la lecture et la compréhension du journal des transactions courantes des mythes.Ces lectures peuvent aider à la compréhension du journal des transactions et de décider quelles sont les techniques à utiliser pour "clair" c':

À partir de 10 le plus important journal des transactions SQL Server mythes:

Mythe:Mon Serveur SQL est trop occupé.Je ne veux pas faire de SQL Server sauvegardes du journal des transactions

L'un des plus grands de la performance des opérations intensives dans SQL Server est un auto-grandir l'événement de la transaction en ligne le fichier de log.En ne faisant pas de sauvegardes du journal des transactions, assez souvent, à la transaction en ligne du journal deviendra plein et devra grandir.La valeur par défaut taille de croissance est de 10%.Le plus occupé de la base de données est, le plus rapide en ligne du journal des transactions augmentera si les sauvegardes du journal des transactions ne sont pas créés La création d'un journal des transactions SQL Server sauvegarde ne bloque pas la ligne du journal des transactions, mais une auto-croissance événement n'.Il peut bloquer toute activité en ligne dans le journal des transactions

À partir de Journal des transactions mythes:

Mythe:Régulière du journal la diminution est une bonne pratique de la maintenance

FAUX.Journal de la croissance est très cher car le nouveau bloc doit être mis à zéro-out.Toute activité d'écriture s'arrête sur cette base de données jusqu'à ce que la réinitialisation est terminée, et si votre écriture sur le disque est lent ou de croissance automatique de la taille est grande, cette pause peut être énormes, et les utilisateurs remarqueront.C'est une des raisons pourquoi vous voulez éviter de croissance.Si vous réduisez la taille du journal, il va croître de nouveau, et vous êtes juste de gaspiller opération de disque sur inutile shrink-et-augmenter-nouveau jeu

Cette technique que John recommande n'est pas recommandé car il n'y a aucune garantie que la base de données va s'attacher sans le fichier journal.Modifier la base de données complète en simple, la force d'un point de contrôle et d'attendre quelques minutes.Le Serveur SQL server va effacer le journal, que vous pouvez puis de le réduire à l'aide de la commande DBCC SHRINKFILE.

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

Journal de sauvegarde DatabaseName Avec Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile vous donnera le nom logique de fichier journal.

Reportez-vous à:

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

Si votre base de données est en mode de Récupération Complète et si vous ne prenez pas de TL de sauvegarde, puis de le modifier pour SIMPLE.

L'utilisation de la DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) commande.Si c'est une base de données de test et vous êtes en essayant de sauver/récupérer de l'espace, cela aidera.

Rappelez-vous cependant que TX journaux ont une sorte de minimum/état d'équilibre de la taille qu'ils vont grandir pour.En fonction de votre modèle de récupération que vous ne pouvez pas être en mesure de réduire le journal - si PLEINE et si vous n'êtes pas d'émission TX sauvegardes du journal le journal ne peut pas être réduit - il grandira jamais.Si vous n'avez pas besoin TX sauvegardes de journaux, changer votre mode de récupération Simple.

Et rappelez-vous, jamais, jamais, sous aucun cas supprimer le journal (LDF) fichier!Vous aurez à peu près les instantanés de base de données de la corruption.Cuit!Fait!Les données perdues!Si la gauche "réparée" le principal MDF fichier peut être corrompu en permanence.

Ne jamais supprimer le journal des transactions - vous risquez de perdre des données!Une partie de vos données est dans le TX Log (quel que soit le modèle de récupération)...si vous détachez et "renommer" le TX fichier journal efficacement supprime une partie de votre base de données.

Pour ceux qui ont supprimé le TX Journal que vous souhaitez utiliser quelques checkdb commandes et corriger le problème avant de vous perdre plus de données.

Découvrez Paul Randal messages de blog sur ce sujet, de mauvais conseils.

Aussi, en général, ne pas utiliser de shrinkfile sur les fichiers MDF comme il peut gravement fragment de vos données.Découvrez ses Mauvais Conseils de la section pour plus d'info ("Pourquoi vous ne devriez pas réduire vos fichiers de données")

Découvrez-Paul-site web -, il se couvre de ces questions.Le mois dernier il a parcouru beaucoup de ces questions dans son Le Mythe D'Un Jour de la série.

Pour Tronquer le fichier de log:

Sauvegarde de la base de données
Détachez la base de données, soit à l'aide d'Enterprise Manager ou en exécutant : Sp_DetachDB [DBName]
Supprimer le fichier du journal des transactions.(ou de renommer le fichier, juste au cas où)
Ré-attacher la base de données, en utilisant à nouveau: Sp_AttachDB [DBName]
Lorsque la base de données est connectée, un nouveau fichier journal de transactions est créé.

Pour réduire le fichier journal:

Journal de sauvegarde [DBName] avec No_Log
Réduire la base de données soit par:

À l'aide d'Enterprise manager :- Cliquez-droit sur la base de données, Toutes les tâches, réduire la base de données, des Fichiers, Sélectionnez un fichier journal, OK.

À l'aide de T-SQL :- Dbcc Shrinkfile ([Log_Logical_Name])

Vous pouvez trouver le nom logique du fichier journal en cours d'exécution sp_helpdb ou en regardant dans les propriétés de la base de données dans le Gestionnaire Enterprise manager.

De mon expérience sur la plupart des Serveurs SQL il n'y a pas de sauvegarde du journal des transactions.Des sauvegardes complètes ou des sauvegardes différentielles sont de pratique courante, mais les sauvegardes du journal des transactions sont vraiment rarement.Si le fichier journal des transactions augmente toujours (jusqu'à ce que le disque est plein).Dans ce cas, le modèle de récupération doit être réglé sur "simple".N'oubliez pas de modifier le système de bases de données "modèle" et "la base de données tempdb", trop.

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

Faire une sauvegarde du fichier MDB.
Arrêter les services SQL
Renommez le fichier journal
Démarrer le service

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

Supprimer ou déplacer la renommé le fichier de log.

Essayez ceci:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO

Base de données → clic droit Propriétés → fichier → ajouter un autre fichier journal avec un nom différent et définir le chemin d'accès le même que l'ancien fichier journal avec un nom de fichier différent.

La base de données prend automatiquement le nouveau fichier journal.

Sauvegarde de la DB
Détacher DB
Renommer le fichier Journal
Joindre DB (tout en l'assortissant de supprimer renommé .ldf (fichier journal).Sélectionner et supprimer en appuyant sur le bouton Supprimer)
Nouveau fichier journal sera recréé
Supprimer Renommé le fichier de Log.

Cela fonctionne, mais il est suggéré de prendre la sauvegarde de votre base de données en premier.

Exemple:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Il s'est passé avec moi où la base de données de fichier journal a été de 28 Sgb.

Que pouvez-vous faire pour réduire ce?En fait, les fichiers journaux sont celles du fichier de données SQL server conserve lorsqu'une transaction a eu lieu.Pour une transaction de processus SQL server alloue de pages pour le même.Mais après l'achèvement de la transaction, ce ne sont pas libérés soudain, en espérant qu'il peut y avoir une transaction à venir comme le même.Cela tient de l'espace.

Étape 1:La première Exécution de cette commande dans la requête de base de données explorées point de contrôle

Étape 2:Cliquez-droit sur la base de données La tâche> sauvegarder Sélectionnez sauvegarder type de Journal des Transactions Ajouter une adresse de destination et le nom du fichier à conserver les données de sauvegarde (.bak)

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

Étape 3:Maintenant, allez dans la base de données Cliquez-droit sur la base de données

Les Tâches> Rétrécit> Fichiers Choisir le type de Fichier Log Rétrécir l'action que la libération de l'espace inutilisé

Étape 4:

Vérifiez votre fichier de log normalement dans SQL 2014 ce qui peut être trouvé à

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

Dans mon cas, sa réduit de 28 GO à 1 MO

Certains des autres réponses n'a pas fonctionné pour moi:Il n'était pas possible de créer le poste de contrôle alors que la db est en ligne, parce que le journal des transactions était plein (quelle ironie).Cependant, après le réglage de la base de données en mode d'urgence, j'ai été en mesure de réduire le fichier de log:

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

DB Journal des Transactions Réduire à min taille:

Sauvegarde:Journal des transactions
Shrink fichiers:Journal des transactions
Sauvegarde:Journal des transactions
Shrink fichiers:Journal des transactions

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

Habituellement, il réduit à 2 MO.

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

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow