下图来自一个监控工具。显示的指标是过去 7 天 SQL Server 2016 的“已用日志空间”。
我正在寻求帮助以了解这里发生的事情。
我所知道的是 IT 部门正在使用第 3 方工具 (Veeam) 定期“备份”。我被建议每晚执行一次完整备份,每 15 分钟执行一次日志备份(但我不确定这些是数据库文件的磁盘映像备份还是 Veeam 向 SQLServer 发出的执行备份的命令)。其中一个步骤包括 SQL Server 的“处理日志”,我相信其中一个步骤是截断日志。
我知道截断日志意味着将日志文件中可以重复使用的那些部分标记为不活动。目前,我理解(正确或错误)如果 SQL Server 知道日志文件部分已写入磁盘(即通过备份),则可能会重新使用它。
我在这张图表中看到的是
- 最左边的一个数据库的日志文件使用率异常高 - 忽略它。
- 每天增长然后每天清除每个日志文件(3 个驼峰)。
- 增长超过 3 天(周五、周六、周日),然后截断。
我在这里的解释是必须进行日志备份,否则使用率不会回落到接近零。
我怀疑日志备份每天只发生一次——尽管我认为这张图表不能证明这一点。例如,有可能在工作时间有更频繁的日志备份,但由于长时间运行的事务,此时不会发生截断。然而,在 Veeam 的夜间备份中,截断命令发出并成功。尽管存在这种可能性,但我仍然认为 Veeam 每天只执行一次日志备份的可能性更大。
这里的部分问题是 Veeam 对我来说有点像黑盒子——我不确定 IT 是如何配置它的。我也不清楚它是在拍摄硬盘(即数据库文件)的快照图像,还是指示SQLServer 执行备份。
我的目标是确保我们经常进行日志文件备份(并制定一个良好的频率)以支持基本上所有这些数据库的完整恢复模型。如果我确定目前我们进行日志备份的频率不超过每晚一次,那么我还需要确保如果我采取措施进行频繁的日志备份,我不会与 Veeam 竞争,以至于 Veeam 和任何计划任务在SQLServer 不会破坏彼此的日志链 - 任何有关如何检查和计划这些事情的建议将不胜感激。
您可以使用标准报告检查备份历史记录:
... 通过使用一些脚本: 检索 SQL Server 数据库备份历史记录且无备份的脚本
...或查看服务器的 ERRORLOG 文件并搜索 Source = Backup