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

目前有一个ERP的数据库大小为140G左右，
数据文件增长方式为：5%的增长方式

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

54 个解决方案

#1

这应该比较合理吧，不过这每天增长的100M并不是数据量，而是数据占用的空间大小。

#2

从你的压缩比来看，你的系统设置的块大小并不适合你的服务器应用

#3

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

#4

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

#5

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

#6

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

#7

100M 是否小了点？

#8

就是有些小了

#9

跟数据库大小没关系啊，得看你每天处理多少数据量了，会写多少日志，
哪怕就1M的数据，反复擦写，也会变成100，1000M甚至更多的日志。

一般建议设置为按固定大小增长，比如512M，1G，2G。。。

#10

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

#11

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

#12

数据库一直都是个大问题

#13

尽量设大点，这样不用每天都加大

#14

引用 11 楼 bean_sql 的回复:

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

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

#15

该回复于2013-05-10 09:45:49被管理员删除

#16

围观达人的发言

#17

还是以固定大小增长比较合理。百分比当数据库很大的时候，如果磁盘空间小于百分比会。。。。。

如果空间允许，预估一下1~2年的数据库文件可能大小，吧数据文件设置的大点，这段期间就没什么空间申请了。
满足不了那就文件增长固定大小尽量设置大点。。。减少频繁的空间申请也会消耗系统资源。

#18

引用 17 楼 ldslove 的回复:

还是以固定大小增长比较合理。百分比当数据库很大的时候，如果磁盘空间小于百分比会。。。。。

如果空间允许，预估一下1~2年的数据库文件可能大小，吧数据文件设置的大点，这段期间就没什么空间申请了。
满足不了那就文件增长固定大小尽量设置大点。。。减少频繁的空间申请也会消耗系统资源。

李总

#19

100M 是否小了点

#20

引用 11 楼 bean_sql 的回复:

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

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

#21

20楼的纯粹个人想法，没有什么数据支持，可以酌情考虑，不是强制的。

#22

可以尝试每天做差异备份，通过一周的差异备份，推算出数据库增长的规模，然后设置数据库增长大小

#23

谢谢！！

#24

100M 是否小了点

#25

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

#26

引用 11 楼 bean_sql 的回复:

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

数据文件140G，备份出来也是140G，说明基本没什么可以收缩的余地了
收缩文件时，可以看到空闲了多少比例，再决定是否收缩也不迟

另外，数据的大小与日志的大小没必然的关系

#27

该回复于2013-05-10 14:13:09被管理员删除

#28

引用 楼主 bean_sql 的回复:

目前有一个ERP的数据库大小为140G左右，
数据文件增长方式为：5%的增长方式

定值增长是线性增长，百分比是非线性
关键还是看你的业务数据的增长，如果业务数据的增长是非线性的，用百分比增长挺好~~

#29

该回复于2013-05-10 15:16:00被管理员删除

#30

#31

强悍！。。。。。

#32

该回复于2013-05-10 17:58:53被版主删除

#33

感觉有点小了

#34

数据库一直都是个大问题啊！！

#35

就是尽量防止日志文件自动增长，因为自动增长的时候影响性能，做好监控，然后设定个适合的值，定期备份。
其实，6楼已经回答的很好了。

#36

100M小了点了

#37

#38

数据库太大了不适合用%方式增加

#39

好难啊，不太懂

#40

凡是大数据的问题讨论我都重视。

#41

引用 35 楼 SQL_Beginner 的回复:

就是尽量防止日志文件自动增长，因为自动增长的时候影响性能，做好监控，然后设定个适合的值，定期备份。
其实，6楼已经回答的很好了。

我觉得我回答的也挺好。完全符合题意
被戴上了灌水大王的帽子，干啥别人都觉得我没个正经。

#42

引用 41 楼 Beirut 的回复:

Quote: 引用 35 楼 SQL_Beginner 的回复:

就是尽量防止日志文件自动增长，因为自动增长的时候影响性能，做好监控，然后设定个适合的值，定期备份。
其实，6楼已经回答的很好了。

我觉得我回答的也挺好。完全符合题意
被戴上了灌水大王的帽子，干啥别人都觉得我没个正经。

别逗了，谁给你灌水大王了。赌王

#43

引用 42 楼 pengqian098 的回复:

Quote: 引用 41 楼 Beirut 的回复:

Quote: 引用 35 楼 SQL_Beginner 的回复:

就是尽量防止日志文件自动增长，因为自动增长的时候影响性能，做好监控，然后设定个适合的值，定期备份。
其实，6楼已经回答的很好了。

我觉得我回答的也挺好。完全符合题意
被戴上了灌水大王的帽子，干啥别人都觉得我没个正经。

别逗了，谁给你灌水大王了。赌王

这是技术贴，你们这群蠢货。灌水要看看地方。

#44

就是尽量防止日志文件自动增长，因为自动增长的时候影响性能，做好监控，然后设定个适合的值，定期备份。
其实，6楼已经回答的很好了

#45

引用 41 楼 Beirut 的回复:

Quote: 引用 35 楼 SQL_Beginner 的回复:

就是尽量防止日志文件自动增长，因为自动增长的时候影响性能，做好监控，然后设定个适合的值，定期备份。
其实，6楼已经回答的很好了。

我觉得我回答的也挺好。完全符合题意
被戴上了灌水大王的帽子，干啥别人都觉得我没个正经。

你们的掌声呢？

#46

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

#47

好难懂啊，好难懂啊，

#48

该回复于2013-05-13 08:44:28被管理员删除

#49

这可以路过看看不

#50

该回复于2013-05-14 08:30:54被管理员删除