Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
SQL ServerAzure SQL Managed Instance
La réplication prend en charge une grande variété de modifications de schéma pour les objets publiés. Quand vous effectuez une des modifications de schéma suivantes dans l’objet publié approprié sur un Abonné Microsoft SQL Server, cette modification est propagée par défaut sur tous les Abonnés SQL Server :
ALTER TABLE
ALTER TABLE SET LOCK ESCALATIONne doit pas être utilisé si la réplication des changements de schéma est activée et qu'une topologie inclut SQL Server 2005 (9.x) ou SQL Server Compact 3.5 Subscribers.ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGERpeut être utilisé uniquement pour les déclencheurs du langage de manipulation de données (DML) car les déclencheurs du langage de définition de données (DDL) ne peuvent pas être reproduits.
Important
Vous devez effectuer des modifications de schéma dans les tables en utilisant Transact-SQL ou SQL Server Objets de Gestion (SMO). Lorsque vous modifiez le schéma dans SQL Server Management Studio, Management Studio tente de supprimer et de recréer la table. Vous ne pouvez pas supprimer les objets publiés, donc le changement de schéma échoue.
Dans le cas de la réplication transactionnelle ou de fusion, les modifications de schéma sont propagées de manière incrémentielle lors de l'exécution de l'Agent de distribution ou de fusion. Avec la réplication d'instantané, les modifications de schéma sont propagées lors de l'application d'un nouvel instantané sur l'Abonné. Dans la réplication par instantané, une nouvelle copie du schéma est envoyée à l'abonné à chaque synchronisation. Par conséquent, tous les changements de schéma (pas seulement ceux listés précédemment) vers les objets précédemment publiés sont automatiquement propagés à chaque synchronisation.
Pour obtenir des informations sur l’ajout et la suppression d’articles dans les publications, consultez Ajouter et supprimer des articles de publications existantes.
Pour répliquer les modifications de schéma
Les modifications de schéma mentionnées précédemment sont reproduites par défaut. Pour plus d'informations sur la désactivation de la réplication des modifications de schéma, consultez Replicate Schema Changes.
Considérations concernant les modifications de schéma
Les éléments suivants doivent être pris en compte lors de la réplication des modifications de schéma.
Considérations d’ordre général
Les modifications de schéma sont soumises aux restrictions imposées par Transact-SQL. Par exemple,
ALTER TABLEcela ne permet pas de modifier les colonnes clés primaires.La correspondance des types de données ne se fait que pour l’instantané initial. Les modifications de schéma ne correspondent pas aux versions précédentes des types de données. Par exemple, si vous utilisez
ALTER TABLE ADD datetime2 columnSQL Server 2012 (11.x), le type de donnée ne se traduit pas par nvarchar pour les abonnés SQL Server 2005 (9.x). Dans certains cas, les modifications du schéma sont bloquées au niveau de l’éditeur.Si vous définissez une publication pour permettre la propagation des changements de schéma, elle propage les changements de schéma indépendamment de la manière dont vous définissez l’option de schéma associée à un article dans la publication. Par exemple, si vous choisissez de ne pas répliquer les contraintes de clé étrangère pour un article de type table, puis que vous exécutez une commande
ALTER TABLEqui ajoute une clé étrangère à la table sur le serveur de publication, la clé étrangère est ajoutée à la table sur le serveur d’abonnement. Pour éviter ce comportement, désactivez la propagation des modifications de schéma avant d’émettre laALTER TABLEcommande.Ne modifiez le schéma que chez Publisher, pas chez Abonnés (y compris la republication des Abonnés). La réplication de fusion interdit les modifications de schéma sur l'Abonné, La réplication transactionnelle n’empêche pas les changements, mais ces modifications peuvent provoquer l’échec de la réplication.
Les modifications propagées à un Abonné de republication sont transmises par défaut à ses Abonnés.
Si le changement de schéma fait référence à des objets ou contraintes existant sur le Publisher mais pas sur l’Abonné, le changement de schéma réussit sur le Publisher mais échoue sur l’Abonné.
Tous les objets sur l’Abonné que vous consultez lors de l’ajout d’une clé étrangère doivent avoir le même nom et propriétaire que l’objet correspondant sur le Publisher.
L’ajout, la suppression ou la modification explicite d’index n’est pas reproduite. Vous devez effectuer toute modification impliquant un index explicite sur chaque jeu de réplicas individuellement. Les index créés implicitement pour des contraintes (telles qu'une contrainte de clé primaire) sont pris en charge.
La modification ou la suppression de colonnes d'identité gérées par la réplication ne sont pas prises en charge. Pour plus d’informations sur la gestion automatique des colonnes d’identité, consultez Répliquer des colonnes d’identité.
Les modifications de schéma incluant des fonctions non déterministes ne sont pas prises en charge car elles peuvent entraîner des données différentes au Publisher et à l'abonné (ce qu'on appelle non-convergence). Par exemple, si vous émettez la commande suivante sur le serveur de publication :
ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), les valeurs diffèrent lorsque la commande est répliquée sur l'Abonné, puis exécutée. Pour plus d'informations sur les fonctions non déterministes, consultez Deterministic and Nondeterministic Functions.Nommez explicitement les contraintes. Si vous ne nommez pas explicitement une contrainte, SQL Server génère un nom pour la contrainte, et ces noms sont différents sur le Publisher et chaque abonné. Cette différence peut poser des problèmes lors de la réplication des modifications du schéma. Par exemple, si vous supprimez une colonne au Publisher et qu’une contrainte dépendante est supprimée, la réplication tente de supprimer la contrainte au niveau de l’abonné. La suppression sur l'Abonné échouera car le nom de la contrainte est différent. Si la synchronisation échoue en raison d'un problème de dénomination de contrainte, supprimez manuellement la contrainte sur l'Abonné, puis réexécutez l'Agent de fusion.
Si vous publiez une table pour la réplication, vous ne pouvez pas modifier une colonne de cette table en un type de données XML si vous avez déjà généré un instantané de publication. Pour modifier la colonne, il faut d’abord supprimer la réplication.
Le niveau d’isolation « Read uncommitted » n’est pas pris en charge lors d’une opération DDL sur une table publiée.
N’utilisez SET CONTEXT_INFO pas pour modifier le contexte des transactions où des modifications de schéma sont effectuées sur des objets publiés.
Ajouter des colonnes
Pour ajouter une nouvelle colonne à un tableau et inclure cette colonne dans une publication existante, exécutez
ALTER TABLE <Table> ADD <Column>. Par défaut, la colonne est alors répliquée sur tous les Abonnés. La colonne doit autoriser les valeursNULLou inclure une contrainte par défaut. Pour plus d’informations sur l’ajout de colonnes, consultez la section « Fusion Replication » de cet article.Pour ajouter une nouvelle colonne à un tableau sans inclure cette colonne dans une publication existante, désactivez la réplication des modifications de schéma, puis exécutez
ALTER TABLE <Table> ADD <Column>.Pour inclure une colonne existante dans une publication existante, utilisez sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) ou la boîte de dialogue Propriétés de la publication - <Publication>.
Pour plus d'informations, voir Définir et modifier un filtre de colonne. Cette action nécessite la réinitialisation des abonnements.
L’ajout d’une colonne d’identité à une table publiée n’est pas pris en charge, car cela peut entraîner une non-convergence lorsque la colonne est répliquée à l’abonné. Les valeurs de la colonne d’identité sur le serveur de publication dépendent de l’ordre dans lequel les lignes de la table concernée sont stockées physiquement. Les lignes sont susceptibles d'être stockées différemment sur l'Abonné ; la valeur de la colonne d'identité peut donc être différente pour les mêmes lignes.
Suppression de colonnes
Pour supprimer une colonne d’une publication existante et retirer la colonne du tableau au Publisher, exécutez
ALTER TABLE <Table> DROP <Column>. Par défaut, la colonne est alors supprimée de la table chez tous les abonnés.Pour supprimer une colonne d’une publication existante, tout en la conservant dans la table sur le serveur de publication, utilisez sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) ou la boîte de dialogue Propriétés de la publication - <Publication>.
Pour plus d'informations, voir Définir et modifier un filtre de colonne. Cette action nécessite de générer un nouvel instantané.
Vous ne pouvez pas utiliser la colonne pour insérer les clauses de filtre d’un article ou d’une publication dans la base de données.
Lors de la suppression d’une colonne d’un article publié, prenez en compte les contraintes, index ou propriétés de la colonne pouvant affecter la base de données. Par exemple :
Vous ne pouvez pas supprimer les colonnes utilisées dans une clé primaire des articles dans des publications transactionnelles, car la réplication les utilise.
Vous ne pouvez pas supprimer la
rowguidcolonne des articles dans les publications fusionnées ni lamstran_repl_versioncolonne des articles dans les publications transactionnelles qui supportent la mise à jour des abonnements, car la réplication les utilise.Les modifications de l’index ne sont pas propagées aux abonnés. Si vous supprimez une colonne sur le serveur de publication et qu'un index qui en dépend est supprimé, la suppression de l'index n'est pas répliquée. Vous devez supprimer l’index chez l’Abonné avant de supprimer la colonne sur le serveur de publication, afin que la suppression de la colonne puisse réussir lorsqu’elle est répliquée du serveur de publication vers l’Abonné. Si la synchronisation échoue en raison d'un index sur l'Abonné, supprimez manuellement cet index, puis réexécutez l'Agent de fusion.
Des contraintes de nom explicites pour que vous puissiez les abandonner. Pour plus d’informations, consultez la section « Considérations générales » plus tôt dans cet article.
Réplication transactionnelle
Les modifications de schéma sont propagées aux Abonnés exécutant des versions antérieures de SQL Server, mais l'instruction DDL doit absolument inclure la syntaxe prise en charge par la version installée sur l'Abonné.
Si l'Abonné republie des données, les seules modifications de schéma prises en charge sont l'ajout et la suppression d'une colonne. Effectuez ces modifications sur le Publisher en utilisant sp_repladdcolumn (Transact-SQL) et sp_repldropcolumn (Transact-SQL) plutôt que
ALTER TABLEla syntaxe DDL.Les modifications de schéma ne sont pas répliquées aux abonnés non-SQL Server.
Les modifications de schéma ne sont pas propagées depuis des éditeurs non-SQL Server.
Vous ne pouvez pas modifier les vues indexées qui sont répliquées sous forme de tableaux. Vous pouvez modifier des vues indexées qui sont répliquées en tant que vues indexées, mais le fait de les modifier les transforme en vues ordinaires plutôt qu'en vues indexées.
Si la publication supporte la mise à jour immédiate ou les abonnements à mise à jour en file d’attente, mettez le système en alerte avant d’effectuer des modifications de schéma : arrêtez toute activité sur la table publiée au niveau du Publisher et des Abonnés, et propagez les modifications de données en attente à tous les nœuds. Après que les changements de schéma se propagent à tous les nœuds, l’activité peut reprendre sur les tables publiées.
Si la publication est dans une topologie pair-à-pair, mettez le système en veille avant d’effectuer des modifications de schéma. Pour plus d’informations, consultez Mettre en suspens une topologie de réplication (Programmation Transact-SQL de la réplication).
L’ajout d’une colonne d’horodatage à une table et le mappage de l’horodatage sur
binary(8)entraînent la réinitialisation de l’article pour tous les abonnements actifs.
Réplication de fusion
La manière dont la réplication de fusion gère les modifications de schéma dépend du niveau de compatibilité de la publication et selon que l’instantané est défini en mode natif (par défaut) ou en mode caractères :
Pour reproduire les changements de schéma, réglez le niveau de compatibilité de publication à au moins 90RTM. Si les abonnés utilisent des versions antérieures de SQL Server ou si le niveau de compatibilité est inférieur à 90RTM, utilisez sp_repladdcolumn (Transact-SQL) et sp_repldropcolumn (Transact-SQL) pour ajouter et supprimer des colonnes. Toutefois, ces procédures sont déconseillées.
Si vous essayez d'ajouter à un article existant une colonne avec un type de données qui a été introduit dans SQL Server 2008 (10.0.x), SQL Server présente le comportement suivant :
100RTM, instantané natif 100RTM, instantané en mode caractère Tous les autres niveaux de compatibilité hierarchyid Autoriser la modification Bloquer la modification Bloquer la modification geography et geometry Autoriser la modification Autoriser la modification* Bloquer la modification flux de fichier Autoriser la modification Bloquer la modification Bloquer la modification date, time, datetime2et datetimeoffset Autoriser la modification Autoriser la modification* Bloquer la modification *Les abonnés SQL Server Compact convertissent ces types de données au niveau de l'Abonné.
Si une erreur se produit lors de l'application d'une modification de schéma (par exemple une erreur résultant de l'ajout d'une clé étrangère référençant une table non disponible sur l'Abonné), la synchronisation échoue et l'abonnement doit être réinitialisé.
Si une modification de schéma est apportée à une colonne reprise dans un filtre de jointure ou un filtre paramétré, vous devez réinitialiser tous les abonnements et régénérer l'instantané.
La réplication de fusion fournit des procédures stockées qui permettent d'ignorer les modifications de schéma pendant le dépannage. Pour plus d’informations, consultez sp_markpendingschemachange (Transact-SQL) et sp_enumeratependingschemachanges (Transact-SQL).