MSSQL 有一张千万条记录数据表

1.MSSQL  单表数据量为3千万+   已做复制

现在想删除2014年之前的记录大约2千万多条记录

2.删除完数据后做收缩，会不会影响到正常运营，大约能收缩50G

生产库不能停机
求合理解决办法

30 个解决方案

#1

我最近在做类似的，删除数据不能一次性删除，死定的，我这边有时间列，我是每个月一次来删除，当然，删除前要做完整备份。复制方面不用做什么，收缩也是，不要一次性收缩，一次100M左右，虽然次数多，但是影响面小，另外就是服务器闲时操作

#2

简单来说，就是把每次的量减少，次数反正不急的话多一点也没所谓，我这边是做归档操作，已经把需要归档的数据插入一个归档表，所以删除操作不需要一次性或者短期内执行，我每天删里面的一个月数据，一下子就搞完了。

#3

另外由于做了复制，不能truncate，所以会比较慢，不然把“不能删除”的数据insert 到一个表，然后truncate源表，再插回去就完事了

#4

引用 1 楼 DBA_Huangzj 的回复:

我最近在做类似的，删除数据不能一次性删除，死定的，我这边有时间列，我是每个月一次来删除，当然，删除前要做完整备份。复制方面不用做什么，收缩也是，不要一次性收缩，一次100M左右，虽然次数多，但是影响面小，另外就是服务器闲时操作

我删除的时候想把数据库切换到简单模式，不让记录LOG，不知道会不会有影响到复制（我服务器磁盘有点紧张）
一次100M左右，大概收缩要多久啊？

#5

你的数据量也挺大的了，建议：

1.不要一次删除，而是最好要分批删除，比如一次删除1个月的

2.最好在晚上的维护时间内删除，如果在白天删除，可能导致严重的阻塞问题。

3.像这种删除，速度肯定不会快，所以建议把这个表，按照日期字段，改为分区表，这样可以每个月一个分区，到时候要删除，只需要一个一个分区删除就可以了，删除的速度是秒级别的，速度非常快，而且也方便进行历史数据的迁移

#6

引用 3 楼 DBA_Huangzj 的回复:

另外由于做了复制，不能truncate，所以会比较慢，不然把“不能删除”的数据insert 到一个表，然后truncate源表，再插回去就完事了

一开始我也想这样做，先把要操作的表移除复制  insert into  truncate table   之后在把表加到复制  
这样做有一个风险就是有可能会影响到库的复制报错    这个库从新做复制要好久好久   所以就把这个想法PASS了

#7

引用 4 楼 lovezhunuonuo 的回复:

Quote: 引用 1 楼 DBA_Huangzj 的回复:

我最近在做类似的，删除数据不能一次性删除，死定的，我这边有时间列，我是每个月一次来删除，当然，删除前要做完整备份。复制方面不用做什么，收缩也是，不要一次性收缩，一次100M左右，虽然次数多，但是影响面小，另外就是服务器闲时操作

我删除的时候想把数据库切换到简单模式，不让记录LOG，不知道会不会有影响到复制（我服务器磁盘有点紧张）
一次100M左右，大概收缩要多久啊？

应该是没什么影响的。

#8

引用 5 楼 yupeigu 的回复:

你的数据量也挺大的了，建议：

1.不要一次删除，而是最好要分批删除，比如一次删除1个月的

2.最好在晚上的维护时间内删除，如果在白天删除，可能导致严重的阻塞问题。

3.像这种删除，速度肯定不会快，所以建议把这个表，按照日期字段，改为分区表，这样可以每个月一个分区，到时候要删除，只需要一个一个分区删除就可以了，删除的速度是秒级别的，速度非常快，而且也方便进行历史数据的迁移

没有做过表分区，分区的时候会不会影响到在线运营数据，有没有类似的例子给我看看。谢谢

#9

引用 4 楼 lovezhunuonuo 的回复:

Quote: 引用 1 楼 DBA_Huangzj 的回复:

我最近在做类似的，删除数据不能一次性删除，死定的，我这边有时间列，我是每个月一次来删除，当然，删除前要做完整备份。复制方面不用做什么，收缩也是，不要一次性收缩，一次100M左右，虽然次数多，但是影响面小，另外就是服务器闲时操作

我删除的时候想把数据库切换到简单模式，不让记录LOG，不知道会不会有影响到复制（我服务器磁盘有点紧张）
一次100M左右，大概收缩要多久啊？

不能这样做，做了复制不能换模式，100M，如果没阻塞，1分钟左右吧

#10

引用 6 楼 lovezhunuonuo 的回复:

Quote: 引用 3 楼 DBA_Huangzj 的回复:

另外由于做了复制，不能truncate，所以会比较慢，不然把“不能删除”的数据insert 到一个表，然后truncate源表，再插回去就完事了

一开始我也想这样做，先把要操作的表移除复制  insert into  truncate table   之后在把表加到复制  
这样做有一个风险就是有可能会影响到库的复制报错    这个库从新做复制要好久好久   所以就把这个想法PASS了

慢慢删

#11

引用 8 楼 lovezhunuonuo 的回复:

Quote: 引用 5 楼 yupeigu 的回复:

你的数据量也挺大的了，建议：

1.不要一次删除，而是最好要分批删除，比如一次删除1个月的

2.最好在晚上的维护时间内删除，如果在白天删除，可能导致严重的阻塞问题。

3.像这种删除，速度肯定不会快，所以建议把这个表，按照日期字段，改为分区表，这样可以每个月一个分区，到时候要删除，只需要一个一个分区删除就可以了，删除的速度是秒级别的，速度非常快，而且也方便进行历史数据的迁移

没有做过表分区，分区的时候会不会影响到在线运营数据，有没有类似的例子给我看看。谢谢

既然你要删数据，就没必要做分区了。做了分区要重整复制，更麻烦

#12

引用 9 楼 DBA_Huangzj 的回复:

Quote: 引用 4 楼 lovezhunuonuo 的回复:

Quote: 引用 1 楼 DBA_Huangzj 的回复:

我最近在做类似的，删除数据不能一次性删除，死定的，我这边有时间列，我是每个月一次来删除，当然，删除前要做完整备份。复制方面不用做什么，收缩也是，不要一次性收缩，一次100M左右，虽然次数多，但是影响面小，另外就是服务器闲时操作

我删除的时候想把数据库切换到简单模式，不让记录LOG，不知道会不会有影响到复制（我服务器磁盘有点紧张）
一次100M左右，大概收缩要多久啊？

不能这样做，做了复制不能换模式，100M，如果没阻塞，1分钟左右吧

那我删除会记录大批log啊，不知道磁盘能不能顶住

#13

引用 12 楼 lovezhunuonuo 的回复:

Quote: 引用 9 楼 DBA_Huangzj 的回复:

Quote: 引用 4 楼 lovezhunuonuo 的回复:

Quote: 引用 1 楼 DBA_Huangzj 的回复:

我最近在做类似的，删除数据不能一次性删除，死定的，我这边有时间列，我是每个月一次来删除，当然，删除前要做完整备份。复制方面不用做什么，收缩也是，不要一次性收缩，一次100M左右，虽然次数多，但是影响面小，另外就是服务器闲时操作

我删除的时候想把数据库切换到简单模式，不让记录LOG，不知道会不会有影响到复制（我服务器磁盘有点紧张）
一次100M左右，大概收缩要多久啊？

不能这样做，做了复制不能换模式，100M，如果没阻塞，1分钟左右吧

那我删除会记录大批log啊，不知道磁盘能不能顶住

这样太容易了，删1天的数据，如果很快，多删几天，或者一个月，然后马上做一个日志备份，磁盘顶得住的，1个月的数据估计产生的日志都不会超过1G，

#14

现在的问题是做了复制，不能换模式，换了后面的问题就多了，做好日志备份即可。备份文件你觉得碍事可以删，前提你要有个完整备份

#15

相信我，我今天才干了个2000多万，有复制的表，没啥问题，这个不是理论，而是实践的建议

#16

引用 14 楼 DBA_Huangzj 的回复:

现在的问题是做了复制，不能换模式，换了后面的问题就多了，做好日志备份即可。备份文件你觉得碍事可以删，前提你要有个完整备份

好的   谢谢昂

#17

引用 15 楼 DBA_Huangzj 的回复:

相信我，我今天才干了个2000多万，有复制的表，没啥问题，这个不是理论，而是实践的建议

2千万是一次干的还是分批处理的

#18

分批，一个月一个月，我这边大概删除一个月的数据（大概100多万）十几分钟吧

#19

DBCC SHRINKFILE (N'testDB_Data' , 91250)  这样写怎么还是收缩很慢的？  不知道你是怎么收缩的啊？

#20

DBCC SHRINKFILE (N'testDB_Data' , 91250) --这个是说收缩到91250M，假设你的文件有100000M，第一次应该为DBCC SHRINKFILE (N'testDB_Data' , 99900)

#21

引用一下回复，不然不知道你回复了

#22

引用 20 楼 DBA_Huangzj 的回复:

DBCC SHRINKFILE (N'testDB_Data' , 91250) --这个是说收缩到91250M，假设你的文件有100000M，第一次应该为DBCC SHRINKFILE (N'testDB_Data' , 99900)

date 源文件：91350   不知道为何收缩到10多分钟还没有完成，我就取消了。

#23

那就晚点吧，可能你的数据库有其他应用在运行

#24

闲时再收缩也行

#25

引用 24 楼 DBA_Huangzj 的回复:

闲时再收缩也行

好的  我明早试试。麻烦了啊 谢谢

#26

嗯，我也试试，谢谢了！

#27

大数据处理都是挺有趣的操作。

#28

#29

#30