Modification du schéma dans les bases de données de publication

Mis à jour : 14 avril 2006

La réplication prend en charge un large éventail de modifications de schéma sur les objets publiés. Lorsque vous apportez l'une des modifications de schéma suivantes à l'objet publié sur un serveur de publication Microsoft SQL Server, cette modification est propagée par défaut à tous les Abonnés SQL Server :

• ALTER TABLE
• ALTER VIEW
• ALTER PROCEDURE
• ALTER FUNCTION
• ALTER TRIGGER (ALTER TRIGGER ne peut être utilisé qu'avec les déclencheurs DML [data manipulation language] puisque les déclencheurs DDL [data definition language] ne peuvent pas être répliqués.)

Important :
Les modifications de schéma apportées aux tables doivent être effectuées à l'aide de Transact-SQL ou de SMO (SQL Server Management Objects). Lorsque des modifications de schéma sont effectuées dans SQL Server Management Studio, Management Studio tente de supprimer puis de recréer la table. La suppression des objets publiés étant impossible, la modification 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 de capture instantanée, les modifications de schéma sont propagées lors de l'application d'une nouvelle capture instantanée sur l'Abonné. Dans la réplication de capture instantanée, une nouvelle copie du schéma est envoyée à l'Abonné à chaque synchronisation. Par conséquent, toutes les modifications de schéma (pas uniquement celles répertoriées ci-dessus) apportées aux objets précédemment publiés sont automatiquement propagées avec chaque synchronisation.

Pour plus d'informations sur l'ajout et la suppression d'articles de publications, consultez Ajout et suppression d'articles de publications existantes.

Pour répliquer les modifications de schéma

Les modifications de schéma répertoriées ci-dessus sont répliquées par défaut. Pour plus d'informations sur la désactivation de la réplication des modifications de schéma, consultez les rubriques suivantes :

• SQL Server Management Studio: Procédure : répliquer des modifications de schéma (SQL Server Management Studio)
• Programmation Transact-SQL de réplication : How to: Replicate Schema Changes (Replication Transact-SQL Programming)

Considérations sur 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 générales

• Les modifications de schéma sont soumises aux restrictions imposées par Transact-SQL. Par exemple, ALTER TABLE ne vous permet pas de modifier les colonnes de clés primaires.
• Si la configuration d'une publication autorise la propagation des modifications de schéma, celles-ci sont propagées quelle que soit la configuration de l'option de schéma associée pour un article de la publication. Si, par exemple, vous décidez de ne pas répliquer les contraintes de clé étrangère pour un article de table mais qu'ensuite vous émettez une commande ALTER TABLE qui ajoute une clé étrangère sur le serveur de publication, la clé étrangère est ajoutée à la table sur l'Abonné. Pour éviter cela, désactivez la propagation des modifications de schéma avant d'émettre la commande ALTER TABLE.
• Les modifications de schéma doivent être uniquement effectuées sur le serveur de publication et non sur les Abonnés (y compris les Abonnés de republication). La réplication de fusion empêche interdit les modifications de schéma sur l'Abonné, à la différence de la réplication transactionnelle mais dans ce dernier cas, il se peut que les modifications apportées entraînent l'échec de la réplication.
• Les modifications propagées à un Abonné de republication sont transmises par défaut à ses Abonnés.
• Si la modification de schéma fait référence à des objets ou des contraintes qui existent sur le serveur de publication mais pas sur l'Abonné, elle est effectuée sur le serveur de publication mais échoue sur l'Abonné.
• Tous les objets de l'Abonné référencés lors de l'ajout d'une clé étrangère doivent avoir un nom et un propriétaire identiques à l'objet correspondant sur le serveur de publication.
• L'ajout, la suppression ou la modification explicites d'index ne sont pas pris en charge. En revanche, les index créés explicitement pour les contraintes, par exemple une contrainte de clé primaire, le sont.
• 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éplication de colonnes d'identité.
• Les modifications de schéma qui comprennent des fonctions non déterministes ne sont pas prises en charge car elles peuvent se traduire par la présence de données différentes sur le serveur de publication et l'Abonné (c'est-à-dire non convergentes). Si, par exemple, vous émettez sur le serveur de publication la commande ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), les valeurs sont différentes lorsque la commande est répliquée sur l'Abonné et exécutée. Pour plus d'informations sur les fonctions non déterministes, consultez Fonctions déterministes et non déterministes.
• Il est conseillé de nommer explicitement les contraintes. Si les contraintes ne sont pas nommées explicitement, SQL Server génère des noms pour celles-ci, qui seront différents sur le serveur de publication et sur chaque Abonné. Cela peut occasionner des problèmes pendant la réplication des modifications de schéma. Par exemple, si vous supprimez une colonne sur le serveur de publication et qu'une contrainte dépendante est supprimée, la réplication essaie de supprimer la contrainte sur 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 une table est publiée pour réplication, il n'est pas possible de modifier une colonne de cette table en un type de données XML si une capture instantanée de publication a déjà été générée (vous pouvez modifier la colonne avant la création de la capture instantanée). Pour modifier la colonne, vous devez d'abord supprimer la réplication. Pour plus d'informations, consultez Suppression de la réplication.

Ajout de colonnes

