我正在处理别人的备份维护计划，并且存在日志文件问题，我有一个数据库位于一个驱动器上，大小为31 GB，日志文件坐在另一台大小为20 GB的服务器上，数据库处于完全恢复模式。有一个维护计划，每天运行一次以执行完整备份，第二个计划每15分钟备份一次日志文件。我已经检查过日志文件备份到的驱动器，并且仍然有充足的空间，但备份后日志文件永远不会变小，维护计划中是否存在某些缺失？SQL日志文件在SQL Server 2012中不收缩
在此先感谢
你描述的情况似乎很好。
事务日志备份确实不是收缩日志文件。然而，它确实截断日志，文件，这意味着空间可重复使用：
从联机丛书（Transaction Log Truncation）：
日志截断自动的逻辑日志被释放的空间复用 事务日志。
另外，从Managing the Transaction Log：
日志截断，这是简单的恢复模式下自动的，是 必须保持日志被填满。截断过程通过将不包含逻辑日志的任何部分的虚拟 日志文件标记为非活动来减少逻辑日志文件的大小。
这意味着每次事务日志备份发生在您的方案中时，它都会在该文件中创建可供后续事务处理使用的可用空间。
由此引出，你是否应该缩小文件？一般来说，答案是否定的。假设您的数据库不会突然出现大规模的一次性使用高峰，事务日志将增长到适合典型工作负载的大小。
这意味着，如果你启动日志萎缩，SQL Server将只需要再次增长这...这是一个资源密集型操作，影响服务器的性能，并且在日志增长没有交易就可以完成。
当前的计划和文件大小对我来说都是合理的。
我不知道这是否适用于你的情况，但早期版本的SQL Server 2012时，有模型设置为简单恢复模式，庄稼了一个错误。对于将模型设置为Simple的任何数据库，日志文件将继续增长以尝试达到2,097,152 MB的限制。如果您在之后更改为“完整”，这仍然适用。知识库文章2830400指出，改为Full，然后改回Simple是一种解决方法 - 这不是我的经验。为SP1运行CU 7是我工作的唯一技巧。
本文提供解决此错误的第一次更新的链接：“SQL Server 2012 SP1的累积更新4”以及“SQL Server 2012的累积更新7”（如果尚未安装SP1） 。
这不适用于海报的问题。他从不提及他使用简单恢复模型的任何地方。事实上他说他正在使用完全恢复模式。 –
我应该写一个更具描述性的文章。如果数据库最初是在简单恢复模型中创建的，并且后来更改为FULL，则它适用。这是一个讨厌的错误。 –
请编辑您的文章并添加相关信息。这将有所帮助，因为它不需要每个人都阅读整个知识库文章并找出相关的内容。 –
如果您将恢复更改为完整，然后恢复为简单，则缩小将成功工作。
错误 - 你改变为简单，然后回到完整。 http://technet.microsoft.com/en-us/library/ms189493.aspx – cdonner
嗨伊恩，再次感谢一个非常深入的答案，非常感谢。我想知道这个大小的原因是，我被告知这个日志文件以前只有几百兆，而在那个时候，这个日志文件与数据库的大小不成正比。由于它现在是事务复制的一部分，它的尺寸是否可以从原来的大小上增加？ – PJD
由于事务复制确实依赖于事务日志，因此在复制完成并且不再需要之前，数据不能在日志中被截断。所以从这个意义上说它会有效果，但显然很难根据一些一般信息来量化事物！也就是说，我只会担心日志是否继续与工作量的增长不成比例地增长;这可能需要进一步调查。 –