Pourquoi ne puis-je pas réduire un fichier journal des transactions, même après la sauvegarde?
J'ai une base de données qui a un fichier journal de transaction 28gig. Le mode de récupération est simple. Je viens de prendre une sauvegarde complète de la base de données, puis les deux:
backup log dbmcms with truncate_only
DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)
Le nom de la base de données est db_mcms et le nom du fichier du journal des transactions est Wxlog0.
Ni a aidé. Je ne sais pas quoi faire ensuite.
Merci à tous pour votre réponse.
Nous avons finalement trouvé le problème. Dans sys.databases, log_reuse_wait_desc était égal à "réplication". Apparemment, cela signifie que SQL Server attend la fin d'une tâche de réplication avant de pouvoir réutiliser l'espace du journal.
Réplication n'a jamais été utilisé sur cette base de données ou ce serveur a été joué avec il était une fois sur cette base. Nous avons effacé l'état incorrect en exécutant sp_removedbreplication. Une fois que nous avons exécuté cette opération, le journal de sauvegarde et dbcc shrinkfile fonctionnaient parfaitement.
Certainement un pour le sac à malice.
Sources:
http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705
Vous pouvez rencontrer ce problème si votre base de données est configurée pour parcourir automatiquement le journal et vous vous retrouvez avec de nombreux fichiers journaux virtuels.
Exécutez DBCC LOGINFO('databasename') & regardez la dernière entrée. S'il s'agit d'un 2, votre fichier journal ne sera pas réduit. Contrairement aux fichiers de données, les fichiers journaux virtuels ne peuvent pas être déplacés à l'intérieur du fichier journal.
Vous devrez exécuter BACKUP LOG et DBCC SHRINKFILE plusieurs fois pour que le fichier journal soit réduit.
Pour des points bonus supplémentaires, exécutez DBBC LOGINFO entre log & shirks
'sp_removedbreplication' n'a pas résolu le problème pour moi car SQL vient juste de revenir en disant que la base de données ne faisait pas partie d'une réplication ...
J'ai trouvé ma réponse ici:
- http://www.sql-server-performance.com/forum/threads/log-file-fails-to-truncate.25410/
- http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due- to-snapshot-replication.aspx
Fondamentalement, je devais créer une réplication, réinitialiser tous les pointeurs de réplication sur zéro; puis supprimez la réplication que je venais de faire… .. c'est-à-dire.
Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO
Tu n'as pas besoin de ça
DBCC SHRINKFILE ('Wxlog0', 0)
Assurez-vous simplement que vous êtes conscient des dangers: voir ici: Ne tronquez pas vos fichiers ldf!
Et ici Journal de sauvegarde avec Truncate_Only: comme un piège à ours
Cette réponse a été levée de ici et est publiée ici au cas où l'autre fil serait supprimé:
Le problème que vous avez avec le LSN non distribué dans le journal est le problème . J'ai déjà vu cela une fois auparavant, je ne sais pas trop pourquoi nous ne décomprimons pas le transaction telle que répliquée. Nous étudierons cela en interne. Vous peut exécuter la commande suivante pour désélectionner la transaction en tant que répliqué
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
À ce stade, vous devriez pouvoir tronquer le journal.
J'ai eu le même problème dans le passé. Normalement, une réduction et une sauvegarde Trn doivent se produire plusieurs fois. Dans les cas extrêmes, je règle la base de données sur "Simple" récupération, puis j'effectue une opération de réduction sur le fichier journal. Cela fonctionne toujours pour moi. Cependant, récemment, j'ai eu une situation où cela ne fonctionnerait pas. Le problème était dû à une requête longue qui ne fonctionnait pas. Toute tentative de réduction était donc inutile jusqu'à ce que je puisse arrêter ce processus, puis exécuter mes opérations de réduction. Nous parlons d'un fichier journal qui a augmenté de 60 Go et est maintenant réduit à 500 Mo.
Rappelez-vous, dès que vous passez du mode de récupération COMPLET au mode de récupération simple et que vous réduisez le nombre, n'oubliez pas de le réinitialiser sur COMPLET. Ensuite, vous devez immédiatement faire une sauvegarde complète de la base de données.
Je sais que cela fait quelques années, mais je voulais ajouter quelques informations.
J'ai trouvé des journaux très volumineux, en particulier lorsque la base de données n'était pas configurée pour sauvegarder les journaux des transactions (les journaux étaient très volumineux), la première sauvegarde des journaux ne mettrait pas log_reuse_wait_desc à rien, mais laisserait le statut en cours de sauvegarde. Cela bloquerait le psy. Si vous exécutez la sauvegarde une seconde fois, réinitialisez log_reuse_wait_desc sur NOTHING, ce qui permettra au retrait de fonctionner.
Si vous définissez le mode de récupération sur la base de données en 2005 (je ne sais pas pour les versions antérieures à 2005), le fichier journal est supprimé et vous pouvez le remettre en mode de récupération complète pour redémarrer/recréer le fichier journal. Nous avons rencontré ce problème avec SQL 2005 Express, car nous ne pouvions pas nous approcher de la limite de 4 Go avec des données tant que nous n'avions pas changé le mode de récupération.
Essayez de créer une autre sauvegarde complète après avoir sauvegardé le journal w/truncate_only (vous devez le faire de toute façon, comme indiqué par IIRC, afin de maintenir la chaîne de journaux). En mode de récupération simple, votre journal ne devrait pas grandir de toute façon car il est effectivement tronqué après chaque transaction. Essayez ensuite de spécifier la taille souhaitée du fichier journal, par exemple.
-- shrink log file to c. 1 GB
DBCC SHRINKFILE (Wxlog0, 1000);
L'option TRUNCATEONLY ne réorganise pas les pages dans le fichier journal. Vous pouvez donc avoir une page active à la "fin" de votre fichier, ce qui pourrait empêcher sa réduction.
Vous pouvez également utiliser DBCC SQLPERF (LOGSPACE) pour vous assurer qu'il y a vraiment de l'espace dans le fichier journal à libérer.
Remettez la base de données en mode complet, exécutez la sauvegarde du journal des transactions (pas seulement une sauvegarde complète), puis la réduction.
Une fois réduit, vous pouvez remettre la base de données en mode simple et conserver la même taille.
Vous ne pouvez pas réduire un journal de transactions plus petit que sa taille créée initialement.
Avez-vous essayé depuis le studio de gestion SQL Server avec l'interface graphique? Faites un clic droit sur la base de données, les tâches, la réduction, les fichiers. Sélectionnez filetype = Log.
J'ai travaillé pour moi il y a une semaine.
J'ai essayé toutes les solutions énumérées et aucune d'entre elles n'a fonctionné. J'ai fini par avoir à faire sp_detach_db, puis à supprimer le fichier ldf et à attacher à nouveau la base de données, ce qui l'a forcée à créer un nouveau fichier ldf. Ça a marché.
Essayez d’utiliser la taille de la cible dont vous avez besoin à partir de TRUNCATEONLY dans DBCC:
DBCC SHRINKFILE ('Wxlog0', 1)
Et vérifiez ceci aux articles:
http://msdn.Microsoft.com/en-us/library/ms189493(SQL.90).aspx
http://support.Microsoft.com/kb/907511
Modifier:
Vous pouvez essayer de déplacer d’abord les pages allouées au début du fichier journal avec
DBCC SHRINKFILE ('Wxlog0', NOTRUNCATE)
et après ça
DBCC SHRINKFILE ('Wxlog0', 1)
J'ai eu le même problème. J'ai exécuté un processus de défragmentation d'index, mais le journal des transactions est devenu saturé et le processus de défragmentation a été erroné. Le journal des transactions est resté volumineux.
J'ai sauvegardé le journal des transactions, puis j'ai réduit le fichier .ldf du journal des transactions. Cependant, le journal des transactions n'a pas diminué du tout.
J'ai alors émis un "CHECKPOINT" suivi de "DBCC DROPCLEANBUFFER" et j'ai pu ensuite réduire le fichier .ldf du journal des transactions.