一次数据库收缩捕获-22解决方案？

Question

我正在为SQLServer2012EE开发一个计划，以正确地缩小大小和类型(nchar到char类型)，一些不必要的Unicode nvarchar(max)字段，并希望通过进行一次收缩来优化数据库大小，作为停机时间的一部分。实验表明，所分配的空间节省了50%，即11G的数据。

经过阅读和实验，很明显，缩小数据库会导致索引碎片，而重建索引则会导致数据库扩展。一个真正的捕获-22的情况。我不想在数据库中留出50%的空闲空间，在这种情况下是11G的磁盘存储。

下面的方法会不会是一次合理的收缩，从而最终得到无框架的索引和最新的索引统计？

O备份w/验证和重复备份。

不要丢下所有的索引。

O通过复制到新表重新生成任何过胖的表，然后删除并重命名表。这目前运作良好。

O缩小数据库，留下合理的空闲空间。

O重新创建所有已删除的索引。

O验证数据库并检查碎片。

指出任何需要考虑的警告、建议、建议或替代方案。

特克斯，戴夫

Answer 1

简单的恢复模型不会“关闭日志”--因此通常情况下，除非您要将任何这些活动分解成非常小的块，只需预先调整日志的大小，以处理最大的重建，并且不要麻烦地破坏恢复模型。

而且，通常情况下，除非您的数据不会再次增长，暂时腾出空间是没有什么好处的(考虑到我不知道您所说的“合理”是什么意思)。您需要在驱动器上留出空闲空间，以防数据库再次增长，对吗？为什么只为了让它长出来而收缩它呢？在数据库增长之前，你会提供该空间的短期租金吗？您只是试图避免空闲空间%警报吗？

建议:给这些帖子一个好的阅读..。

• 为什么事务日志不断增长或耗尽空间？
• 服务器增长数据库文件的最佳实践
• SHRINKFILE最佳做法和经验
• 我需要缩小我的数据库-我刚刚腾出了很多空间
• 缩小数据库的大小
• 什么时候可以缩小数据库？
• 耗尽空间的数据库