SQL Server自动缩小打开是否安全？

（我原本是作为一个普通的问题询问的，但后来发现了正确的方法 – 感谢BrentO）

没有永不。

我已经多次在ServerFault上遇到这个问题，并希望通过一些很好的build议来吸引更多的观众。 如果人们在这种做事的方式上皱眉头，那么我们会很乐意去除这个问题。

自动缩小是一个非常常见的数据库设置已启用。 这似乎是一个好主意 – 从数据库中删除额外的空间。 有很多“非自愿的DBA”（认为TFS，SharePoint，BizTalk或者只是普通的旧SQL Server），他们可能不知道自动收缩是邪恶的。

虽然在微软我曾经拥有SQL Server存储引擎，并试图删除自动收缩function，但它不得不留下来向后兼容。

为什么自动收缩如此糟糕？

数据库可能只是再次增长，为什么缩小呢？

1. 收缩 – 增长 – 收缩 – 增长导致文件系统级别的碎片化，并占用大量资源。
2. 你不能控制它什么时候开始（即使它是正常的）
3. 它使用了大量的资源。 在数据库中移动页面需要CPU，大量的IO，并生成大量的事务日志。
4. 下面是真正的踢脚板：数据文件缩小（无论是否自动）会导致大量的索引碎片，从而导致性能下降。

我做了一个博客文章，有一个示例SQL脚本，它显示了它引起的问题，并在一个更详细的解释。 请参阅自动收缩 – 将其closures！ （在我的博客上没有广告或垃圾）。 不要因为收缩日志文件而感到困惑，有时候这是有用的和必要的。

所以，你自己一个忙 – 看看你的数据库设置，并closures自动收缩。 完全相同的原因，您的维护计划也不应该缩水。 把这个词传播给你的同事。

编辑：我应该补充说，第二个答案提醒 – 有一个普遍的误解，认为中断缩小操作可能会导致腐败。 不，不会的。 我曾经拥有SQL Server中的收缩代码，它会回滚当前页面的移动，如果中断的话。

希望这可以帮助！

当然，保罗是对的。

查看所有数据库及其自动收缩设置。 如果你有很多数据库，就会潜入。

sp_msforeachdb @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')' 

这是在dmv的某个地方….我想知道。

这不是“不安全” – 它不会损害任何东西。

但不build议在数据库可能决定启动昂贵的重新安排练习的生产环境中，在一堆请求进入之前，这些请求需要更长时间才能提供。 使用调度缩减操作以及其他维护操作（如备份（实际上，在备份之后 – 它将更多地从事务日志中这样做））要好得多。 或者根本不缩小，除非有增长问题 – 您可以随时设置一个显示器，让您知道未使用的分配空间何时超过一定比例或固定大小。

IIRC除默认外，所有MSSQL版本中的所有数据库的默认值都是closures的。

TechNet上有一个白皮书，更详细地解释了SQL维护。

http://technet.microsoft.com/en-us/library/cc262731.aspx

我看到一个SQL服务器同时启用了Autogrow和Autoshrink。 这个（相对强大的）服务器非常慢，因为它整天所做的只是缩小和扩大数据库文件。 Autoshrink可以是有用的，但我build议两件事情：

1. 默认closuresAutoshrink。
2. logging您的服务器configuration，以便知道Autogrow和Autoshrink的启用位置以及不在哪里。

我被迫缩小数据库的唯一时间是在磁盘空间较less（不足以保存生产数据库）的testing服务器上刷新副本。

生产数据库的文件具有慷慨的可用空间，不幸的是，您必须恢复与您备份的数据库相同的文件大小。 所以在备份之前别无select，只能缩减生产。 （这个缩水花了很长时间，大量的资源被消耗掉，随后的交易日志增长是有问题的。）

另外看看这个video教程….

观看Paul Randal演示如何缩小和自动缩小可能导致严重的数据库碎片问题http://wtv.watchtechvideos.com/topic194.html