我今天收到一封电子邮件，指出我们有一个长达278GB的日志文件，询问是否有人维护它。 我已经知道答案是否定的，因为我们没有dba（除了我自己，我对sql有相当的了解，但我是一名开发人员）。
我们的数据库比较大， 一些表有100多万条logging。 对于日志文件来说这似乎相当大，我想要找出一些方向来确定这是否是exception的，我们是否可以configuration更好的东西，或者最好的解决scheme是简单地接受我们需要喂养的野兽更高清的空间。
如果有更多的信息，我可以在这里张贴，这将有助于让我更好的答案，请让我知道什么。
这听起来像数据库设置为完整恢复模式，没有事务日志备份正在运行。 这是一个非常普遍的问题。
如果您不想执行时间点恢复，logging运输或其他任何事情，并且您只需要恢复到最后一次完整备份完成的时间，就可以将数据库设置为SIMPLE恢复模式，收缩你的日志文件到一个健全的。
如果您正在执行日志备份，请确保它们正常运行，并考虑增加其频率。
也有可能是某个交易开始了一个交易时间/几天/几周/几个月，而从未承诺过。 日志的活动部分不能被截断，这些部分在事务提交或回滚之前不会变为非活动状态。 使用DBCC OPENTRAN（MSDN当前正在closures，所以我现在无法提供链接）来排除故障，它会向您显示有关数据库中最长时间运行的事务的信息。 如果你发现你有一个长期运行的事务，你可能很难让应用程序提交。 当然，你可以杀死这个连接，但是你将失去它在这些小时/天/周/月所做的任何数据库修改。 您可能需要修复应用程序中的某些代码。
同样，在你解决了这个问题之后，你会想把你的日志文件缩小到理智的程度。 您可以使用性能监视器查看随着时间的推移实际使用了多less空间。 作为一个完整的拍摄屁股的数字，我的目标是为您的最大表格的1.25倍（以GB测量，而不是行）的大小，并保持configuration文件的增长。
这听起来像你没有采取任何日志备份。 日志备份会截断日志文件，因此，如果日志文件失去控制，似乎还没有运行日志备份。
编辑我有错误的备份types，纠正得益于达林。