我可以安全地从Autogrow更改实时SQL数据库吗？

我有一个SQL 2005的实时数据库，并且处于非自愿DBA的非常不幸的地位。

数据库具有1.4 GB的MDF文件和2.2 GB的LDF。自动增长将不受限制地增长10％。我有很多磁盘空间 – 所以认为最好将初始大小设置得更大一些。它正在快速增长，在过去的六个月里，规模翻了一番。

我可以select一个高数字（因为我有足够的空间），只需更改初始大小（可能为4000或什么的） – 然后将其设置为每周检查，以确保我们不在这个数字的一定百分比内？

谢谢。

是。您可以增加mdf初始大小，并且SQL Server将文件增长到该大小。在一个活的数据库上这样做是相当安全的，尽pipeselect一个安静的时间！你会发现这个尺寸的增加非常快。我只是将testing数据库从128MB增加到了4GB，耗时2秒。

考虑到数据库的当前大小，初始大小为4GB似乎是合理的。如果你有很多的磁盘空间，为什么不把增长率设置得很高，例如2GB甚至4GB？以大增量增长数据库减less了mdf文件的物理碎片。

您不需要每周检查一次，因为SQL Server只会继续增长文件。只要确保你没有用完磁盘空间。

PS我刚刚看到亚伦的回复。我不同于他，因为我对数据库的自动增长没有任何问题。但是，您要设置自动增长参数，以避免大量的小幅增加。 10％是默认值，对于大多数数据库来说，这个数字太小了。

PPS的日志大小看起来有点大。数据库是否设置为“完整日志logging”，如果是这样，你确定数据库正在备份？如果日志文件大小失控，则可以使用“dbcc shrinkfile”来减less日志文件大小。详情请参阅联机丛书。

如何及时 – 我昨天刚刚写了一篇关于这个问题的日志博客文章 – 在数据文件大小pipe理的重要性检查。概要：

如果可能的话，最初将数据文件的大小设置为考虑当前大小加上至less一年的增长
如果可以的话，打开即时文件初始化（注意：这只影响数据文件，日志文件总是要清零）
总是有autogrow打开 – 我完全和毫无保留地不同意谁说的相反。当监控失败时，应该始终处于紧急状态（除非SCOM错误阻止了您的操作 – 请参阅文章以作解释）
设置自动增长到一个固定的，适当的大小
不要依靠自动增长。监控文件使用情况并手动增长。监控紧急情况下的自动增长情况
如果你能避免，永远不要缩水。我的博客文章有一个脚本，告诉你为什么。
你的日志文件似乎太大了。结帐这个其他的博客文章正确的事务日志大小pipe理的一些提示和技巧的重要性。

希望这可以帮助！

aSkywalker，使用The Force或者在这里看看Paul Randal的“不自主的DBA”的文章：