有人在维护过程中触发了一条更新语句，该语句对两个表进行了交叉连接更新，每个表包含 200,000 条记录。这是 40 万亿条语句，这可以解释部分日志如何增长到 200GB。我也没有限制日志文件的大小，这是我将要处理的另一个问题，服务器范围内有近 200 个数据库。
我使用的“解决方案”是备份数据库，使用 truncate_only 备份日志，然后再次备份数据库。然后我缩小了日志文件并对日志设置了上限。
由于有其他数据库正在使用日志驱动器，所以我急于将其清理干净。我本可以将日志文件备份到我们的备份驱动器，希望没有其他数据库需要增大其日志文件。
Paul Randal 来自http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx
在任何情况下，您都不应删除事务日志、尝试使用未记录的命令重建它，或者简单地使用 BACKUP LOG 的 NO_LOG 或 TRUNCATE_ONLY 选项（已在 SQL Server 2008 中删除）截断它。这些选项要么会导致事务不一致（而且很可能是损坏），要么会消除正确恢复数据库的可能性。
还有其他我不知道的选项吗？
答案1
您可以将数据库置于简单恢复模式（然后使用 CHECKPOINT 命令确保日志尽可能被截断），然后再返回到完整恢复模式。然后进行完整数据库备份，以便系统意识到它处于完整状态。
然后，您可以根据需要缩小日志。缩小日志并不像缩小数据库那么糟糕，您几乎永远不应该这样做。
您并没有删除日志，您只是截断了它 - 这会让您无法恢复到某个时间点。因此，请尽快对数据库进行完整备份。
还要记住，如果您的日志无法增长，您的数据库将停止。因此，保留自动增长并不是一个坏选择……但也许可以将其设置为在日志填满时向您发送警报。