【100分】sql 日志文件达到了可怕的18.4G ，这方面处理没什么经验，请大牛们贴贴你们日常清理的日志的脚本

[霜寒月冷]

网上也搜了一些资料，对有的语句还不是很放心，担心清理的时候，sql文件会被损坏，故先备份了
一遍。

[霜寒月冷]

引用 36 楼 DBA_Huangzj 的回复:

按照目前的情况，可能性最大的就是你那个delete操作，把大量数据在短时间内删除，到时记录的日志非常大，需要一段时间commit，commit完之后就可以搜索了，如果你要删的数据是全删，建议使用truncate table

怪不得，我删了10多分钟，查询分析器都好像死。 那我现在开始收缩，有什么高效的脚本建议

[--小F--]

好久没有出现过这样的日志收缩的帖子了 盖个章让大家讨论一下。

[水族杰纶]

引用 39 楼 chz415767975 的回复:

[quote=引用 36 楼 DBA_Huangzj 的回复:] 按照目前的情况，可能性最大的就是你那个delete操作，把大量数据在短时间内删除，到时记录的日志非常大，需要一段时间commit，commit完之后就可以搜索了，如果你要删的数据是全删，建议使用truncate table

怪不得，我删了10多分钟，查询分析器都好像死。 那我现在开始收缩，有什么高效的脚本建议[/quote] 38#代码试试

[--小F--]

DBCC SHRINKFILE (Bigdata_Log, 1); 应该可以直接收缩到1M

[--小F--]

TRUNCATEONLY 将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动。数据文件只收缩到最后分配的区。

[發糞塗牆]

日志收缩基本上都很快，一下子收缩18G都没问题...等一下吧。不要手动停

[霜寒月冷]

引用 41 楼 wufeng4552 的回复:

[quote=引用 39 楼 chz415767975 的回复:]
[quote=引用 36 楼 DBA_Huangzj 的回复:]
按照目前的情况，可能性最大的就是你那个delete操作，把大量数据在短时间内删除，到时记录的日志非常大，需要一段时间commit，commit完之后就可以搜索了，如果你要删的数据是全删，建议使用truncate table

怪不得，我删了10多分钟，查询分析器都好像死。
那我现在开始收缩，有什么高效的脚本建议[/quote]
38#代码试试[/quote]

[水族杰纶]

引用 45 楼 chz415767975 的回复:

[quote=引用 41 楼 wufeng4552 的回复:] [quote=引用 39 楼 chz415767975 的回复:] [quote=引用 36 楼 DBA_Huangzj 的回复:] 按照目前的情况，可能性最大的就是你那个delete操作，把大量数据在短时间内删除，到时记录的日志非常大，需要一段时间commit，commit完之后就可以搜索了，如果你要删的数据是全删，建议使用truncate table

怪不得，我删了10多分钟，查询分析器都好像死。 那我现在开始收缩，有什么高效的脚本建议[/quote] 38#代码试试[/quote] [/quote] trunc. log on chkpt. dbname是你数据库名 dbname_log是你的日志文件名 如果修改过 sp_helpdb dbname查询日志文件名

[發糞塗牆]

有SSMS操作就可以了。。。

[霜寒月冷]

谢谢楼上所有同仁，结贴给分。SSMS参照这个帖子 ，我做好了，设置了10MB http://blog.sina.com.cn/s/blog_491d1f37010131mk.html

[小博测试成长之路]

不错不错

[cattpon]

引用 1 楼 DBA_Huangzj 的回复:

SELECT name,log_reuse_wait_desc,recovery_model_desc
FROM sys.databases

上结果，

膜拜一下版主。。。。

[u014530773]

http://www.4shared.com/photo/G5xoKdjZce/__20140403_.html

[sunylf]

温故而知新.......

[lonelyk]

好贴.收藏了~

[蚍蜉]

自己水平太低，不明觉厉，以后留着看

[twtiqfn]

好高深的问题，不懂啊

[niuzhenpeng]

学习，mark。

[ponydph]

我遇到的问题是 数据文件很大，导致查询很慢。 一般都是定时导出数据，

[Cream_vc]

可以按照SQL SERVER上的操作压缩，就可以解决了！！！