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

2012-10-17 06:01:05 218 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

数据挖掘之Apriori频繁项集挖掘本文的代码文件原件可以在我们的 "数据臭皮匠" 中输入"第六章1" 拿到 1.基本概念介绍频繁项集和关联规则的挖掘首先需要了解一些概念, 如支持度, 置信度, 事务,事务集,项,项集, 频繁项集等, 首先介绍下基本的概念定义(以下为笔者的简单化理解, 更严谨的定义请参考书中内容): 首先假设我们有一个由多行多列组成的表格事务: 可以将事务简单理解为表格的其中一行事务集:一个表格会有多行, 这个包括多个事务的集合就叫事务集项:表格中每一行会包括多个值, 每一个值就是一个项项集:多个项组阅读详情

我说的是数据文件，不是日志文件
日志文件我知道怎么干掉
数据文件一天可以增加几百兆。。

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

...全文

Big Key 导致 Redis 频繁重连的问题排查背景监控是系统的重要模块，我们给产线的 Redis 机器配置了全方位的监控，包括机器性能指标测试以及 Redis 服务测试等等。今天收到了 PagerDuty 告警，报告说 Redis 服务间歇性异常。问题描述 Redis 是一个集群，三主三从，每个节点各配置了一个监控，监控的测试逻辑大致是，用 INFO，CLUSTER SLOTS，CLUSTER NODES 等命令查看节点以及集群的基本信息是否正常，然后给主节点（master） set 一个 dummy key，看是否在规定时间内能同步到从节点（sl 阅读详情

lighting_pig

MS-SQL Server 34,876 成员 254,635 内容

+ 关注 + 加入社区

切换为时间正序

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

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

相关推荐