我正在使用SQL Express 2005,并在每晚备份所有数据库。我发现一个数据库越来越大。我查看了这个数据库,但不知道为什么它变得如此庞大!我想知道是否与日志文件有关?
寻求如何找出原因和优化/减小该数据库大小的技巧。
我正在使用SQL Express 2005,并在每晚备份所有数据库。我发现一个数据库越来越大。我查看了这个数据库,但不知道为什么它变得如此庞大!我想知道是否与日志文件有关?
寻求如何找出原因和优化/减小该数据库大小的技巧。
需要检查以下几个方面:
你的数据库是否处于"Simple"恢复模式?如果是,它会产生更少的事务日志条目,备份文件会更小。建议在开发环境中使用 - 但不适用于生产环境。
如果它处于"FULL"恢复模式 - 你是否定期进行事务日志备份?这应该限制事务日志的增长,从而减少整体备份大小。
最近是否对其运行过DBCC SHRINKDATABASE(yourdatabasename)
操作?这可能会有所帮助。
你的数据库中是否有任何只是随着时间不断填充的日志/记录表?你能否删除其中一些条目?
你可以通过进入对象资源管理器,在你的数据库上右键单击,选择“属性”,然后在对话框中选择“选项”选项卡,找到数据库的恢复模式:
Marc
如果备份文件不断增长而且无法停止,我也遇到过这个问题。当然,这并不是一个“问题”,它是按设计实现的——你只是在创建一个备份“集”,直到占用所有可用空间。
为了避免这种情况,你需要更改覆盖选项。在SQL管理工作室中,右键单击你的数据库,选择“任务”-“备份”,然后在备份窗口中,你将看到默认显示的是“常规”选项卡。将其更改为“选项”选项卡,你将看到另一组选项。
顶部默认选项是“追加到现有介质集”。这就是导致备份文件大小不断增长的原因。将其更改为“覆盖所有现有备份集”,那么备份文件的大小将始终等于最新的整个备份文件。
(如果你有一个SQL脚本来执行备份操作,需要将“NOINIT”更改为“INIT”)
注意:这意味着备份文件只包含最新的更改内容——如果你三天前犯了一个错误,但你只有昨晚的备份文件,那么你就无法恢复。只有在你有一个备份策略将你的.bak文件每日复制到另一个位置的情况下,才应该使用这种方法,这样你就可以回到前几天的任何备份文件。
看起来您正在使用完整恢复模式,由于没有进行事务日志备份,导致事务日志不断增长。
为了纠正这个问题,您需要:
我建议阅读以下微软参考文献,以确保您正确管理数据库环境。
如果你每天都进行全备份数据库,那么随着时间推移,它肯定会变得越来越大。因此,你需要为自己制定计划:
第1天:完全备份
第2天:差异备份
第3天:差异备份
第4天:差异备份
第5天:差异备份
然后重新开始。
当你恢复数据库时,如果要还原完全备份,你可以轻松地完成这个操作。但是,当你需要还原差异版本时,你需要在 " NO-recovery " 的情况下备份前面的第一次完全备份,然后备份你需要的差异备份,以便安全地恢复数据。
使用7zip对备份文件进行归档。我最近将一个数据库备份到了一个178MB的.bak文件中。将其归档为.7z文件后,大小仅为16MB。 http://www.7-zip.org/
如果您需要一个比7zip更高效、更快速地处理大文件的存档工具,我建议您看看LZ4存档。我已经用它来备份文件多年了,没有任何问题: http://lz4.github.io/lz4/
保持数据库小的一个技巧是在设计时使用尽可能小的数据类型。
例如,您可能有一个状态表,当一个 smallint 或 tinyint 可以胜任时,您真的需要将索引设置为 int 吗?
Darknight