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

Question

我说的是数据文件，不是日志文件
日志文件我知道怎么干掉
数据文件一天可以增加几百兆。。频繁删除的那个表 unused一天加个几百兆没问题
数据库收缩好像没用，shrinkdatebase之类的命令也没用，重建索引页没用
上网一查，大家都说要先把数据copy走，然后TRUNCATE ，然后把数据移回来，个人觉得这个挺恶心的，请问有啥更好的办法不？

Answer 1

定时进行收缩啊dbcc shrinkfile

Answer 2

上网查了一下，不知道是说如果数据库只有一个文件还是什么原因dbcc shrinkfile不起作用
我试了一下dbcc shrinkfile确实不起作用

Answer 3

例子：DBCC SHRINKFILE (N'TEST' , 2)
     收缩数据库TEST 到2M大小。
应该可以收缩。

Answer 4

这个增加的空间可能用到index, constrain上了，重新整理一下index看看有没有用。

Answer 5

把那个表的DBCC SHOWCONTIG(TB)给结果.

Answer 6

试了一下，发现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)我还没试，等明天多了几百兆再试这个命令看是不是可以只要运行一次...

Answer 7

无论是日志文件还是数据文件，由于DBCC SHRINKFILE 是作用在区而不是页上，如果你的数据分布零碎，那是无效的，重建/创建聚集索引，然后在DBCC SHRINKFILE，如果这个无效，把数据copy走，然后TRUNCATE ，然后把数据移回来这个是可行的，不恶心，微软技术支持都是这样说的。

Answer 8

库大的话不建议一次性缩的太小，严重耗费I/O资源。特别在运行期间，一边收缩一边又要涨。你可以100M或者1G这样收缩。反而快一点

Answer 9

这样是有道理的，确实不能一次性收缩比率太大，避免可能引起的收缩故障。
先把数据copy走，然后TRUNCATE ，然后把数据移回来，个人觉得这个挺恶心的。其实这个也是一个没有办法的办法

Answer 10

这个不是一次收缩一点点因为日志的空间可能被其他用户正在使用，所以就会看不到效果
过一会在执行一个命令可能就有效果了更科学的方法是使用while 里面加一个 waitefor

Answer 11

今天来汇报一下，DBCC SHRINKFILE (N'TEST' , 2)这个命令和DBCC SHRINKFILE（1）一样也是一次只收缩一点点，不是真的一次到位，不过，也一样搞个循环多运行几次就可以搞定。现在明白了，之所有很多人说只能先把数据copy走，然后TRUNCATE ，然后把数据移回来，不能用DBCC SHRINKFILE 估计都是遇到了和我一样类似的问题，这个命令一次只能释放出一点点空间，如果不循环个几十上百次那是没效果的。楼上说的先断开服务再收缩这是不行的，因为很多系统不能停的。搞定结贴。

Answer 12

删除语句,不要用delete,而是TRUNCATE .

Answer 13

昨天DBCC SHRINKFILE还可以，现在循环来搞不行了，原因不明。。估计还是有人用表的原因或其他未知问题。看起来这个世界唯一的正确办法就是 把数据copy走，然后TRUNCATE ，然后把数据移回来？？

Answer 14

试了一下，还是应该把主键改成聚集索引，
然后定时任务，每晚重建聚集索引，然后DBCC SHRINKFILE