2014-11-13 52 views
0

我有一个数据库的大小在200G左右,并且它每天都会发生很多插入(每天增长大约3到4 GB),但Auto-Grow设置设置为1 mb。SQL Server 2008自动增长设置为重载数据库

我认为这是一个问题,我认为如果将它设置为1GB,它会增加性能和功能,是吗?

我觉得用1MB自动增长的数据库总是会忙于分配一个新的空间,对吗?
任何建议提高性能的最佳实践方法?

感谢所有

+0

这实际上更像是一个DBA问题(而不是**编程**问题) - 投票转移到dba.stackexchange.com –

回答

0

我觉得这是一个问题,我想,如果我将它设置为1GB这无疑增加了性能和功能,是这样吗?

这将意味着数据库将需要停止更少的增长,当然,数据插入会更频繁地发生。它将减少数据文件增长的影响。但是,Microsoft says that autogrow is not intended to manage planned file growth。它意在处理意外的增长。自动增长功能并不是按照您使用它的方式来设计的。设计意图是你知道你将要存储多少数据,并且你已经相应地进行了规划,并且已经正确地确定了数据库的大小。

但是,考虑到您的应用程序,这可能有些不现实。如果您的系统设计为永久保存所有收集的数据,则您的容量规划有点困难。

这就是为什么区分运营数据和仓库数据的常见做法。您的运营数据存储在一个数据库中,您可以预测在给定时间范围内(通常为一年或更多年)的增长情况。经过一段时间后,较旧的数据将被存档到数据仓库中,这可能是非常大的或单年的容器,但由于很少插入数据,因此您知道您的容量将会是多少。

如果我是你,我会选择一个时间表来计划。说一个月,一个季度或一年。每一段时间,手动增加数据库的空间足够大,这样可以腾出空间来满足未来的需要。不要忘记包含索引空间!使用SSMS报告来帮助您估算!

这意味着您可以在非工作时间或维护时段进行增长,并且您的应用程序永远不会等待数据库完成增长。然后,我会将autogrowth设置为您计划的可用空间的5%左右。如果你低估,你会看到你的收缩/增长日志时的多少。然后你可以增加下个月。最终,你会了解每月需要的内容。只要确保在数据库中根据可用空间增长,而不是绝对文件大小。

相关问题