1. 首页
  2. 问答
  3. 即使在备份之后，为什么我无法收缩事务日志文件？

即使在备份之后，为什么我无法收缩事务日志文件？

2009-04-22 31 views
24

我有一个拥有28gig事务日志文件的数据库。恢复模式很简单。我只是把数据库的完整备份，然后跑了两个：即使在备份之后，为什么我无法收缩事务日志文件？

backup log dbmcms with truncate_only

DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)

数据库的名称是db_mcms和事务日志文件的名称是Wxlog0。

也没有帮助。我不确定接下来要做什么。

来源

2009-04-22 Jordan Hudson

+0

无法运行上面的第一个命令，因为我的数据库处于完全恢复模式（尽管我认为它很简单）。我们的结果定期将数据库从生产恢复到质量保证并且无法将恢复模式更改为简单。 – dudeNumber4 2015-01-14 14:04:53

回答

42

谢谢大家回答。

我们终于找到了问题。在sys.databases中，log_reuse_wait_desc等于'replication'。显然，这意味着SQL Server在等待复制任务完成之前可以重用日志空间。

复制 从来没有在这个数据库上使用过，或者这个服务器 曾经在这个数据库上玩过。我们通过运行sp_removedbreplication来清除不正确的状态。在我们运行这个之后，备份日志和dbcc shrinkfile工作得很好。

绝对是一个用来装袋的技巧。

来源：

http://social.technet.microsoft.com/Forums/pt-BR/sqlreplication/thread/34ab68ad-706d-43c4-8def-38c09e3bfc3b

http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705

来源

2009-04-23 17:08:03

+3

我搜索了很长时间才找到你的文章，这正是我的情况，我曾经启用然后禁用数据库镜像。这显然是一个神器。谢谢！ – smoore4 2013-08-25 16:25:50

+1

感谢你！解决了我的问题吧！ – sys49152 2014-05-31 12:57:05

0

你是否从SQL Server管理工作室内用GUI进行过尝试。右键单击数据库，任务，缩小，文件。选择filetype = Log。

我一个星期前为我工作。

来源

2009-04-22 20:51:18 asgerhallas

+0

没有骰子。奇怪的是，它告诉我文件中可用的空闲空间是负数7gigs。 在这个数据库似乎有东西被捣毁，我不知道它是什么。 :( – 2009-04-22 20:53:18

0

尝试后你创建另一个完全备份的备份日志W/TRUNCATE_ONLY（IIRC你应该这样做无论如何要保持日志链）。在简单恢复模式下，您的日志不应该增长太多，因为它在每次事务之后都会被截断。然后尝试指定希望日志文件的大小，例如

-- shrink log file to c. 1 GB 
DBCC SHRINKFILE (Wxlog0, 1000);

的TRUNCATEONLY选项不会重新排列日志文件中的页面，所以你可能在你的文件的“结束”，这可以防止它被缩小有一个活动页面。

您还可以使用DBCC SQLPERF（LOGSPACE）来确保日志文件中有真正的空间被释放。

来源

2009-04-22 21:18:25 Matt

0

将数据库恢复为完整模式，运行事务日志备份（而不仅仅是完整备份），然后收缩。

收缩后，您可以将数据库恢复到简单模式，并且它的日志记录将保持相同的大小。

来源

2009-04-22 21:29:01 Guy

0

您不能缩小比最初创建的大小更小的事务日志。

来源

2009-04-22 21:34:12

1

如果您在2005年对数据库设置了恢复模式（不知道2005年之前的版本），它会将日志文件放在一起，然后您可以将其恢复为完全恢复模式以重新启动/重新创建日志文件。我们用SQL 2005 express来解决这个问题，因为在改变恢复模式之前，我们无法接近数据的4GB限制。

来源

2009-04-22 21:43:29 MikeJ

27

如果您的数据库设置为自动增长日志&，那么最终会出现大量虚拟日志文件，您可能会遇到此问题。
运行DBCC LOGINFO('databasename') &看看最后一个条目，如果这是2，那么你的日志文件将不会缩小。与数据文件不同，虚拟日志文件不能在日志文件中移动。

您需要多次运行BACKUP LOG和DBCC SHRINKFILE才能使日志文件收缩。

对于日志&之间运行DBBC LOGINFO额外奖励积分推卸

来源

2009-04-23 00:04:07

+5

感谢这个，它解决了我的问题。在http://technet.microsoft.com/en-us/library/ms178037%28v=sql.105%29更多的技术细节。 aspx和http://technet.microsoft.com/en-us/library/ms345414%28v=sql.105%29.aspx。 – jeffcook2150 2012-08-21 05:46:37

2

我有同样的问题，在过去。通常需要多次执行收缩和trn备份。在极端情况下，我将数据库设置为“简单”恢复，然后在日志文件上执行收缩操作。这对我来说总是有效的。但是最近我遇到了一个不行的情况。这个问题是由于长时间运行的查询没有完成，所以任何缩小的尝试都是无用的，直到我可以杀死该进程然后运行我的缩小操作。我们正在谈论的日志文件增长到60 GB，现在缩小到500 MB。

请记住，只要您从FULL更改为简单恢复模式并进行缩小，请不要忘记将其设置回FULL。然后立即执行完整的数据库备份。

来源

2010-06-02 01:50:46 Brent

3

'sp_removedbreplication'没有解决我的问题，因为SQL刚刚返回，说数据库不是复制的一部分......

，我发现我的答案在这里：

基本上我不得不创建一个复制，所有复制指针复位至零;然后删除我刚刚创建的复制。 即

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

来源

2011-07-06 04:03:05 MrEs

3

这个答案已经从here抬起，并张贴在这里的情况下，其他线程被删除：

你有非分布式日志中LSN是问题的事实。 我已经看到这一次之前不知道为什么我们不会取消 事务复制。我们将在内部进行调查。您可以 执行以下命令取消标记事务， 复制

EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1

此时，你应该能够截断日志。

来源

2013-01-22 07:39:37 Legend

0

我试着列出的所有解决方案，并没有一次成功。我最终不得不做一个sp_detach_db，然后删除ldf文件并重新附加数据库，迫使它创建一个新的ldf文件。这工作。

来源

2014-03-06 01:32:10 user3386130

1

我知道这是一个几年的历史，但想补充一些信息。

我发现在非常大的日志中，特别是当数据库未设置为备份事务日志（日志非常大）时，日志的第一次备份不会将log_reuse_wait_desc设置为无，而是将状态保留为备份状态。这将阻止收缩。第二次运行备份正确地将log_reuse_wait_desc重置为NOTHING，允许收缩进行处理。

来源

2015-02-20 20:37:28 Russ

相关问题

 相关问题