Switching Table Partitions
One of the great features
of table partitions is that they enable you to instantly swap the
contents of one partition to an empty table, the contents from a
partition on one table to a partition in another table, or an entire
table’s contents into another table’s empty partition. This operation
performs changes only to metadata in the system catalogs for the
affected tables/partitions, with no actual physical movement of data.
For you to switch data from a partition to a table or from a table into a partition, the following criteria must be met:
The source table and
target table must both have the same structure (that is, the same
columns in the same order, with the same names, data types, lengths,
precisions, scales, nullabilities, and collations). The tables must also
have the same primary key constraints and settings for ANSI_NULLS and QUOTED_IDENTIFIER.
The source and target of the ALTER TABLE...SWITCH statement must reside in the same filegroup.
If
you are switching a partition to a single, nonpartitioned table, the
table receiving the partition must already be created, and it must be
empty.
If you are
adding a table as a partition to an already existing partitioned table
or moving a partition from one partitioned table to another, the
receiving partition must exist, and it must be empty.
If you are switching a partition from one partitioned table to another, both tables must be partitioned on the same column.
The source must have all the same indexes as the target, and the indexes must also be in the same filegroup.
If
you are switching a nonpartitioned table to a partition of an already
existing partitioned table, the nonpartitioned table must have a
constraint defined on the column corresponding to the partition key of
the target table to ensure that the range of values fits within the
boundary values of the target partition.
If the target table has any FOREIGN KEY
constraints, the source table must have the same foreign keys defined
on the corresponding columns, and those foreign keys must reference the
same primary keys that the target table references.
If you are switching a partition
of a partitioned table to another partitioned table, the boundary
values of the source partition must fit within those of the target
partition. If the boundary values do not fit, a constraint must be
defined on the partition key of the source table to make sure all the
data in the table fits into the boundary values of the target partition.
Caution
If the tables have IDENTITY columns, partition switching can result in the introduction of duplicate values in IDENTITY columns of the target table and gaps in the values of IDENTITY columns in the source table. You can use DBCC_CHECKIDENT to check the identity values of tables and correct them if necessary.
When you switch a
partition, data is not physically moved. Only the metadata information
in the system catalogs indicating where the data is stored is changed.
In addition, all associated indexes are automatically switched, along
with the table or partition.
To switch table partitions, you use the ALTER TABLE command:
ALTER TABLE table_name SWITCH [ PARTITION source_partition_number_expression ]
TO target_table [ PARTITION target_partition_number_expression ]
You can use the ALTER TABLE...SWITCH
command to switch an unpartitioned table into a table partition, switch
a table partition into an empty unpartitioned table, or switch a table
partition into another table’s empty table partition. The code shown in Listing 5 creates a table to hold the data from the 2006 partition and then switches the 2006 partition from the sales_big_partitioned table to the new table.
Listing 5. Switching a Partition to an Empty Table
CREATE TABLE dbo.sales_big_2006(
sales_id int IDENTITY(1,1) NOT NULL,
stor_id char(4) NOT NULL,
ord_num varchar(20) NOT NULL,
ord_date datetime NOT NULL,
qty smallint NOT NULL,
payterms varchar(12) NOT NULL,
title_id dbo.tid NOT NULL
) ON '2006_data' -- required in order to switch the partition to this table
go
alter table sales_big_partitioned
switch partition $PARTITION.SalesBigPF1 ('1/1/2006')
to sales_big_2006
go
|
Note that Listing 5 uses the $PARTITION
function. You can use this function with any partition function name to
return the partition number that corresponds with the specified
partitioning column value. This prevents you from having to query the
system catalogs to determine the specific partition number for the
specified partition value.
You can run the query from Listing 4 to show that the 2006 partition is now empty:
partition_scheme partition_number filegroup range_boundary rows
---------------- ---------------- ---------- ------------------- ---------
SalesBigPS1 1 Older_Data 30
SalesBigPS1 2 2006_Data 2006-01-01 00:00:00 0
SalesBigPS1 3 2007_Data 2007-01-01 00:00:00 616450
SalesBigPS1 4 2008_Data 2008-01-01 00:00:00 457210
SalesBigPS1 5 2009_Data 2009-01-01 00:00:00 0
SalesBigPS1 6 2010_Data 2010-01-01 00:00:00 0
Now that the 2006 data partition is empty, you can merge the partition without incurring the I/O cost of moving the data to the Older_data partition:
ALTER PARTITION FUNCTION SalesBigPF1 () merge RANGE ('1/1/2006')
Rerunning the query in Listing 24.22 now returns the following result set:
partition_scheme partition_number filegroup range_boundary rows
---------------- ---------------- ---------- ------------------- ---------
SalesBigPS1 1 Older_Data 30
SalesBigPS1 2 2007_Data 2007-01-01 00:00:00 616450
SalesBigPS1 3 2008_Data 2008-01-01 00:00:00 457210
SalesBigPS1 4 2009_Data 2009-01-01 00:00:00 0
SalesBigPS1 5 2010_Data 2010-01-01 00:00:00 0
To demonstrate switching a table into a partition, you can update the date for all the rows in the sales_big_2006 table to 2009 and switch it into the 2009 partition of the sales_big_partitioned table. Note that before you can do this, you need to copy the data to a table in the 2009_data filegroup and also put a check constraint on the ord_date column to make sure all rows in the table are limited to values that are valid for the 2009_data partition. Listing 6 shows the commands you use to create the new table and switch it into the 2009 partition of the sales_big_partitioned table.
Listing 6. Switching a Table to an Empty Partition
CREATE TABLE dbo.sales_big_2009(
sales_id int IDENTITY(1,1) NOT NULL,
stor_id char(4) NOT NULL,
ord_num varchar(20) NOT NULL,
ord_date datetime NOT NULL
constraint CK_sales_big_2009_ord_date
check (ord_date >= '1/1/2009' and ord_date < '1/1/2010'),
qty smallint NOT NULL,
payterms varchar(12) NOT NULL,
title_id dbo.tid NOT NULL
) ON '2009_data' -- required to switch the table to the 2009 partition
go
set identity_insert sales_big_2009 on
go
insert sales_big_2009 (sales_id, stor_id, ord_num,
ord_date, qty, payterms, title_id)
select sales_id, stor_id, ord_num,
dateadd(yy, 3, ord_date),
qty, payterms, title_id
from sales_big_2006
go
set identity_insert sales_big_2009 off
go
alter table sales_big_2009
switch to sales_big_partitioned
partition $PARTITION.SalesBigPF1 ('1/1/2009')
go
|
Rerunning the query from Listing 4 now returns the following result:
partition_scheme partition_number filegroup range_boundary rows
---------------- ---------------- ---------- ------------------- ---------
SalesBigPS1 1 Older_Data 30
SalesBigPS1 2 2007_Data 2007-01-01 00:00:00 616450
SalesBigPS1 3 2008_Data 2008-01-01 00:00:00 457210
SalesBigPS1 4 2009_Data 2009-01-01 00:00:00 613560
SalesBigPS1 5 2010_Data 2010-01-01 00:00:00 0
Tip
Switching
data into or out of partitions provides a very efficient mechanism for
archiving old data from a production table, importing new data into a
production table, or migrating data to an archive table. You can use SWITCH
to empty or fill partitions very quickly. As you’ve seen in this
section, split and merge operations occur instantaneously if the
partitions being split or merged are empty first. If you must split or
merge partitions that contain a lot of data, you should empty them first
by using SWITCH before you perform the split or merge.
