相关疑难解决方法(0)

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

在 SQL Server 中 -

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

我一直在通过 sql server 2008 r2 中的数据收集器监视文件增长两周。数据库以大约 35(MB)/天的速度持续增长。数据库尚未达到 2 GB 的初始大小。

DB 文件自动增长设置为 5MB，我想尝试不同的方法，所以我正在寻找建议和/或评论。

每周周日晚上 1:30 有一项调整任务运行。该任务将：

• 检查数据库完整性
• 缩小日志文件 - （这没关系，因为日志模式很简单）
• 收缩数据库
• 重组索引
• 重建索引
• 更新统计
• 清理历史

我想在每周调整计划中再添加两个步骤：

1. 如果已用空间达到某个阈值或总大小，则将数据库文件增大 500 MB。
2. 如果已用空间达到总大小的某个阈值，则将日志文件增加 250 MB（收缩后）。

通过将增长负担置于离线时间，我希望通过减少重负载期间自动增长事件的数量来提高性能。

我有两个关于自动增长文件的问题。

• 放置文件增长步骤的最佳位置是在当前步骤之前还是之后？
• 如果我使用ALTER DATABASE|MODIFY FILE来增长文件，那么我如何确定SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)？

序言：总的来说，这是一个很大的禁忌，但相信我，在真正需要空间的情况下，这种情况很少见。例如 Express Edition 限制为 10GB。想象一下，您发现通过数据类型转换（blob 列）可以释放大量空间。但在那之后，DB 文件的大小仍然和我们知道的一样，10GB 的限制也没有神奇地改变。所以需要某种收缩。那是一个例子。

在我的测试环境中，我执行了：

DBCC SHRINKFILE (DBFile, NOTRUNCATE)
DBCC SHRINKFILE (DBFile, TRUNCATEONLY)

这确实有效（我知道这会最大限度地减少可用空间，在现实世界中我会留下可用空间）。花了很多小时才完成。正如我们所知，它是一个单线程进程奇怪的行为 DBCC Shrinkfile，“它作为一系列非常小的系统事务工作，因此没有什么可回滚的。” - 保罗兰达尔http://www.sqlservercentral.com/Forums/Topic241295-5-1.aspx。我们也知道它搞乱了索引碎片时间http://www.mssqltips.com/sqlservertip/2055/issues-with-running-dbcc-shrinkfile-on-your-sql-server-data-files/和我可以确认。尽管在http://www.karaszi.com/SQLServer/info_dont_shrink.asp 中有描述，但我没有遇到日志文件增长

我发布了一些INDEX REBUILD，REORGANIZE而那些在几秒钟内就完成了。

我的问题：

1. 如果我可以在收缩后几秒钟内修复索引碎片，那么收缩有什么大不了的？我不明白。在 DBA stackexchange 上，“收缩”主题 ( https://dba.stackexchange.com/tags/shrink/info ) 说“几乎是您可以对 SQL Server 数据库做的最糟糕的事情。简而言之：它牺牲了性能来获得空间。” plus 指的是另一篇关于它的流行文章。但是索引碎片是可以修复的。
2. 为什么我没有遇到任何日志文件增长？
3. 如果在空间释放操作后首先重建索引会怎样。可以代替第一个DBCC SHRINKFILE (DBFile, NOTRUNCATE)所以我只需要DBCC SHRINKFILE (DBFile, TRUNCATEONLY)吗？我有一种感觉，两者在不同的逻辑层面上工作，但我不得不问这个。

底线：我保证我不会定期收缩或做任何事情。但这是一个上限被击中并需要收缩的情况。

回答我的第二个问题：我没有遇到事务日志文件增长，因为我在开发人员测试环境中摆弄。事务日志文件会在生产环境中增长（假设完全恢复模型）。您也应该在您的测试环境中模仿它。tr 日志文件的增长实际上大于您可以在数据库文件中释放的空间。最后，您不仅要收缩数据库文件，还要收缩事务日志（如何以及何时这样做取决于恢复模型）。我看到的生产环境有如此严重的索引碎片，它可以变得更好。我的脚本重新索引每个碎片级别高于 30% 的索引。

为了应对增长，您可能必须在进行一生一次的转换时从完全恢复切换到简单。但这会破坏备份链。

回答我的第三个问题：在 DB 文件收缩后进行重新索引/索引重建，因为收缩会弄乱索引碎片。

我还没有试验过所有这些如何影响查询统计信息。

脚本重新索引：见实施例d的TechNet sys.dm_db_index_physical_stats（的Transact-SQL） 。一篇关于增量收缩的文章，会引出其他有价值的内容：http : //www.mssqltips.com/sqlservertip/3178/incrementally-shrinking-a-large-sql-server-data-file-using-powershell

我的生产服务器的数据库意外增长，我几乎要创建一个作业来缩小每月运行一次的数据库。这是个好主意吗？

备份失败并且记录了大量事务的失败时间，这使数据库迅速增长。

我正在使用 SQL Server 2008 R2。