当恢复数据不重要时，事务日志备份

我们有一个数据库，其中包含配置数据。当应用程序针对它运行时，它们基本上会执行大量计算，然后将一些数据写入文件。与普通安装不同，我们并不需要事务日志。我的意思是，我们可以对数据库进行备份并使用它，而无需将事务日志应用到数据库以使其保持最新状态。当恢复数据不重要时，事务日志备份

既然事务日志对我们来说并不重要，那么最好的备份策略应该是什么？目前，事务日志非常庞大（10 GB，其中数据库大约为50 MB，这是几个月的时间）。

我们可以对数据库进行初始备份，然后每隔几天或更少时间备份事务日志，覆盖当前的日志吗？或者我们可以一起删除交易日志并开始新的交易日志？ JDD。

JD。

来源

2009-08-01 JD.

确保数据库在简单恢复模式中运行。

这样做会否定您需要执行事务日志备份。此恢复模型自动确保事务日志的非活动部分可立即变为可重用状态。

不再关注事务日志管理，您可以将注意力集中在备份策略上。

每周完整的数据库备份可能具有每日差异备份，可能适合您的要求。

Recovery Model Overview

来源

2009-08-01 14:52:27

谢谢。简单来说，Simple就是要走的路。但是，我们将数据写入数据库，但可以从备份的数据库中计算此数据（链接提到Simple适用于数据库中数据不会更改的情况）。当我们改变配置数据时，我们只需要完整的数据库备份即可。我们是否可以自动执行此操作，并且是否需要执行其他任何操作，例如缩小事务日志？ JD。 JD。 – 2009-08-01 19:38:54

只是做了一些更多的阅读。 SQL服务器实例的恢复间隔为0分钟。据我所知，自动检查点发生，这意味着事务日志被截断（释放空间以供重用）。它是否正确？如果是这样，那么我真的不需要运行任何脚本（只需要一个完整的数据库备份）。 – 2009-08-01 19:53:03

@JD：使用简单恢复模型意味着您无法在需要时将数据库恢复到特定时间点（因为这需要事务日志备份）。提供时间点恢复不是必需的，也许数据是相对静态的，或者可以通过另一种方式恢复。您可以通过重新导入数据馈送来恢复完整的数据库备份或恢复数据，然后简单恢复模式将满足您的需求。您也正确，因为简单恢复模型自动为您管理事务日志文件的截断。 – 2009-08-01 22:37:30

据我了解，你不要将任何数据写入到数据库。因此，最适合您的备份策略是： 1.使用DBCC SHRINKFILE将恢复模式更改为简单并缩小事务日志。 2.对数据库进行一次完整备份。

来源

2009-08-01 14:54:52

谢谢HawX。你的回复有帮助。 – 2009-08-02 15:59:42

当恢复数据不重要时，事务日志备份

回答

相关问题