Comment effacer le journal des transactions du serveur SQL?
Je ne suis pas un expert en SQL, et je me rappelle le fait que chaque fois que j'ai besoin de 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 est certainement. Comment puis-je vider le journal des transactions?
20 réponses
rendre un fichier journal plus petit devrait vraiment être réservé pour les scénarios où il a rencontré une croissance inattendue que vous ne vous attendez pas à se produire à 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 modifiez jamais votre base de données sans assurer vous pouvez restaurer quelque chose est mal.
Si vous vous souciez de point-à-temps de récupération
(et par point-in-time recovery, je veux dire que vous vous souciez de pouvoir restaurer autre chose qu'une sauvegarde complète ou différentielle.)
probablement votre base de données est en mode de récupération FULL . Sinon, assurez-vous qu'il est:
ALTER DATABASE testdb SET RECOVERY FULL;
Même si vous prenez régulièrement des sauvegardes complètes, l' le fichier journal se développera et se développera jusqu'à ce que vous effectuiez une sauvegarde log - c'est pour votre protection, ne pas manger inutilement à votre espace disque. Vous devriez effectuer ces sauvegardes de journal assez fréquemment, en fonction de vos objectifs de récupération. Par exemple, si vous avez une règle d'affaires qui stipule que vous pouvez vous permettre de perdre pas plus de 15 minutes de données en cas de catastrophe, vous devriez avoir un travail qui sauvegarde le journal toutes les 15 minutes. Voici un script qui générera les noms de fichiers horodatés en fonction de l'heure actuelle (mais vous pouvez également le faire avec les plans de maintenance, etc.), il suffit de ne pas choisir l'une des options de rétrécissement dans les plans d'entretien, ils sont terribles).
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;
noter que \backup_share\ doit être placé sur une machine différente qui représente un dispositif de stockage sous-jacent différent. Les sauvegarder sur la même machine (ou sur une autre machine qui utilise les mêmes disques sous-jacents, ou sur une autre VM qui est sur le même hôte physique)) ne vous aide pas vraiment, puisque si la machine explose, vous avez perdu votre base de données et ses sauvegardes. En fonction de votre infrastructure réseau, il peut être plus judicieux de sauvegarder localement puis de les transférer à un autre endroit dans les coulisses; dans les deux cas, vous voulez les retirer de la machine de base de données primaire aussi rapidement que possible.
maintenant, une fois que vous avez des sauvegardes journalières en cours d'exécution, il devrait être raisonnable de rétrécir le fichier journal à quelque chose de plus raisonnable que ce qui a explosé jusqu'à maintenant. Cela ne pas signifie Exécuter SHRINKFILE encore et encore jusqu'à ce que le fichier journal soit de 1 Mo - même si vous sauvegardez le journal fréquemment, il doit toujours accommoder la somme de toutes les transactions simultanées qui peuvent se produire. Les évènements d'autogrow de fichiers journaux sont coûteux, car SQL Server doit mettre les fichiers à zéro (contrairement aux fichiers de données lorsque l'initialisation de fichiers instantanés est activée), et les transactions utilisateur doivent attendre 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 pourriez avoir besoin de sauvegarder le rondin deux fois avant qu'un rétrécissement 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, un bon filigrane est probablement 10-50% plus élevé que le plus grand il a été. Disons que cela vient à 200 Mo, et que vous voulez que tous les événements subséquents d'autogrowth soit de 50 Mo, alors vous pouvez ajuster la taille du fichier log 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 ce premier:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Si vous ne se soucient pas de point-à-temps de récupération
si il s'agit d'une base de données de test, et vous ne vous souciez pas de point-in-time recovery, alors vous devriez vous assurer que votre base de données est en mode de récupération SIMPLE .
ALTER DATABASE testdb SET RECOVERY SIMPLE;
mettre la base de données en mode de récupération SIMPLE permettra de s'assurer que SQL Server réutilise des parties du fichier journal (essentiellement en éliminant les transactions inactives) au lieu de croître pour conserver un enregistrement de toutes les" transactions (comme FULL récupération fait jusqu'à ce que vous sauvegardez journal.) Les événements CHECKPOINT aideront à contrôler le journal et à s'assurer qu'il n'a pas besoin de croître à moins de générer beaucoup d'activité de t-log entre CHECKPOINT s.
ensuite, vous devez absolument vous assurer que cette croissance logarithmique était vraiment due à un événement anormal (par exemple, un nettoyage de printemps annuel ou la reconstruction de vos plus grands indices), et non pas en raison de l'utilisation normale, quotidienne. Si vous réduisez le fichier log à une taille ridiculement petite, et SQL Server doit juste le faire pousser à nouveau pour accommoder votre activité normale, qu'avez-vous gagné? Avez-vous pu utiliser l'espace disque que vous avez libéré seulement temporairement? Si vous avez besoin d'une correction immédiate, alors 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, fixer une taille et un taux de croissance appropriés. Comme dans l'exemple du cas de récupération point-in-time, vous pouvez utiliser le même code et la même logique pour déterminer quelle taille de fichier est appropriée et définir des paramètres raisonnables d'autogrowth.
Certaines choses que vous ne voulez pas faire
-
sauvegardez le journal avec l'option
TRUNCATE_ONLYet ensuiteSHRINKFILE. Par exemple, cette optionTRUNCATE_ONLYa été dépréciée et n'est plus disponible dans les versions actuelles de SQL Server. Deuxièmement, si vous êtes dans le modèle de récupérationFULL, cela détruira votre chaîne de log et nécessitera une nouvelle sauvegarde complète. -
Détacher la base de données, supprimer le fichier journal, et re-joindre . Je ne peux pas souligner à quel point dangereux, cela peut être. Votre base de données peut ne pas revenir, elle peut apparaître comme suspecte, vous pouvez devoir revenir à une sauvegarde (si vous en avez une), etc. etc.
-
utilisez l'option" base de données de rétrécissement .
DBCC SHRINKDATABASEet l'option de plan de maintenance pour faire la même chose sont de mauvaises idées, surtout si vous avez vraiment besoin de résoudre un problème de journal. Ciblez le fichier que vous voulez ajuster et ajustez-le indépendamment, en utilisantDBCC SHRINKFILEouALTER DATABASE ... MODIFY FILE(exemples ci-dessus). -
réduire le journal de fichiers de 1 MO . Cela semble tentant parce que, hey, SQL Server va me laisser le faire dans certains scénarios, et regardez tout l'espace qu'il libère! À moins que votre base de données ne soit lue seulement (et elle l'est, vous devriez la marquer comme telle en utilisant
ALTER DATABASE), cela conduira absolument juste à beaucoup les événements de croissance inutiles, car le journal doit s'adapter aux transactions courantes, quel que soit le modèle de récupération. Quel est l'intérêt de libérer cet espace temporairement, juste pour que SQL Server puisse le reprendre lentement et douloureusement? -
créer un deuxième fichier journal . Cela fournira temporairement le soulagement pour le lecteur qui a rempli votre disque, mais c'est comme essayer de fixer un poumon perforé avec un pansement. Vous devriez traiter les avec le fichier journal problématique directement au lieu d'ajouter simplement un autre problème potentiel. En plus de rediriger une certaine activité de journal de transaction vers un lecteur différent, un deuxième fichier de journal ne fait vraiment rien pour vous (contrairement à un deuxième fichier de données), puisque seulement un des fichiers peut jamais être utilisé à la fois. Paul Randal explique aussi pourquoi plusieurs fichiers journaux peuvent vous piquer plus tard .
être proactif
à la place de rétrécir votre fichier journal à une petite quantité et de le laisser constamment autogrow à un petit taux sur son propre, mettez - le à une certaine taille raisonnablement grande (une qui accommodera la somme de votre plus grand ensemble de transactions concurrentes) et mettez un réglage autogrow raisonnable comme un repli, de sorte qu'il n'ait pas à croître plusieurs fois pour satisfaire des transactions simples et de sorte qu'il sera relativement rare pour lui de ne jamais avoir à croître pendant les opérations commerciales normales.
le les pires scénarios possibles sont une croissance de 1 MB ou de 10%. Assez drôle, ce sont les valeurs par défaut pour SQL Server (dont je me suis plaint et a demandé des changements sans résultat ) - 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 d'e/S lent, croire moi, vous aurez vraiment l'avis de cette courbe).
Lire la suite
S'il vous plaît ne vous arrêtez pas ici; alors 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 ya des gens qui se soucient plus de l'intégrité des données que de libérer de l'espace disque.
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 .
avertissement: veuillez lire attentivement les commentaires ci-dessous, et je présume 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 les situations où ce n'est pas solution adéquate ou optimale veuillez commenter ci-dessous
-
cliquez avec le bouton droit de la souris sur le nom de la base de données.
-
Sélectionner Des Tâches → Rétrécir → Base De Données
-
puis cliquez sur OK !
j'ouvre habituellement le répertoire Windows Explorer contenant les fichiers de la base de données, donc je peux immédiatement voir l'effet.
j'ai été en fait très surpris que cela ait fonctionné! Normalement, J'ai utilisé le DBCC avant, mais j'ai juste essayé ça et ça n'a pas rétréci quoi que ce soit, donc J'ai essayé de l'interface graphique (2005) et il a très bien fonctionné - libérant de 17 GO en 10 secondes
en mode de récupération complète cela pourrait ne pas fonctionner, donc vous devez soit sauvegarder le journal d'abord, ou passer à la récupération Simple, puis rétrécir le fichier. [merci @onupdatecascade pour cela]
--
PS: j'apprécie ce que certains ont commenté concernant les dangers de ceci, mais dans mon environnement je n'ai eu aucun problème à le faire moi-même en particulier puisque je fais toujours une sauvegarde complète d'abord. Donc, s'il vous plaît prendre en considération ce que votre environnement est, et comment cela affecte votre stratégie de sauvegarde et la sécurité de l'emploi avant de continuer. Tout ce que je faisais était de pointer les gens vers 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
From: DBCC SHRINKFILE (Transact-SQL)
vous pouvez vouloir sauvegarder en premier.
ci-dessous est un script pour rétrécir le journal des transactions, mais je recommande certainement sauvegarder le journal des transactions avant de le rétrécir.
si vous rétrécissez simplement le fichier vous allez perdre une tonne de données qui peuvent venir comme un sauveur de vie en cas de désastre. Le journal des transactions contient un grand nombre de données utiles qui peuvent être lues à l'aide d'un lecteur tiers journal des transactions (il peut être lu manuellement, mais avec un effort extrême cependant).
La transaction log est également un must quand il s'agit de point dans la récupération de temps, donc ne pas simplement jeter, mais assurez-vous de sauvegarder à l'avance.
voici plusieurs messages 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 lorsque les commandes d'exécution ci-dessus
"Ne peut pas réduire le fichier journal (log file name) en raison de la logique fichier log situé à la fin du fichier est en usage "
cela signifie que TLOG est utilisé. Dans ce cas, essayez d' exécuter ceci plusieurs fois d'affilée ou trouver un moyen de réduire les activités de base de données.
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 à" Simple", et le journal de transactions va très bientôt rétrécir et ne jamais remplir à nouveau.
si vous utilisez SQL 7 ou 2000, vous pouvez activer" truncate log on checkpoint " dans l'onglet Options de la base de données. Cela a le même effet.
ce n'est pas recommandé dans les environnements de production évidemment, car vous ne serez pas en mesure de restauration à un point précis dans le temps.
Voici une voie simple et très inélégante & potentiellement dangereuse .
- Sauvegarde de la DB
- Detach DB
- Renommer le fichier Journal
- Attach DB
- Nouveau fichier journal sera recréé
- supprimer le fichier Log renommé.
je suppose que vous ne faites pas de sauvegardes de journaux. (Qui tronquent le journal). Mon conseil est de changer le modèle de récupération de complet à simple . Cela empêchera le ballonnement de rondins.
la plupart des réponses ici jusqu'à présent supposent que vous n'avez pas réellement besoin du fichier journal des transactions, cependant si votre base de données utilise le modèle de récupération FULL , et que vous voulez garder vos sauvegardes au cas où vous auriez besoin de restaurer la base de données, alors ne pas tronquer ou supprimer le fichier journal comme beaucoup de ces réponses suggèrent.
L'élimination du fichier journal (en le tronquant, en le rejetant, en l'effaçant, etc.) cassera votre chaîne de sauvegarde, et vous empêchera de 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.
De la Microsoft article sur BACKUP
nous vous recommandons de ne jamais utiliser NO_LOG ou TRUNCATE_SEULEMENT à la main tronquer le journal des transactions, parce que cela brise la chaîne du journal. Jusqu' la prochaine base de données complète ou différentielle la sauvegarde, la base de données n'est pas protégé contre l'échec des médias. Utiliser la troncature du journal dans très circonstances spéciales, et créer des sauvegardes des données immédiatement.
pour éviter cela, sauvegardez votre fichier journal sur le disque avant de le rétrécir. La syntaxe ressemblerait à quelque chose comme 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 du serveur SQL doit être correctement tenu à jour afin d'empêcher sa croissance indésirable. Cela signifie exécuter des sauvegardes de journal de transaction 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 à 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 " clarifier" it:
à Partir de 10 le plus important journal des transactions SQL Server mythes :
mythe: mon serveur SQL est trop occupé. Je ne veux pas faire des sauvegardes SQL Server transaction log
L'une des opérations les plus intensives en termes de performances dans SQL Server est un événement de croissance automatique du fichier journal des transactions en ligne. En ne faisant pas des sauvegardes de journal de transaction assez souvent, le journal des transactions deviendra plein et devra grandir. La taille de croissance par défaut est de 10%. Plus la base de données est active, plus le journal des transactions en ligne se développera rapidement si les sauvegardes du journal des transactions ne sont pas créées La création D'une sauvegarde SQL Server transaction log 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
à Partir de journal des Transactions mythes :
mythe: le rétrécissement régulier des billes est une bonne pratique d'entretien
faux. La croissance logarithmique est très coûteuse parce que le nouveau morceau doit être recalé. Toutes les activités d'écriture s'arrêtent sur cette base de données jusqu'à ce que la réduction à zéro soit terminée, et si votre écriture de disque est lente ou si la taille de l'autogrowth 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 log, il va croître à nouveau et vous êtes juste gaspiller l'opération de disque sur inutile rétrécir-et-croître-jeu
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. Passez de la base de données complète à simple, forcez un point de contrôle et attendez quelques minutes. Le serveur SQL va effacer le journal, que vous pouvez alors rétrécir en utilisant DBCC SHRINKFILE.
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 la récupération simple 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 du fichier log.
se référer à:
Récupérer à partir d'un journal des transactions 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, alors changez-le en SIMPLE.
utilisez la commande DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) . Si c'est une base de données de test et que vous essayez de sauver/récupérer de l'espace, cela aidera.
rappelez-vous cependant que les bûches TX ont une sorte de taille minimale/stable qu'elles atteindront en grandissant. En fonction de votre modèle de récupération, vous ne pourrez peut - être pas rétrécir le journal - S'il est complet et que vous n'émettez pas de sauvegardes TX, le journal ne peut pas être rétréci-il grandira pour toujours. Si vous n'avez pas besoin de sauvegardes TX log, passez à Simple .
et rappelez-vous, jamais en aucun cas supprimer le fichier log (LDF)! Vous aurez à peu près beaucoup de corruption de base de données instantanée. Cuit! Fait! Les données perdues! Si on le laisse "non réparé", le fichier principal du MDF pourrait devenir 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 de log TX qui effectivement supprime partie de votre base de données.
pour ceux qui ont supprimé le journal TX, vous pouvez lancer quelques commandes checkdb et corriger la corruption avant de perdre plus de données.
consultez les billets du blog de Paul Randal sur ce même sujet, mauvais conseil .
aussi en général n'utilisez pas shrinkfile sur les fichiers MDF car il peut gravement fragmenter vos données. Consultez sa section mauvais conseils pour plus d'information ("pourquoi vous ne devriez pas rétrécir vos fichiers de données")
consultez le site Web de Paul - Il couvre ces mêmes questions. Le mois dernier, il a parcouru beaucoup de ces questions dans sa série Myth A Day .
pour tronquer le fichier journal:
- Sauvegarde de la base de données
- détachez la base de données, soit en utilisant Enterprise Manager, soit en exécutant: Sp_DetachDB [DBName]
- supprimer le fichier journal des transactions. (ou renommer le fichier, juste au cas)
- Ré-attacher la base de données, en utilisant à nouveau: Sp_AttachDB [DBName]
- lorsque la base de données est jointe, un nouveau fichier du journal des transactions est créé.
pour rétrécir le fichier journal:
- journal de Sauvegarde [DBName] avec No_Log
-
rétrécir la base de données par:
utilisant Enterprise manager :- Clic droit sur la base de données, toutes les tâches, base de données de rétrécissement, fichiers, sélectionnez le fichier journal, OK.
utilisant T-SQL :- Dbcc Shrinkfile ([Log_Logical_Name])
vous pouvez trouver le nom logique du fichier log en lançant sp_helpdb ou en regardant 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 différentielles sont une pratique courante, mais les sauvegardes du journal des transactions sont vraiment rares. Ainsi, le fichier journal des transactions croît à jamais (jusqu'à ce que le disque soit plein). Dans ce cas, le modèle de récupération doit être réglé sur " simple ". N'oubliez pas de modifier les bases de données système "model" et "tempdb", aussi.
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 devrait toujours être "simple".
- faites une sauvegarde du fichier MDB.
- Stop SQL services
- renommer le fichier log
- Démarrer le service
(Le système va créer un nouveau fichier journal.)
supprimer ou déplacer le fichier journal renommé.
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 log avec un nom différent et définir le chemin le même que l'ancien fichier log avec un nom de fichier différent.
la base de données récupère automatiquement le fichier journal nouvellement créé.
- Sauvegarde de la DB
- Detach DB
- Renommer le fichier Journal
- fixer DB (lors de la fixation supprimer renommé .ldf (fichier journal).Sélectionner et supprimer en appuyant sur le bouton Supprimer)
- Nouveau fichier journal sera recréé
- supprimer le fichier Log renommé.
cela fonctionnera, 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)
c'est arrivé avec moi où le fichier journal de la base de données était de 28 GBs.
Que pouvez-vous faire pour réduire ce? 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 SQL server attribue 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'il puisse y avoir une transaction venant comme la même. Cela tient de l'espace.
Étape 1: Lancez d'abord cette commande dans la requête de la base de données explorée le point de contrôle
Étape 2: Clic droit sur la base de données La tâche> sauvegarder Sélectionner le type de sauvegarde comme journal des transactions Ajouter une adresse de destination et le nom du fichier pour conserver les données de sauvegarde (.bak)
répétez cette étape encore une fois et à ce moment donner un autre nom de fichier
Étape 3: Maintenant, allez à la base de données Faites un clic droit sur la base de données
Tâches> Rétrécissements> Fichiers Choisir le type de fichier comme Log Action de rétrécissement comme libérer l'espace non utilisé
Étape 4:
Vérifiez votre fichier journal normalement, dans SQL 2014 ce peut être trouvé à la
C:\Program fichiers\Microsoft SQL Server\MSSQL12.MSSQL2014 EXPRESS\MSSQL\DATA
dans mon cas, son réduit de 28 Go à 1 MB
journal des transactions DB Shrink to min size :
- 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 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