今天我收到一封电子邮件，说我们有一个日志文件已经增长到 278GB，并询问是否有人在维护它。我已经知道答案是否定的，因为我们没有 dba（除了我自己。我对 sql 了解很多，但我是一名开发人员）。
我们的数据库相当大；有些表有数亿条记录。但这对日志文件来说似乎太大了，我希望得到一些指导，弄清楚这是否不正常，我们是否可以配置更好的东西，或者最好的解决方案是否只是接受我们需要为这头野兽提供更多的硬盘空间。
如果我可以在这里发布更多信息以帮助我得到更好的答案，请告诉我。
答案1
听起来好像数据库设置为完整恢复模式，并且没有运行事务日志备份。这是一个非常常见的问题。
如果您不想进行时间点还原、日志传送或任何类似操作，而只想恢复到上次完整备份完成的时间点，请将数据库设置为简单恢复模式，并将日志文件缩小到合理的大小。
如果您正在进行日志备份，请确保它们运行时没有错误，并考虑增加其频率。
也有可能某些事务在几小时/几天/几周/几个月前启动了事务但从未提交。日志的活动部分不能被截断，并且这些部分在事务提交或回滚之前不会变为非活动状态。使用 DBCC OPENTRAN（MSDN 当前已关闭，因此我现在无法提供链接）来排除故障，它将向您显示有关数据库中运行时间最长的事务的信息。如果您发现有一个长期运行的事务，则可能很难让应用程序提交。当然，您可以终止该连接，但您将丢失它在那几小时/几天/几周/几个月内所做的任何数据库修改。您可能需要在应用程序中的某个地方修复一些代码。
再次强调，解决问题后，您需要将日志文件缩小到合理的大小。您可以使用性能监视器查看一段时间内实际使用的空间量。作为一个完全随机的数字，我的目标是将日志文件的大小设为最大表的 1.25 倍（以 GB 为单位，而不是以行为单位），并将文件配置为增大。
答案2
听起来你没有进行任何日志备份。日志备份会截断日志文件，因此如果日志文件增长失控，则好像没有运行日志备份。
编辑我的备份类型错误，感谢 Darin 的纠正。