探索-数据库日志增长设置多少比较合理

Question

目前有一个ERP的数据库大小为140G左右，
数据文件增长方式为：5%的增长方式感觉不是很合理，请大牛指点下...
----------------------------------------------------
从最近的两次备份压缩文件分析（SQL 2005）：
数据库140G左右，压缩后11到12G左右
两个压缩后的备份文件相差60M，
相隔7天，
这样推算：如果没有压缩的话  60*140/11=700M左右
平均每天100M的增长
（以上个人推算，不知道是否合理，仅供参考）

Answer 1

对于ERP类型的应用，磁盘增长设为10M or 20M即可
太大时，当磁盘扩展时会影响客户端响应

Answer 2

自增长也要探讨吗？
如果探讨的话就是别射成百分比
我的和日志一样都是100M
用的挺happy的

Answer 3

个人建议：
1、对于150G的库，日志文件不要按百分比来设置，设置为100M一次还差不多。
2、平均100M。对于ERP来说有点大了。你这100M是日志造成的吗？

Answer 4

可以设置平均每次100M的增长，我个人是建议先评估下数据库1个月或1年能增加至多少，再根据磁盘空间的大小来决定一个初始值。如你评估1个月的数据量增长至200G,你可以先设置个200G的初始值，再设置每次100M的增长。如果是日志文件增长比较快，记得做好定期日志备份，迁移日志备份文件，以减少日志文件占更多的磁盘空间。

Answer 5

跟数据库大小没关系啊，得看你每天处理多少数据量了，会写多少日志，
哪怕就1M的数据，反复擦写，也会变成100，1000M甚至更多的日志。一般建议设置为按固定大小增长，比如512M，1G，2G

Answer 6

建议看看这篇文章：Transaction Log VLFs – too many or too few?
http://www.sqlskills.com/blogs/kimberly/transaction-log-vlfs-too-many-or-too-few/

Answer 7

请问下 大牛们，目前数据库这么大，
能否收缩下mdf文件？
（日志应该可以收缩的，收缩前先备份下）

Answer 8

只要磁盘空间没问题，就不要去shrink DB。

Answer 9

收缩可以，但是要考虑是否有必要，如果mdf的可用空间本来就不多，假设只有10%，那么完全没必要收缩了，不然到一定程度又会自动增长，带来的IO压力更大。如果100G的mdf里面可用空间有90%，那就收缩到30~50G是可以的。

Answer 10

对于日志的估算，可以用DBCC SQLPERF(LOGSPACE)，每天执行一次把数据插入一个表，然后过一段时间再统计

Answer 11

可以设置平均每次100M的增长，我个人是建议先评估下数据库1个月或1年能增加至多少，再根据磁盘空间的大小来决定一个初始值。如你评估1个月的数据量增长至200G,你可以先设置个200G的初始值，再设置每次100M的增长。如果是日志文件增长比较快，记得做好定期日志备份，迁移日志备份文件，以减少日志文件占更多的磁盘空间。

Answer 12

建议看看这篇文章：Transaction Log VLFs – too many or too few?
http://www.sqlskills.com/blogs/kimberly/transaction-log-vlfs-too-many-or-too-few