Question

我有一个拥有28gig事务日志文件的数据库。恢复模式很简单。我刚刚对数据库进行了完整备份，然后运行了两个：

backup log dbmcms with truncate_only

DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)

db的名称是db_mcms，事务日志文件的名称是Wxlog0。

两者都没有帮助。我不知道下一步该做什么。

Answer 1

感谢大家的回答。

我们终于找到了这个问题。在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

Answer 2

如果您的数据库设置为自动增长日志和放大器，则可能会遇到此问题。你最终得到了很多虚拟日志文件运行DBCC LOGINFO('databasename')＆amp;查看最后一个条目，如果这是2，则您的日志文件不会缩小。与数据文件不同，虚拟日志文件无法在日志文件中移动。

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

对于额外的奖励积分，在日志和日期之间运行DBBC LOGINFO。推卸

Answer 3

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

我在这里找到了答案：

基本上我必须创建一个复制，将所有复制指针重置为Zero;然后删除我刚刚制作的复制。即。

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

Answer 4

你不需要这个

DBCC SHRINKFILE ('Wxlog0', 0)

请确保您了解危险：请参阅此处：Do not truncate your ldf files!

这里Backup Log with Truncate_Only: Like a Bear Trap

Answer 5

此答案已从here解除，并在此处发布以防其他线程被删除：

您在日志中有非分布式LSN这一事实是个问题。我曾经看过这一次，但不确定为什么我们不会取消标记交易重复。我们将在内部进行调查。您可以执行以下命令将事务取消标记为复制

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

此时您应该能够截断日志。

Answer 6

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

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

Answer 7

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

Answer 8

我知道这已经有几年了，但是想添加一些信息。

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

Answer 9

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

我一周前为我工作过。

Answer 10

尝试在DBCC中使用需要TRUNCATEONLY的目标大小：

DBCC SHRINKFILE（'Wxlog0'，1）

并查看文章：

http://msdn.microsoft.com/en-us/library/ms189493(SQL.90).aspx

http://support.microsoft.com/kb/907511

编辑：

您可以尝试首先使用

将已分配的页面移动到日志文件的开头

DBCC SHRINKFILE（'Wxlog0'，NOTRUNCATE）

之后

DBCC SHRINKFILE（'Wxlog0'，1）

Answer 11

在备份日志w / truncate_only之后尝试创建另一个完整备份（IIRC你应该这样做以保持日志链）。在简单恢复模式下，您的日志不应该增长太多，因为它在每次事务后都会被有效地截断。然后尝试指定日志文件所需的大小，例如

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

TRUNCATEONLY选项不会重新排列日志文件中的页面，因此您可能在文件的“结尾”有一个活动页面，这可能会阻止它缩小。

您还可以使用DBCC SQLPERF（LOGSPACE）来确保要释放的日志文件中确实存在空间。

Answer 12

将数据库重新置于完全模式，运行事务日志备份（不仅仅是完整备份），然后进行收缩。

缩小后，你可以将数据库恢复到简单模式，并且txn log将保持相同的大小。

Answer 13

您无法缩小小于其最初创建的大小的事务日志。

Answer 14

我尝试了列出的所有解决方案，但没有一个有效。我最终不得不做一个sp_detach_db，然后删除ldf文件并重新附加数据库，强制它创建一个新的ldf文件。这很有用。

Answer 15

我遇到了同样的问题。我运行了索引碎片整理过程，但事务日志已满，并且碎片整理过程出错了。事务日志仍然很大。

我备份了事务日志，然后继续收缩事务日志.ldf文件。但是，事务日志根本没有缩小。

然后我发出了一个“CHECKPOINT”，然后是“DBCC DROPCLEANBUFFER”，之后能够缩小事务日志.ldf文件

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

15 个答案: