我有一个数据库，其大小正在快速增长。虽然它的大小是60GB但是在执行db_spaceused存储过程之后我可以验证更多的40 GB是未使用的（未使用的空间是不同的，不是我不知道的保留空间用于表增长）。实际数据大小约为10-12 GB，预留空间中的GB很少。
现在收集那些未使用的空间我试图使用缩小操作，但结果却没有帮助。在进一步搜索之后，我还发现不使用缩减DB，因为这导致数据片段被生成，导致磁盘操作时的dealay。现在我真的不确定我应该尝试什么其他操作来重新收集空间并重新收集数据库。我断言，由于大小查询可能需要更长的时间，并且回收此空间可能有助于提高性能（不确定）。
在调查时我也遇到了Gererate Scripts功能。它也有助于导出数据，架构，但我不确定它是否也有助于创建脚本（每个用户，权限和其他东西），以便脚本将使用create scema帮助创建数据库的副本（深层复制/克隆）然后用数据填充到其他db / server？
任何指针都会有所帮助。
答案 0 :(得分：3)
如果您的数据库是60Gb，则意味着它已增长到60GB。即使数据只有20Gb，您也可能会不时地进行数据增长（例如，夜间索引维护工作）。建议使数据库保持在60Gb 。不要试图回收空间，只会造成伤害，无论是什么导致数据库增长到60Gb才能开始它可能会再次出现并触发数据库增长。
事实上，你应该去对面。尝试确定为什么它增长到60Gb，并推断当数据达到30Gb时会发生什么。数据库会增长到90Gb吗？如果是的话，你应该将它现在增长到90Gb。你想要的最后一件事是增长是随机发生的，并且可能在关键时刻耗尽磁盘空间。实际上，如果您的服务器已启用Instant File initialization，则应立即检查。
现在当然，问题是： 会导致3倍数据量增长，以及如何识别它？我不知道任何简单的方法。我建议首先查看您的SQL代理作业。检查维护脚本。查看应用程序本身，它是否具有增长模式和数据删除？查看过去的备份（你确实拥有它们，对吧？）并进行比较。
BTW我假设尽职调查并且您检查了数据文件已增长到60Gb。如果LOG文件已经增长，那么很容易，这意味着您启用了完全恢复模型并忘记备份日志。