我有一个数据库，该数据库具有350 MB数据文件（.mdf）和4.9 GB日志文件（.ldf）。恢复模型设置为FULL。
当我尝试收缩日志文件时，它没有收缩。
我知道收缩数据库是不好的，不应该这样做。但是我仍然在尝试缩小日志文件。
我跑的时候
DBCC SQLPerf(logspace) 我发现日志大小为4932 MB，使用的日志空间为98.76％！
然后我尝试了这个命令
USE <databasename>;
DBCC loginfo;
现在几乎所有的VLF均为“状态2”，这意味着所有VLF都在使用中。
我尝试进行日志备份，然后缩小日志文件。缩小并没有减小尺寸。
我将恢复模型更改为SIMPLE并尝试再次缩小，但这也无济于事。
我检查了未结交易
DBCC opentran (database);并发现现在没有任何交易打开。
是什么阻止了我缩小日志文件？我该如何解决？
Answers:
这是我自己的问题的答案。
运行以下查询以获取有关日志文件的重用等待的信息：
SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DBName'
我得到以下输出：
log_reuse_wait_desc
-------------------
REPLICATION
即使删除复制后，数据库中仍保留一些与复制相关的对象。
要从数据库中删除复制，sp_removedbreplication可以使用。但这对我们不起作用，因为当时复制并不活跃，实际上复制早已被删除了。
解决方案是使用SQL Server的import选项将数据库内容导入到另一个数据库。
缩小日志的步骤将是
通过SSMS或T-SQL备份事务日志，然后执行收缩
如果右键单击数据库名称，则SSMS命令位于任务下方
BACKUP LOG <Databasename> TO DISK N'<path\database_log.ldf';
GO
DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS您可能需要多次这样做
如果有事务或作业阻止了该操作，请使用“活动”监视器来识别该进程并将其终止，或者使用“ SQL Agent”作业活动监视器来结束该作业。
阅读如何缩小SQL Server日志以获取解释，说明日志的循环性质如何防止截断后的缩小。您可能会将最后一个LSN点记录到位于LDF尾部的VLF中。从直觉上来说，您必须通过生成日志写入来推进日志以使其收缩。
您需要首先创建一个备份，具体取决于为数据库设置的备份模型，然后才能收缩数据库。
您可以尝试运行以下命令：
USE <databasename>
GO
BACKUP DATABASE <databasename> TO DISK '<absolute path goes here>\<databasename>.bak';
GO或者，您可以从SSMS进行操作并使用可用的图形工具（有关详细信息，请参见此处：http : //msdn.microsoft.com/zh-cn/library/ms187510.aspx）
备份数据库后，即可对其进行压缩。但是，缩小数据库不是一个好主意，因为索引碎片过多会占满，并且搜索数据会变慢。
希望这可以帮助。
我发现我必须对数据库和事务日志都执行2或3个备份，以使事务日志实际减小大小。我有一个使用完全恢复模型创建的数据库。每天晚上它都会执行数据库和事务日志的备份，但是不可避免地，事务日志似乎会在2-3周内持续增长。当剩余磁盘空间达到1GB时，我将看到事务日志约为30GB。我遵循了Microsoft建议的步骤，并且在备份数据库和事务日志的第4或第5次迭代之后，事务日志最终将释放其额外的空间并缩小。然后，我返回并删除已创建的多个备份。
对于阻止收缩日志文件的复制，我的解决方法是：
就我而言，它奏效了。进入数据库后，将自动创建日志，日志大小为512kb，而不是70GB。但这只是一种解决方法。根本问题没有解决。就我而言，我们正在使用复制。
log_reuse_wait_desc给了ACTIVE_TRANSACTION。交易一旦完成，收缩就可以了。