有人发布了更新声明，作为一些维护的一部分，在两个表中进行了交叉联接更新，每个表中有200,000条logging。 这就是40万亿的陈述，这将解释日志增长到200GB的一部分。 我也没有日志文件上限，这是另一个问题，我将照顾服务器范围内 – 我们有近200个数据库驻留。
我使用的“解决scheme”是备份数据库，用truncate_only备份日志，然后再次备份数据库。 然后我缩小了日志文件并在日志上设置了一个上限。
看到有其他数据库使用日志驱动器，我有点急于清理。 我可能已经能够将日志文件备份到我们的备份驱动器，希望没有其他数据库需要增长他们的日志文件。
Paul Randal，来自http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx
在任何情况下，您都不应该删除事务日志，尝试使用未logging的命令重build它，或者使用BACKUP LOG（已在SQL Server 2008中删除）的NO_LOG或TRUNCATE_ONLY选项将其截断。 这些选项将导致事务性不一致（并且可能会损坏）或者删除能够正确恢复数据库的可能性。
有没有其他的select，我不知道？
您可以将数据库放入简单恢复模型（然后使用CHECKPOINT命令确保日志尽可能被截断），然后返回到完全恢复模式。 然后进行完整的数据库备份，以便系统认识到它处于Full状态。
然后，您可以方便地缩小日志。 收缩日志并不像缩减数据库那样糟糕，你几乎不应该这样做。
你还没有删除日志，你只是截断它 – 这会杀死你的select恢复到一个时间点。 因此，请尽快对数据库进行完整备份。
另外请记住，如果您的日志不能增长，您的数据库将停止。 所以让autogrow离开并不是一个坏的select…但是也许设置它会在发送完成时向您发送一个警报。