我正在处理别人的备份维护计划,遇到了日志文件的问题。我的数据库存放在一个大小为31 GB的驱动器上,而日志文件则存放在另一个大小为20 GB的服务器上,该数据库采用完全恢复模型。有一个每天运行一次的维护计划,用于进行完整备份,还有一个每15分钟备份日志文件的计划。我已经检查了日志文件备份所在的驱动器,发现还有很多空间,但备份后日志文件的大小始终没有变小,是维护计划缺少了什么吗?谢谢。
您所描述的情况似乎很好。事务日志备份不会使日志文件缩小。但是,它确实截断了日志文件,这意味着可以重用空间:来自Books Online (Transaction Log Truncation):日志截断会自动释放逻辑日志中可供事务日志重用的空间。此外,从Managing the Transaction Log中也可以看到:简单恢复模式下,自动进行日志截断非常重要,以避免日志填满。截断过程通过将不包含任何逻辑日志部分的虚拟日志文件标记为非活动状态,从而减少逻辑日志文件的大小。这意味着在您的情况下,每次发生事务日志备份时,它都会在文件中创建可由后续事务使用的空闲空间。跟着这个问题,你应该也缩小文件吗?一般来说,答案是否定的。假设您的数据库没有突然出现大规模的使用峰值,事务日志将会增长到适合典型工作负载的大小。这意味着如果您开始收缩日志,SQL Server 将需要再次增长它... 这是一个消耗资源的操作,影响服务器性能,并且在日志增长时无法完成任何事务。当前计划和文件大小对我来说都很合理。
我不知道这是否适用于你的情况,但 SQL Server 2012 的早期版本存在一个 bug,当模型设置为简单恢复模式时会出现问题。对于使用简单模式创建的任何数据库,日志文件将继续增长,试图达到 2,097,152 MB 的限制。即使之后更改为完整模式仍然适用。KB 文章 2830400 指出,先更改为完整模式,然后再更改回简单模式是一种解决方法 - 但这并非我的经验。对我有效的唯一方法是运行 SP1 的 CU 7。该文章提供了解决此 bug 的第一个更新的链接:“SQL Server 2012 SP1 的累积更新 4”,以及(如果您尚未安装 SP1)“SQL Server 2012 的累积更新 7”。