使用维护计划管理事务日志大小

Question

在Server 2008中是否有配置维护计划的最佳实践？目前，我正在删除大于40个小时的数据库备份和事务日志，然后备份它们。我看到的问题是，事务日志仍然非常大。是否应该包含“收缩数据库计划”任务？

Answer 1

如果您的日志文件越来越大，那么您至少做了一件错误的事情：

• 如果您需要实时恢复，那么您就没有足够频繁地备份日志(或者数据库也是如此)。也许您已经创建了维护计划，以便每天或每周备份数据库，但是还没有配置备份日志的维护计划。
• 如果您不需要实时恢复，那么您是在完全恢复模式，但不应该。您应该能够将数据库的恢复模型(S)切换为simple。这将意味着您将只能恢复到最后一个完整或差异备份的时间，但也意味着您的日志文件将保持对其自身的检查。
• 在这两种恢复模式中，问题可能是您的事务运行时间非常长。就像这样，有人叫BEGIN TRANSACTION，锁定了他们的工作站，然后去度假。

在这个问题中可以看到更多有关这方面的细节：

• 为什么事务日志不断增长或耗尽空间？

为了暂时缩小日志，如果您处于完全恢复模型，并且希望保持这种状态，您应该执行以下步骤并重新启动日志链以确保安全：

USE [master];
GO
ALTER DATABASE db_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- if you are already in simple, remove this line:
ALTER DATABASE db_name SET RECOVERY SIMPLE;
GO
CHECKPOINT;
GO
-- if you're already in simple, or want to stay that way, remove this line:
ALTER DATABASE db_name SET RECOVERY FULL;
GO
BACKUP DATABASE db_name TO DISK = 'path' WITH INIT, COMPRESSION;
GO
USE db_name;
GO
DBCC SHRINKFILE(N'db_name_log', 30); -- pick some size that makes sense
GO
USE [master];
GO
-- if recovery is full, re-init log chain, otherwise remove this line:
BACKUP LOG db_name TO DISK = 'path' WITH INIT, COMPRESSION;
GO
ALTER DATABASE db_name SET MULTI_USER;
GO

如果您已经处于简单状态(非常不可能)，或者如果您想要切换到简单，那么我评论了应该删除的行。

Answer 2

您肯定不希望任何预定的文件收缩，否则您将以可怕的磁盘碎片结束。在逐个案例的基础上手动执行，并且只有在你确信过度增长是偶然的情况下，例如，由于日志备份无法运行，或者一些预计不会定期发生的大规模ETL。

经常备份(并保持足够长的时间)以满足业务/应用程序的保留要求。还要考虑，您应该经常进行日志备份，以便将事务日志保持在可接受的大小内。在我的例子中，我在工作日每小时运行日志备份，但是有足够的空间根据您的需要调整日程。更频繁地运行它们以减少日志膨胀，减少恢复日志序列的痛苦。

Answer 3

您的事务日志仍然非常大，可能是由于活动的数量。如果您希望能够恢复到时间点(完全恢复模式)并控制事务日志，则更频繁的事务日志备份就是答案。

我们有一个300 gb的OLTP数据库，分配了30 gb的日志空间。我有一项工作，每30分钟进行一次日志备份，这样日志文件就可以很好地保持在分配的空间(甚至在每月索引重建期间)。但是，在重新构建期间，日志备份大小将很大)。

收缩根本不是一个好的做法。