[新年好]新年第一贴,关于新增分区过程中遇到的问题

大家新年好,新的一年又到了,对于DBA来讲,跨月和跨年最需要关注的就是和年月日相关的一些规则规范了.

果不其然,新年上班第一天发现有个数据库的分区方案设置错误,虽然没有影响正常使用,但是差点出大事(原因后附).

事件起因:

　　由于某些业务需求,有一个库建立了分区,按照CreateDate分区,每天一个分区文件,每个文件大约存放20GB的数据.

　　新建时间为15年4月,当时直接把分区方案建到了年底(12月31日).然而没有做记录(这部分特别注意,很多不该发生的小问题都是由于没有记录导致遗漏的)

　　上班第一天,出于习惯,撸了一遍所有有分区的库. 果然发现了问题.

处理过程:

　　第一时间判断业务系统是否出问题,但应该没有太大影响,否则元旦肯定不安生.

　　着手添加相关分区方案(代码如下)

　　第一步,新增分区文件组及对应分区文件

declare @fg nvarchar(10);
declare @sd datetime;
declare @ed datetime;
declare @fd datetime;
declare @sql nvarchar(2000);
set @sd = '2016-01-05';
set @ed = '2016-05-01';
set @fd = @sd;
while @fd < @ed
begin
set @fg = CONVERT(nvarchar(10),@fd,120)
--print @fg;
SET @sql = 'ALTER PARTITION SCHEME [PartitionDB_SCHEME]
NEXT USED [PartitionDB_FG-' + @fg + '];'+
'ALTER PARTITION FUNCTION [parfunDay]()
SPLIT RANGE ('''+ @fg +''')';
print @sql;
exec (@sql);
set @fd = DATEADD(d,1,@fd);
end

View Code
执行完成后原先存在错误分区文件中的数据会开始重新应用分区方案,所以磁盘的IO会占用很高,需要特别注意.

特别注意:

　　大家可以看到上面两步的循环逻辑完全一致,理论上是可以放到一段代码中去执行,但我建议仍然分两步去运行.

　　原因是第一步至新增文件组和文件,不影响业务系统的正常使用,所以很快就能执行完毕.

　　第二步执行过程中由于业务系统仍然在往数据库中写数据,同时分区方案的修改将影响数据写入的位置,因此在执行过程中会产生较多的阻塞.所以第二步建议放到业务低峰期去执行.

PS:

　　虽然1月1日的分区方案没有了,但是新的数据是不会丢失的,因为分区方案指定的是左边界(当然也可以指定右边界,这都是看你自己分区方案怎么写的了)

　　调整分区方案后符合分区方案的数据会逐渐移动到对应的分区文件上,因此初开始分区数据是不准确的,待分区方案应用完毕后才能正式使用.

　　所以,这种坑爹的事情还是设置定期JOB来执行吧.相关的分区方案设置记录也不能少~~

补:

　　最开始说差点出大事,这个事情就是,由于业务需求,会有定期归档(滑动分区后truncate),而旧的分区方案最晚一个是左边界到2015-12-31的,所以所有新的数据都存在最后一个分区文件中,如果再晚一段时间,那么最后一个分区文件将被滑动后删除.然后就粗大事了!!!

补个代码:

　　删除分区的代码,执行后分区方案和分区函数中对应的分区都没有了.

　　如果分区中有数据会按照分区方案去进行合并(左边界或者右边界)如果不符合则存放到primary文件组中

ALTER PARTITION FUNCTION [parfunDay]()
MERGE RANGE ('2016-01-04')