Styjun

My partition function creates right range type partitions. It turns out after the data migration that in partition_number one there are boundary values that are lesser than the boundary declared in my partition function. So for example, if my minimum partition key is 5, i found values 1,2,3 and 4 in partition number 1. What i need to do is alter my partition function adding boundaries 1,2,3 and 4.How am i going to do this? Does split range work in this case? How is sql server going to re arrange my data in the new partitions. Will it do the job just by altering the table? Do i need to do something extra? Do i need to take a backup in case something goes wrong?

I guess your situation is the following: you have a right range partition with the lowest boundary value being 5, and a table that is being partitioned that way, e.g.:

create partition function pf (int) as range right for values (5)
create partition scheme ps as partition pf to ([PRIMARY], [PRIMARY])
create table T (part_key int constraint PK_T primary key)
on ps (part_key)

Now, if you enter the values 1, 2, 3, 4, and 5 into table T and check the distribution of values within each partition, you'll find 1, 2, 3 and 4 in partition 1, and 5 in partition 2:

insert T values (1), (2), (3), (4), (5)
select part_key, $partition.pf(part_key) as partition from T

What you need to do to get each value in its own partition is:
- for each new partition add a new destination filegroup, and
- split the partition range starting at highest value

This could look like:

alter partition scheme ps next used [PRIMARY]
alter partition function pf() split range (4)

alter partition scheme ps next used [PRIMARY]
alter partition function pf() split range (3)

alter partition scheme ps next used [PRIMARY]
alter partition function pf() split range (2)

Now, if you check again your value distribution, you'll see that all distinct values end up in a separate partition:

select part_key, $partition.pf(part_key) as partition from T

But, be aware that this goes along with data movement, i.e. all rows with partition key values 1-4 need to be physically moved from original partition 2 to their new destination partition. So, if there are millions of such rows, this'll take some time and will blow up your transaction log.