小编Beo*_*e42的帖子

每天都会经历当天所有事务日志备份的总和约为 1GB，而在那周结束时，完整数据库备份约为 180MB。对于用于向供应商/客户购买/销售商品的商业数据库，与实际数据库的大小相比，一天的事务日志备份的总大小至少比我预期的大 10 倍。

如何找到哪些 sql 插入/更新/删除/等操作导致如此多/如此大的事务？我设想某个地方有一些错误的代码，它们会重写整个表只是为了更新/插入 1 行，或者一遍又一遍地更新相同的行。在检查所有数据库应用程序代码之前，我想知道什么是错误事务。

大多数问题，包括为什么事务日志不断增长或空间不足？和其他文章涉及的人的事务日志文件不断增长，通常是因为他们从不备份它。我的问题并非如此。我的事务日志文件的大小不再增加，我的问题是如何查找哪些事务导致每个备份的大小定期变大，而不是日志文件的大小。

我们有一个 MS SQL Server 2012 数据库

• 使用完全恢复模型
• 每周完整备份，周五晚上。(.bak)
• 每晚差异备份 (.dif)
• 每天 3 次事务日志备份 (.trn)（编辑：有人指出，为了更好的 RPO，应该更频繁地备份）
• 所有备份都使用压缩。
• DB仅在正常办公时间使用
• DB 有一个应用程序可以执行各种任务，包括一些计划任务

我意识到下面列出的实际大小在计划中并不大，因为该数据库只有几个月的历史，但如果随着数据库的增长这种趋势继续下去，我预计会在多个方面出现麻烦。以下是过去 2 周的备份文件大小。

14/11/2014 11:05 PM 200,873,984 Production_backup_2014_11_14_230500_8220928.trn
14/11/2014 11:18 PM 173,499,904 Production_backup_2014_11_14_231753_3214232.bak
15/11/2014 06:00 AM 321,033,728 Production_backup_2014_11_15_060001_9915061.trn
15/11/2014 10:00 AM 47,616 Production_backup_2014_11_15_100001_1784634.trn
15/11/2014 02:00 PM 59,392 Production_backup_2014_11_15_140001_0461018.trn
15/11/2014 06:00 PM 62,976 Production_backup_2014_11_15_180001_5854303.trn
15/11/2014 11:05 PM 71,506,432 Production_backup_2014_11_15_230501_3937283.dif
16/11/2014 06:00 AM 12,906,496 Production_backup_2014_11_16_060009_1822596.trn
2014 年 11 月 …