相关疑难解决方法(0)

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

什么时候应该使用完整恢复模型，什么时候应该对数据库使用简单恢复模型？

我总是使用完整恢复模式，因为它是默认模式，但今天我遇到了这个错误：

Microsoft OLE DB Provider for SQL Server (0x80040E14) 数据库“DATABASE NAME”的事务日志已满。要找出无法重用日志中的空间的原因，请参阅 sys.databases 中的 log_reuse_wait_desc 列

特定的数据库实际上是我服务器上最小和最不活动的数据库之一，所以我不知道这个数据库上的日志如何被填满，而不是其他数据库。

为了缩小日志并使数据库再次可访问，我将恢复模式从 FULL 更改为 SIMPLE 并缩小了逻辑文件日志，使用以下命令

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

它帮助，但现在我需要了解为什么它的帮助下，如何这种情况开始，如何防止这种情况在未来？

编辑：

每天晚上 1 点，我们都会对服务器上的每个数据库进行脚本备份。这是由 31 行脚本完成的，其中最重要的部分是

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK …

背景：

我最近继承了 50 多个带有 450 多个数据库的 SQL Server。每晚备份大约为 8TB，不用说，我们使用的磁盘空间比我们想要的要多。所有数据库都设置为完全恢复，并且从未备份事务日志。我已经浏览了所有 SQL Server，并确定了只需要每晚备份的低优先级服务器，并且可以接受一天的数据丢失。

题：

我正在将许多低优先级数据库SIMPLE从FULL. 现有的事务日志是否会被截断（在创建检查点时）？一些现有的事务日志是 50-100GB；为了继续前进，确定我应该将它们缩小到什么的最佳方法是什么？我显然不想让它们那么大。或者，随着时间的推移，它们会自行缩小吗（我认为它们不会）？

我们确实为 SQL Server 2008 r2 express 制定了一些维护计划。如果任何表的页数超过 50 并且平均碎片超过 20，我们每个月都会对数据库进行碎片整理。

如果数据库日志大小>2MB，则恢复模式为简单，收缩，恢复模式重新设置为FULL。如果 Page_count>50 且 avg_fragmentation_in_percent > 30，则索引为 REBUILD。

如果 Page_count>50 且 avg_fragmentation_in_percent > 5 且 <30，则索引为 REORGANIZE。

这就是我们目前正在做的事情。但是我们发现自增长事件是资源密集型的，不应重复发生。现在，对于所有数据库，mdf 文件的自动增长设置为 MB，ldf 文件设置为 10%，这是创建新数据库时的默认值。我们计划根据每天变大的数据库数量来增加数据库的自动增长值。但是我想知道有多少自动增长事件对数据库来说是理想的。我应该设置自动增长以便它每天、每周或每月等只发生一次吗？所以请帮助我为我的数据库设置自动增长值。还有另一个问题，如果我每月对数据库进行碎片整理，那么它就会缩小。因此，在此之后，对于所有我确实收缩过的数据库，在写入新数据时都会发生一次自动增长。所以会有很多自动增长事件。那么会不会有问题呢？请告诉我一个解决方案。