☰

最小化运行简单恢复模型的开发人员框中的 SQL 事务日志文件大小

tag-icon • tag-icon sql-server-2008 log-files sharepoint-2010
最小化运行简单恢复模型的开发人员框中的 SQL 事务日志文件大小

我们在开发环境中有很多 SQL 服务器，我们从未备份过数据库（代码的 TFS 就足够了）。

(SharePoint) 数据库都设置为简单恢复模型，但是日志文件（尤其是 SharePoint 配置数据库的日志文件）增长得相当大并填满了 SQL 服务器上的数据驱动器。

由于这些日志文件从未用于任何事情，我希望获得有关如何最好地最小化这些日志文件的大小 - 或者甚至在可能的情况下禁用它们的建议。

我不完全确定为什么日志文件即使在简单的日志记录中也会变得如此之大（检查了长时间运行的事务（DBCC OPENTRAN）但没有发现任何异常）。

我猜测日志文件没有被截断的原因是我们没有进行任何备份，因此没有达到检查点。

日志文件的自动增长设置为自动增长 10%，限制为 2 gb，所以我想这就是为什么这里也达不到检查点 (70%) 的原因。

在不牺牲性能（例如 VLF 碎片）的情况下保持日志文件较小（最佳情况为 0）的最佳策略是什么？

答案1

您是否正在运行任何可能进行重新索引或其他繁重工作的维护作业？即使使用简单恢复，日志也需要至少足够大才能容纳针对数据库发出的最大事务。尝试运行 DBCC SQLPERF(LOGSPACE) 并检查日志文件的实际使用量。如果它非常低，那么简单恢复可能按预期工作，日志文件可能只是因为它需要这么大才能支持一些大于平均水平的事务而增长。

答案2

首先运行以下查询来查看日志未被截断的原因：

select log_reuse_wait from sys.databases where name = '<database name>'

关于日志重用的原因描述如下： http://msdn.microsoft.com/en-us/library/ms178534.aspx

答案3

尝试运行此查询。这是由 MS 整理的（我手边没有这篇文章），最初是为在 SBS2008 上运行的 Sharepoint 设计的，但应该适用于任何 Sharepoint 实例。确保验证数据库名称和路径与您的实例匹配。

declare @ConfigDB varchar(255);
declare @ConfigDBLog varchar(255);
declare @ConfigDBCmd varchar(255);
select @ConfigDB =  name from sys.databases where name like 'SharePoint_Config_%';
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\windows\temp\before.bkf''';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP LOG [' + RTRIM(@ConfigDB) + '] WITH TRUNCATE_ONLY';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
select @ConfigDBLog =  name from sys.database_files where name like 'SharePoint_Config%_log';
set @ConfigDBCmd = 'use [' +  RTRIM(@ConfigDB) + '] DBCC SHRINKFILE([' + RTRIM(@ConfigDB) + '_log],1)';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\windows\temp\after.bkf''';
execute(@ConfigDBCmd);
go

答案4

再检查一遍您的开发数据库上有简单的恢复模型。

select name, recovery_model_desc from sys.databases

您需要一个日志文件：它不能被禁用或设置为零

相关内容