频繁删除数据导致文件太大怎么办

lighting_pig 2012-10-17 06:01:05
我说的是数据文件,不是日志文件
日志文件我知道怎么干掉
数据文件一天可以增加几百兆。。

频繁删除的那个表 unused一天加个几百兆没问题
数据库收缩好像没用,shrinkdatebase之类的命令也没用,重建索引页没用
上网一查,大家都说要先把数据copy走,然后TRUNCATE ,然后把数据移回来,个人觉得这个挺恶心的,请问有啥更好的办法不?
...全文
157 16 打赏 收藏 转发到动态 举报
写回复
用AI写文章
16 条回复
切换为时间正序
请发表友善的回复…
发表回复
lighting_pig 2012-10-18
  • 打赏
  • 举报
回复
昨天DBCC SHRINKFILE还可以,现在循环来搞不行了,原因不明。。估计还是有人用表的原因或其他未知问题。。。。

看起来这个世界唯一的正确办法就是 把数据copy走,然后TRUNCATE ,然后把数据移回来??
Ny-6000 2012-10-18
  • 打赏
  • 举报
回复
删除语句,不要用delete,而是TRUNCATE .
lighting_pig 2012-10-18
  • 打赏
  • 举报
回复
今天来汇报一下,DBCC SHRINKFILE (N'TEST' , 2)这个命令和DBCC SHRINKFILE(1)一样也是一次只收缩一点点,不是真的一次到位,不过,也一样搞个循环多运行几次就可以搞定。

现在明白了,之所有很多人说只能先把数据copy走,然后TRUNCATE ,然后把数据移回来,不能用DBCC SHRINKFILE 估计都是遇到了和我一样类似的问题,这个命令一次只能释放出一点点空间,如果不循环个几十上百次那是没效果的。

楼上说的先断开服务再收缩这是不行的,因为很多系统不能停的。

搞定结贴。
ycagri 2012-10-18
  • 打赏
  • 举报
回复
我一般是先断开服务,或是重启服务程序,断开应用程序,然后收缩
lighting_pig 2012-10-18
  • 打赏
  • 举报
回复
试了一下,还是应该把主键改成聚集索引,
然后定时任务,每晚重建聚集索引,然后DBCC SHRINKFILE
汤姆克鲁斯 2012-10-17
  • 打赏
  • 举报
回复
[Quote=引用 6 楼 的回复:]

试了一下,发现DBCC SHRINKFILE好像还是起作用的,刚才上网查询的命令是
DBCC SHRINKFILE(1)

DBCC SHRINKFILE(表名)
我最开始试了试发现好像不起作用,其实仔细看小了一点点,
一怒之下写了个脚本

declare @i int
set @i=500
while @i>0
begin
dbcc shrinkfile(1)
set……
[/Quote]
这个不是一次收缩一点点

因为日志的空间可能被其他用户正在使用,所以就会看不到效果
过一会在执行一个命令可能就有效果了

更科学的方法是使用while 里面加一个 waitefor
以学习为目的 2012-10-17
  • 打赏
  • 举报
回复
[Quote=引用 6 楼 的回复:]
试了一下,发现DBCC SHRINKFILE好像还是起作用的,刚才上网查询的命令是
DBCC SHRINKFILE(1)

DBCC SHRINKFILE(表名)
我最开始试了试发现好像不起作用,其实仔细看小了一点点,
一怒之下写了个脚本

declare @i int
set @i=500
while @i>0
begin
dbcc shrinkfile(1)
set ……
[/Quote]这样是有道理的,确实不能一次性收缩比率太大,避免可能引起的收缩故障。


先把数据copy走,然后TRUNCATE ,然后把数据移回来,个人觉得这个挺恶心的。其实这个也是一个没有办法的办法
發糞塗牆 2012-10-17
  • 打赏
  • 举报
回复
库大的话不建议一次性缩的太小,严重耗费I/O资源。特别在运行期间,一边收缩一边又要涨。你可以100M或者1G这样收缩。反而快一点
發糞塗牆 2012-10-17
  • 打赏
  • 举报
回复
无论是日志文件还是数据文件,由于DBCC SHRINKFILE 是作用在区而不是页上,如果你的数据分布零碎,那是无效的,重建/创建聚集索引,然后在DBCC SHRINKFILE,如果这个无效,把数据copy走,然后TRUNCATE ,然后把数据移回来这个是可行的,不恶心,微软技术支持都是这样说的。
开启时代 2012-10-17
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 的回复:]
例子:DBCC SHRINKFILE (N'TEST' , 2)
收缩数据库TEST 到2M大小。
应该可以收缩。
[/Quote]
这个如果库大的话 最好别在生产时间段执行。
lighting_pig 2012-10-17
  • 打赏
  • 举报
回复
试了一下,发现DBCC SHRINKFILE好像还是起作用的,刚才上网查询的命令是
DBCC SHRINKFILE(1)

DBCC SHRINKFILE(表名)
我最开始试了试发现好像不起作用,其实仔细看小了一点点,
一怒之下写了个脚本

declare @i int
set @i=500
while @i>0
begin
dbcc shrinkfile(1)
set @i=@i-1
end
GO

然后发现确实把unused空间全消掉了。。。。
挺搞笑的命令,居然一次只消一点点,简直就是恶心人。。。。

楼上说的例子:DBCC SHRINKFILE (N'TEST' , 2)我还没试,等明天多了几百兆再试这个命令看是不是可以只要运行一次...
SQL77 2012-10-17
  • 打赏
  • 举报
回复
把那个表的DBCC SHOWCONTIG(TB)给结果.
shoppo0505 2012-10-17
  • 打赏
  • 举报
回复
这个增加的空间可能用到index, constrain上了,重新整理一下index看看有没有用。
开启时代 2012-10-17
  • 打赏
  • 举报
回复
例子:DBCC SHRINKFILE (N'TEST' , 2)
收缩数据库TEST 到2M大小。
应该可以收缩。
lighting_pig 2012-10-17
  • 打赏
  • 举报
回复
上网查了一下,不知道是说如果数据库只有一个文件还是什么原因dbcc shrinkfile不起作用
我试了一下dbcc shrinkfile确实不起作用
汤姆克鲁斯 2012-10-17
  • 打赏
  • 举报
回复
定时进行收缩啊

dbcc shrinkfile

34,575

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