Transfert efficace de données à l'aide du commutateur de partitionnement
Mis à jour : 12 décembre 2006
Vous pouvez utiliser l'instruction Transact-SQL ALTER TABLE...SWITCH pour transférer rapidement et efficacement des blocs de données des manières suivantes :
- affectation d'une table en tant que partition à une table partitionnée existante ;
- basculement d'une partition d'une table partitionnée vers une autre ;
- réaffectation d'une partition pour constituer une table unique.
Pour obtenir des informations sur les concepts liés au commutateur de partitionnement, consultez Création de partitions pour gérer les sous-ensembles de données. Pour afficher un exemple de code mettant en œuvre le commutateur de partitionnement, consultez Readme_SlidingWindow.
Exigences générales relatives à la commutation de partitions
Lors du transfert d'une partition, vous ne déplacez pas physiquement les données. Vous ne modifiez que les métadonnées indiquant l'emplacement de stockage des données. Cela signifie que la table à partir de laquelle la partition est déplacée (table source) et la table qui reçoit la partition (table cible) doivent toutes les deux exister dans la base de données avant que l'opération SWITCH soit effectuée.
Si vous ajoutez une table en tant que partition à une table partitionnée existante, ou si vous déplacez une partition d'une table partitionnée vers une autre, la partition cible doit exister et être vide.
Si vous réaffectez une partition pour constituer une table unique non partitionnée, la table qui reçoit la partition doit déjà être créée et être vide.
Si vous basculez une partition d'une table partitionnée vers une autre, les deux tables doivent être partitionnées sur la même colonne.
La source et la cible de l'instruction ALTER TABLE...SWITCH doivent résider dans le même groupe de fichiers et leurs colonnes de grandes valeurs doivent être stockées dans ce même groupe. Tout index, ou partition d'index, correspondant doit également résider dans le même groupe de fichiers. Cependant, le groupe de fichiers peut être différent de celui des tables correspondantes ou d'autres index correspondants.
Exigences relatives à la structure des tables et des index
La table source et la table cible doivent posséder la même structure. Par conséquent :
- Elles doivent posséder les mêmes colonnes, portant les mêmes noms, ainsi qu'un type de données, une longueur, un classement, une précision, une échelle, une possibilité de valeur NULL et des contraintes PRIMARY KEY identiques. Elles doivent également posséder les mêmes valeurs pour ANSI_NULLS et QUOTED IDENTIFIER. En outre, les colonnes doivent être définies dans le même ordre. La propriété IDENTITY n'est pas prise en compte.
Attention : L'exécution d'un commutateur de partitionnement peut entraîner l'introduction de doublons dans les colonnes IDENTITY de la table cible, ainsi que des écarts dans les valeurs des colonnes IDENTITY de la table source. Utilisez DBCC CHECKIDENT pour vérifier les valeurs d'identité de vos tables et les corriger le cas échéant. - La possibilité de valeur NULL de leurs colonnes de partitionnement doit être identique. C'est-à-dire que les deux doivent avoir la valeur NULL ou NOT NULL. Si l'une des tables n'est pas partitionnée, la possibilité de valeur NULL de la colonne correspondant à la colonne de partitionnement de l'autre table doit être conforme à la colonne de partitionnement de l'autre table.
Important : Nous vous conseillons de spécifier NOT NULL sur la colonne de partitionnement des tables partitionnées et également des tables non partitionnées qui sont sources ou cibles des opérations ALTER TABLE...SWITCH. Ainsi, vous êtes certain que les contraintes CHECK sur les colonnes de partitionnement ne doivent pas rechercher la présence de valeurs nulles. Les valeurs Null sont généralement placées dans la partition à l'extrême gauche d'une table partitionnée. Lorsque vous changez une partition autre que la partition à l'extrême gauche et lorsque l'option de base de données ANSI_NULLS est définie à ON, l'absence de contrainte NOT NULL sur les tables sources et cibles peut interférer avec les contraintes CHECK qui sont également définies sur la colonne de partitionnement. - Si leurs clés de partition correspondantes sont des colonnes calculées, la syntaxe des expressions définissant leurs colonnes calculées sont identiques et les deux colonnes calculées sont conservées.
- Toute colonne définie à l'aide de la propriété ROWGUID doit correspondre à une colonne contenue dans l'autre table, également définie avec la propriété ROWGUID.
- Toute colonne xml doit être de même type que la même collection de schémas XML.
- Les paramètres des lignes de toute colonne text, ntext ou image sont identiques. Pour plus d'informations sur ce paramètre, consultez Données dans la ligne.
- Les tables possèdent les mêmes index cluster. Ces index ne peuvent pas être désactivés.
- Tout index non-cluster défini sur la table cible est également défini sur la table source et est structuré de manière identique en termes d'unicité, de sous-clés et de sens de tri (ASC ou DESC) pour chaque colonne de clés d'index. Les index non-cluster désactivés ne sont pas concernés par cette exigence.
Exigences relatives aux contraintes
Toute contrainte CHECK définie sur la table cible est également définie sur la table source, soit en tant que correspondance exacte, soit d'une manière applicable à la contrainte CHECK de la table cible.
Par exemple, si la table cible possède une contrainte sur une colonne intColumn1 qui spécifie Column1 < 100, la colonne Column1 correspondante de la table source doit posséder la même contrainte ou une contrainte dont les valeurs sont un sous-ensemble des contraintes de la table cible (par exemple Column1 < 90). Les contraintes CHECK spécifiant plusieurs colonnes doivent être définies à l'aide de la même syntaxe.
Si vous ajoutez une table non partitionnée en tant que partition à une table partitionnée existante, il doit exister une contrainte définie sur la colonne de la table source qui correspond à la clé de partition de la table cible. Cela permet de garantir que la plage de valeurs sera comprise dans les valeurs limites de la partition cible.
Si vous basculez une partition d'une table partitionnée vers une autre table partitionnée, les valeurs limites de la partition source doivent être comprises dans celles de la partition cible. Si ce n'est pas le cas, il doit exister une contrainte définie sur la clé de partition de la table source afin de s'assurer que toutes les données de la table sont comprises dans les valeurs limites de la partition cible.
Attention : |
---|
Évitez toute conversion de type de données dans les définitions de contraintes. Les contraintes qui comprennent une conversion de type de données implicite ou explicite et sont définies sur les tables à la source de la commutation de partitionnement, peuvent entraîner l'échec de ALTER TABLE...SWITCH. |
Si la table cible possède des contraintes FOREIGN KEY, la table source doit disposer des clés étrangères définies dans les colonnes correspondantes, et ces clés étrangères doivent faire référence à la même clé primaire que celles de la table cible. Les clés étrangères de la table source ne peuvent pas être marquées is_not_trusted (visibles dans l'affichage catalogue sys.foreign_keys), à moins que la clé étrangère correspondante de la table cible soit également marquée is_not_trusted. Pour plus d'informations sur ce paramètre, consultez Recommandations pour la désactivation des index. SQL Server applique toute règle CASCADE définie sur les clés étrangères de la table cible à la partition que vous venez de déplacer.
Exigences supplémentaires relatives au déplacement de partitions
Les exigences supplémentaires suivantes doivent également être respectées lors du déplacement de partitions :
- Tout index de la table source ou de la table cible doit être aligné sur la table, que seule l'une des deux soit partitionnée ou qu'elles le soient toutes les deux.
- Il ne peut exister aucun index de texte intégral, ni sur la table source, ni sur la table cible.
- Il ne peut exister aucun index XML sur la table cible.
- Il ne peut exister aucune relation de clé étrangère/primaire active entre la table source et la table cible dans laquelle la table source contient la clé primaire.
- Il ne peut exister aucune relation de clé étrangère/primaire active entre la table source et la table cible dans laquelle la table cible contient la clé étrangère.
- La table source ne peut pas être référencée par une clé étrangère contenue dans une autre table.
- La table source et la table cible ne peuvent pas participer à une vue avec une liaison de schéma. Par conséquent, vous ne pouvez pas définir de vues d'index sur celles-ci.
- Il ne peut exister aucune règle définie sur la table source ou sur la table cible.
Remarque : Les règles constituent une fonction de compatibilité ascendante. L'implémentation par défaut consiste à utiliser des contraintes CHECK. Pour connaître les restrictions applicables dans le cadre des contraintes CHECK, consultez la section Exigences relatives aux contraintes plus haut dans cette rubrique. - Ni la table source, ni la table cible ne peuvent être des sources de réplication.
- Une commutation de partitionnement exige l'exécution d'une instruction ALTER TABLE. Par conséquent, vous devez disposer des autorisations de base de données requises associées à l'instruction ALTER TABLE. Le jeu d'autorisations de la table source et de la table cible ne doivent pas être identiques.
Aucun déclencheur INSERT, UPDATE ou DELETE ou encore aucune action en cascade n'est activée en déplaçant les partitions de table, et les tables sources ou cibles ne doivent pas nécessairement posséder des déclencheurs définis de la même manière pour déplacer des partitions.
Remarque : |
---|
En exécutant une opération ALTER TABLE…SWITCH, un verrou de modification du schéma est acquis sur les tables sources et cibles pour s'assurer qu'aucune autre connexion ne fait référence aux métadonnées des tables lors de la modification. Pour plus d'informations sur les verrous, consultez Modes de verrouillage. |
Pour déplacer des partitions de table
Voir aussi
Concepts
Création de partitions pour gérer les sous-ensembles de données
Autres ressources
DBCC CHECKIDENT (Transact-SQL)
ALTER PARTITION FUNCTION (Transact-SQL)
ALTER PARTITION SCHEME (Transact-SQL)
Readme_SlidingWindow
Aide et Informations
Assistance sur SQL Server 2005
Historique des modifications
Version | Historique |
---|---|
12 décembre 2006 |
|
14 avril 2006 |
|