我有一个小的SQL Server 2005数据库。我每天备份（自动），.bak文件的大小通常为400MB，每天增长5MB（与其用法一致）。
昨晚，备份文件的大小跃升至1GB。怀疑有人试图用垃圾数据填充数据库，我运行了一份报告（Reports -> Standard Reports -> Disk User By Top Tables），总大小约为400MB。
然后想到自动备份过程可能出现问题，我立即再次进行备份，但.bak文件超过1GB。在昨天进行此自动备份之前，对索引进行碎片整理的自动化任务也已运行。但是，所有这几个月，这个索引优化之后的备份用于实际减少.bak文件的大小。
我试图在一夜之间找到这个大幅跳跃的解释，以及为什么.bak文件的大小是实际数据库磁盘使用量的两倍多？
更新：我跑了
DBCC SHRINKDATABASE(mydb)
删除事务日志。然后再次进行备份。 .bak文件的大小比上次更大。
这是我跑的查询：
DBCC SHRINKFILE(mydb_log, 1)
BACKUP LOG mydbWITH TRUNCATE_ONLY
DBCC SHRINKFILE(mydb_log, 1)
答案 0 :(得分：0)
1 - 您如何备份数据？维修计划？
2 - 如果要附加到同一个数据库备份文件，备份将会增长！
查看文件的内容。
RESTORE FILELISTONLY FROM AdventureWorksBackups WITH FILE=1;
http://technet.microsoft.com/en-us/library/ms173778.aspx
这假设您有一个名为AdventureWorksBackups的转储设备。您也可以将其更改为DISK ='AdventureWorks.bak'。
3 - 此外，维护计划在确定何时重新组织/更新统计数据与重建索引方面做得不好。
4 - 查看ola hallengren脚本。他们的方式更好！
首先，他们为您创建一个目录结构。
c:\backup\<server name>\<database name>\full
c:\backup\<server name>\<database name>\diff
c:\backup\<server name>\<database name>\log
其次，每个备份都有一个日期时间戳。没有附加到备份文件。
第三，他们通过传递小时数来保持联机清理。
第四，他们更好地处理索引碎片 - 5-30 =重新组织或30+ =重建。
我通常为我的数据库设置以下内容。
1 - 系统数据库 - 每晚完整备份，每小时记录一次备份。
2 - 用户数据库 - 完整备份1 x周，差异备份x 6天，每小时备份一次
最后但同样重要的是，SQL Server 2005没有对压缩备份的本机支持。这并不意味着您之后无法运行批处理文件来压缩它们。
QUEST（DELL）和RED GATE等第三方工具用于支持自己的备份实用程序。主要原因是填补这一空白。自SQL Server 2008以来，压缩备份可用。我认为许多供应商正在摆脱这种实用程序，因为它现在已成为标准。