• Pour ajouter une nouvelle colonne à une table et inclure celle-ci à une publication existante, exécutez ALTER TABLE <Table> ADD <Colonne>. Par défaut, la colonne est alors répliquée sur tous les Abonnés. La colonne doit accepter des valeurs NULL ou inclure une contrainte par défaut.
• Pour ajouter une nouvelle colonne à une table et inclure cette colonne à une publication existante, désactivez la réplication des modifications de schéma puis exécutez ALTER TABLE <Table> ADD <Colonne>.
• Pour inclure une colonne existante à 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, consultez How to: Define and Modify a Column Filter (Replication Transact-SQL Programming) et Procédure : définir et modifier un filtre de colonne (SQL Server Management Studio). Cette opération exige la réinitialisation des abonnements.
• L'ajout d'une colonne d'identité à une table publiée n'est pas pris en charge car vous risquez d'être confronté à un problème de non convergence lors de la réplication de la colonne sur 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. Comme il est possible que les lignes soient stockées différemment sur l'Abonné, la valeur de la colonne d'identité peut être différente pour les mêmes lignes.

Suppression de colonnes

• Pour supprimer une colonne d'une publication existante et de la table hébergée sur le serveur de publication, exécutez ALTER TABLE <Table> DROP <Colonne>. Par défaut, la colonne est alors supprimée de la table sur tous les Abonnés.
• Pour supprimer une colonne existante d'une publication existante mais la conserver dans la table du 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, consultez How to: Define and Modify a Column Filter (Replication Transact-SQL Programming) et Procédure : définir et modifier un filtre de colonne (SQL Server Management Studio). Cette opération exige la génération d'une nouvelle capture instantanée.
• La colonne à supprimer ne peut pas être utilisée dans les clauses de filtrage d'un article quelconque d'une publication de la base de données.
• La suppression d'une colonne d'un article publié nécessite la prise en compte des éventuels contraintes, index ou propriétés de la colonne susceptibles d'affecter la base de données. Par exemple :
  • Vous ne pouvez pas supprimer les colonnes utilisées dans une clé primaire d'articles de publications transactionnelles car elles sont utilisées par la réplication.
  • Vous ne pouvez pas supprimer la colonne rowguid d'articles de publications de fusion ou la colonne mstran_repl_version d'articles de publications transactionnelles qui prennent en charge les abonnement mis à jour car elles sont utilisées par la réplication.
  • Les modifications d'index ne sont pas propagées aux Abonnés : si vous supprimez une colonne sur le serveur de publication et qu'un index dépendant est supprimé, la suppression de l'index n'est pas répliquée. Vous devez supprimer l'index sur l'Abonné avant de supprimer la colonne sur le serveur de publication, de manière à ce que la suppression de la colonne réussisse lorsqu'elle est répliquée depuis le 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.
  • Les opérations de suppression ne fonctionnent que si les contraintes sont nommées explicitement. Pour plus d'informations, consultez la section « Considérations générales », plus haut dans cette rubrique.

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. Ces modifications doivent être apportées au serveur de publication à l'aide de sp_repladdcolumn (Transact-SQL) et de sp_repldropcolumn (Transact-SQL) au lieu de la syntaxe DDL ALTER TABLE.
• Les modifications de schéma propagées aux Abonnés non SQL Server peuvent entraîner la réinitialisation de l'Abonné.
• Ces modifications ne sont pas propagées si elles proviennent de serveurs de publication non SQL Server.
• Vous ne pouvez pas modifier des vues indexées répliquées en tant que tables. Les vues indexées répliquées en tant que vues indexées peuvent l'être mais une fois modifiées, elles deviennent des tables régulières et non plus des vues indexées.
• Si la publication prend en charge les abonnements mis à jour en attente ou immédiatement, le système doit être suspendu le temps d'effectuer les modifications de schéma : toute activité relative à la table publiée doit être interrompue sur le serveur de publication et les Abonnés et les modifications de données en attente doivent être propagées à tous les nœuds. Après la propagation des modifications de schéma à tous les nœuds, l'activité peut reprendre dans les tables publiées.
• Si la publication fait partie d'une topologie d'égal à égal, le système doit être suspendu le temps d'effectuer les modifications de schéma : Pour plus d'informations, consultez How to: Quiesce a Replication Topology (Replication Transact-SQL Programming).
• L'ajout d'une colonne d'horodatage à une table et le mappage de l'horodatage à binary(8) entraîne la réinitialisation de l'article pour tous les abonnements actifs.

Réplication de fusion

• Pour répliquer les modifications de schéma, le niveau de compatibilité de la publication doit être au minimum égal à 90RTM. Pour plus d'informations, consultez la section « Niveau de compatibilité des publications de fusion » dans la rubrique Utilisation de plusieurs versions de SQL Server dans une topologie de réplication. Si les Abonnés exécutent des versions antérieures de SQL Server ou si le niveau de compatibilité est inférieur à 90RTM, vous pouvez néanmoins utiliser sp_repladdcolumn (Transact-SQL) et sp_repldropcolumn (Transact-SQL) pour ajouter et supprimer des colonnes.
• 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 la capture instantanée.
• 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).

Voir aussi

Concepts

Publication de données et d'objets de base de données
Régénération de procédures transactionnelles personnalisées pour refléter des modifications de schéma

Autres ressources

ALTER TABLE (Transact-SQL)
ALTER VIEW (Transact-SQL)
ALTER PROCEDURE (Transact-SQL)
ALTER FUNCTION (Transact-SQL)
ALTER TRIGGER (Transact-SQL)

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications