1.L_Monitoring有这么些字段,ID,Collecttime,PlateType,PlateNO以及其他一些这段.
建立这个表的时候是个非分区表,其中ID是主键,并在Collecttime,PlateType,PlateNO上面建立了索引.
2.系统运行一阵子后,L_Monitoring数据变得非常大,5,6千万,而且后续还会更大.
所以要求将L_Monitoring表进行分区.分区方案是按照Collecttime进行每天分区.
Collecttime为分区字段,并将Collecttime字段改为聚集索引,原来主键ID改为非聚集索引.
请注意这个步骤:L_Monitoring表我是先建立索引,在建立分区;
3.系统要求清除三个月前的数据,只保留最近3个月的数据.所以,系统运行一阵子(3个月)后就需要清除数据.
加了JOB每天晚上从L_Monitoring删除数据,发现每天晚上数据库会在JOB执行删除的时候卡死.
或者说,每天晚上执行job的时候,对L_Monitoring表的操作会阻塞.
语句如下:delete L_Monitoring where Collecttime< '3个月前'
4.所以清除数据方法必须更改,不可单纯的用delete.所以改为SWITCH PARTITION的方法来删除数据.
这个方法的原理就是:
a.先建立一个和L_Monitoring结构一样的表:L_Monitoring_SwitchOut(L_Monitoring_SwitchOut这表我先用Collecttime分区,然后建立索引,请注意这个先后关系)
b.用ALTER TABLE L_Monitoring SWITCH PARTITION x TO L_Monitoring_SwitchOut PARTITION x语句将某一个分区的数据移动到L_Monitoring_SwitchOut,这个步骤是瞬时完成的
c.truncate table L_Monitoring_SwitchOut
所以,这种方法删除数据,按理说,会很快的.
5.可是ALTER TABLE L_Monitoring SWITCH PARTITION的时候,报错如下:
'ALTER TABLE SWITCH' statement failed. The table 'ITMP2.dbo.L_Monitoring' is partitioned while index 'IX_L_Monitoring_ID' is not partitioned.
其实这个错误提示得很明显了,index is not partitioned(索引没有分区),但是我当时没有搞清楚原理,所以导致各种实验.
原理就是:表的数据可以存不同分区,索引一样可存不同分区.
哎,我搞了好久,查了好多资料.
开始觉得有其他索引的表不能SWITCH,还试了SWITCH之前把索引删除,再SWITCH,然后recreate索引这种方法,这种方法可以swtich成功,但是每次recreate的时候也会阻塞.
最后各种实验终于发现在L_Monitoring表删除索引在recreate后,就可以swtich了.
好吧,可能你没看懂,为什么在索引第一次recreate后,就可以了呢.下面来解答:
1.表在建立索引的时候,如果表是分区表,则索引默认在分区上.
2.如果先建立索引,再分区,索引则在primary上;
所以,上面我步骤中,导致L_Monitoring和L_Monitoring_SwitchOut其实不同的,一个的索引在primary上,一个的索引在分区上.
明白了原理就好了,在上面第5步的时候, SWITCH之前,把PlateType,PlateNO,ID的索引删除在重建(只执行一次)就可以了.(或者利用stutio更改索引的stroage),重新建立的索引会在分区上,而L_Monitoring_SwitchOut的索引也是在分区后建立的,所以索引也存在分区上的.这样,2个表的结构才一模一样了,可以swtich了!
没代码和脚本,全文字,慢慢看吧,希望大家有帮助.
关键字:分区 delete 数据 卡死 分区表