Création de partitions pour gérer les sous-ensembles de données

Article
12/15/2008

En partitionnant une table ou un index, vous pouvez déplacer rapidement et efficacement des sous-ensembles de données à l'aide de l'instruction Transact-SQL ALTER TABLE...SWITCH des manières suivantes :

ajout d'une table en tant que partition à une table partitionnée existante ;
basculement d'une partition d'une table partitionnée vers une autre ;
suppression d'une partition pour constituer une table unique.

Ces scénarios peuvent être utiles si vous souhaitez ajouter de nouvelles données à une table partitionnée et supprimer régulièrement d'anciennes données de la même table partitionnée. Cette opération peut impliquer une quantité de données variable dans divers scénarios. Si les nouvelles données que vous ajoutez doivent être chargées, purgées ou transformées, elles peuvent être traitées comme une entité distincte avant leur ajout en tant que partition. Les anciennes données peuvent être archivées ou mises en entrepôt. Quel que soit le volume de la collection, le transfert est rapide et efficace, car contrairement à une instruction INSERT INTO SELECT FROM, les données ne sont pas déplacées physiquement. Seules les métadonnées relatives à leur emplacement de stockage sont modifiées d'une partition à une autre.

Exemple de scénario : AdventureWorks

Dans le scénario de partitionnement de l'exemple de base de données AdventureWorks, Adventure Works Cycles archive ses anciennes données provenant de la table TransactionHistory dans une table TransactionHistoryArchive en commutant les partitions entre les deux tables. Dans ce but, TransactionHistory est partitionné sur le champ TransactionDate. La plage de valeurs de chaque partition est d'un mois. La table TransactionHistory gère les transactions les plus récentes de l'année, alors que TransactionHistoryArchive gère les transactions plus anciennes. En partitionnant les tables de cette manière, les données d'un mois vieilles d'un an peuvent être transférées de TransactionHistory vers TransactionHistoryArchive tous les mois.

Au début de chaque mois, le mois le plus ancien figurant actuellement dans la table TransactionHistory bascule vers la table TransactionHistoryArchive. Pour exécuter cette tâche, les conditions suivantes doivent être remplies :

La table TransactionHistoryArchive doit posséder la même structure de schéma que la table TransactionHistory. Il doit également exister une partition vide destinée à recevoir les nouvelles données. Dans ce cas-ci, TransactionHistoryArchive est une table partitionnée constituée de deux partitions seulement — o. Une partition contient toutes les données antérieures au mois de septembre 2003 et l'autre partition contient toutes les données à partir de septembre 2003. Cette dernière partition est vide.
La fonction de partition de la table TransactionHistoryArchive est modifiée afin de fractionner en deux sa partition vide, une des partitions étant définie pour recevoir la nouvelle partition destinée aux données de septembre 2003.
La première partition de la table TransactionHistory, qui contient toutes les données créées au cours de septembre 2003, bascule dans la deuxième partition de la table TransactionHistoryArchive. Remarquez qu'une contrainte de validation doit être définie sur la table TransactionHistory pour spécifier qu'aucune donnée antérieure au 1er septembre (TransactionDate >= '9/01/2003') ne doit être incluse. Cette contrainte s'assure que la partition 1 contient uniquement les données de septembre 2003 et qu'elle est prête à basculer vers la partition contenant uniquement les données de septembre 2003 de la table TransactionHistoryArchive. Remarquez également que tout index non aligné sur ses tables respectives doit également être supprimé ou désactivé avant le basculement. Il peut toutefois être recréé par la suite. Pour plus d'informations sur l'alignement des index partitionnés, consultez Consignes spéciales pour les index partitionnés.
La fonction de partition de la table TransactionHistory est modifiée pour fusionner ses deux premières partitions en une seule. Cette partition, appelée désormais partition 1, contient toutes les données créées en octobre 2003 et sera prête à basculer vers TransactionHistoryArchive le mois suivant, à condition que la contrainte de validation existante soit modifiée pour spécifier qu'aucune donnée antérieure au 1er octobre (TransactionDate >= '10/01/2003') ne doit être incluse.
La fonction de partition de la table TransactionHistoryArchive est à nouveau modifiée pour fusionner sa deuxième partition, contenant les données du mois de septembre qui viennent d'être ajoutées, avec sa première partition. Cette action rétablit l'état d'origine de la table TransactionHistoryArchive, sa première partition contenant les données et sa deuxième partition étant vide.
La fonction de partition de la table TransactionHistory est à nouveau modifiée pour diviser sa dernière partition en deux, afin que le mois en cours soit séparé du mois précédent et que la partition soit prête à recevoir de nouvelles données.