我有一个繁忙的数据库，多年来一直很忙，我看到每天大约有几 GB 的事务日志大小。
在过去的几周中，该事务日志大小已增加到每 6 小时 40-50 GB。这对我的备份产生了很大的影响，并且磁盘上的大小令人担忧。
我每隔一天进行一次完整备份，每 6 小时备份一次日志。
日志备份按预期减少了事务日志使用的大小，但它又迅速开始增加。
我怎样才能发现是什么导致了交易中相对突然的交易增加？
- 我的开发人员在过去几周可能会影响的更改方面处于空白状态
- 没有长时间运行的进程
- 没有计划的作业来执行索引操作
- Redgate 监控没有显示任何过度写入
我该如何进一步调查？
我建议启用查询存储。开始收集数据后，您可以使用 GUI 或编写针对sys.query_store_runtime_stats的查询来查找 Log usage heavy 查询。
图形用户界面
在对象资源管理器中打开数据库，选择Top Resource Consuming Queries
在右上角，选择配置以选择您感兴趣的指标
现在我可以看到哪个查询使用日志最多
详细信息（不在屏幕截图上）显示了计划、声明等。
以防您仍然无法识别查询。我会访问查询存储 DMV 并尝试找到query_hash以用作扩展事件会话的搜索过滤器。
鉴于您没有计划的作业来执行索引操作，并且没有长时间运行的进程/事务 - 您可以检查的下一件事是一些逻辑写入，以及正在执行这些写入的查询。
可以通过以下方式完成：
在 Redgate Monitor - 选择“Totals”，按“Logical Writes”的总数对查询进行排序。查看对相关数据库中的表进行写入的查询。
获取 sp_BlitzCache。跑
exec sp_BlitzCache @SortOrder = 'Writes'使用 SQL Server 审计功能，创建一个审计来记录针对该数据库的 INSERT UPDATE 和 DELETE 操作。可能在其中添加 BULK INSERT 和 CREATE TABLE。查看这些查询
扩展活动
如果您发现任何查询对该数据库中的表执行过多写入（1 次逻辑写入 = 8 KB 写入数据），请查看如何减少逻辑写入次数。如果这在你的情况下是可能的，当然
此外，好的做法是定期监控下一个指标
这样你就会知道你的基线是什么，以及你的工作量何时发生显着变化