Publier des données et des objets de base de données

Lors de la création d’une publication, vous choisissez les tables et les autres objets de base de données que vous souhaitez publier. Vous pouvez publier les objets de base de données suivants à l’aide de la réplication.

Création de publications

Pour créer une publication, vous fournissez les informations suivantes :

• Le Distributeur.

• Emplacement des fichiers de sauvegarde instantanée

• Base de données de publication.

• Type de publication à créer (instantané, transactionnel, transactionnel avec des abonnements pouvant être mis à jour ou fusionner).

• Objets de données et de base de données (articles) à inclure dans la publication.

• Filtres de lignes statiques et filtres de colonnes pour tous les types de publications, et filtres de lignes paramétrables et filtres de jointure pour les publications de fusion.

• Planification de l’Agent d’instantané.

• Comptes sous lesquels les agents suivants s’exécutent : l’Agent d’instantané pour toutes les publications ; l’Agent de lecture du journal pour toutes les publications transactionnelles ; l’Agent de lecture de file d’attente pour les publications transactionnelles permettant la mise à jour des abonnements.

• Nom et description de la publication.

Pour plus d’informations sur l’utilisation des publications, consultez les rubriques suivantes :

• Créer une publication

• Définir un article

• Afficher et modifier les propriétés d’une publication

• Afficher et modifier les propriétés d’un article

• Supprimer une publication

• Supprimer un article

Publication de tables

L’objet le plus couramment publié est une table. Les liens suivants fournissent des informations supplémentaires sur les domaines liés à la publication des tables :

• Filtrer les données publiées

• Options d’article pour la réplication transactionnelle

• Options d’article pour la réplication par fusion

• Répliquer des colonnes d’identité

Lors de la publication d’une table pour la réplication, vous pouvez spécifier quels objets de schéma doivent être copiés sur l’Abonné, tels que l’intégrité référentielle déclarée (contraintes de clé primaire, contraintes de référence, contraintes uniques), index, déclencheurs DML utilisateur (déclencheurs DDL ne peuvent pas être répliqués), propriétés étendues et classement. Les propriétés étendues sont répliquées uniquement dans la synchronisation initiale entre le serveur de publication et l’Abonné. Si vous ajoutez ou modifiez une propriété étendue après la synchronisation initiale, la modification n’est pas répliquée.

Pour spécifier des options de schéma, consultez Spécifier des options de schéma ou SchemaOption.

Tables et index partitionnés

La réplication prend en charge la publication de tables et d’index partitionnés. Le niveau de prise en charge dépend du type de réplication utilisé et des options que vous spécifiez pour la publication et les articles associés aux tables partitionnée. Pour plus d’informations, consultez Répliquer des tables et des index partitionnés.

Publication de procédures stockées

Tous les types de réplication vous permettent de répliquer des définitions de procédures stockées : CREATE PROCEDURE est copiée pour chaque abonné. Dans le cas des procédures stockées du Common Language Runtime (CLR), l'assemblage associé est également copié. Les modifications apportées aux procédures sont répliquées chez les Abonnés ; les modifications apportées aux assemblages associés ne le sont pas.

Outre la réplication de la définition d’une procédure stockée, la réplication transactionnelle vous permet de répliquer l’exécution des procédures stockées. Cela est utile en répliquant les résultats des procédures stockées axées sur la maintenance qui affectent de grandes quantités de données. Pour plus d’informations, consultez Publication de l’exécution de procédure stockée dans la réplication transactionnelle.

Vues de publication

Tous les types de réplication vous permettent de répliquer des vues. La vue (et son index associé, s’il s’agit d’une vue indexée) peut être copiée sur l’Abonné, mais la table de base doit également être répliquée.

Pour les vues indexées, la réplication transactionnelle vous permet également de répliquer la vue indexée en tant que table plutôt qu’une vue, ce qui élimine la nécessité de répliquer également la table de base. Pour ce faire, spécifiez l’une des options « indexed view logbased » pour le paramètre @type de sp_addarticle (Transact-SQL). Pour plus d’informations sur l’utilisation de sp_addarticle, consultez Définir un article.

Publication des fonctions User-Defined

Les instructions CREATE FUNCTION pour les fonctions CLR et les fonctions Transact-SQL sont copiées sur chaque Abonné. Dans le cas des fonctions CLR, l’assembly associé est également copié. Les modifications apportées aux fonctions sont répliquées sur les abonnés. Les modifications apportées aux assemblages associés ne le sont pas.

Publication de types de données User-Defined et alias

Les colonnes qui utilisent des types de données définis par l'utilisateur ou des types de données alias sont répliquées aux abonnés comme d'autres colonnes. L’instruction CREATE TYPEstatement pour chaque type répliqué est exécutée sur l’Abonné avant la création de la table. Dans le cas de types définis par l'utilisateur, l'assemblage associé est également copié sur chaque abonné. Les modifications apportées aux types de données définis par l’utilisateur et aux types de données d’alias ne sont pas répliquées sur les Abonnés.

Si un type est défini dans une base de données, mais qu’il n’est référencé dans aucune colonne lorsqu’une publication est créée, le type n’est pas copié dans les Abonnés. Si vous créez par la suite une colonne de ce type dans la base de données et souhaitez la répliquer, vous devez d’abord copier manuellement le type (et l’assembly associé pour un type défini par l’utilisateur) sur chaque Abonné.

Publication d’index complets de texte

L’instruction CREATE FULLTEXT INDEX est copiée vers chaque Abonné, et l’index de texte intégral est créé chez l’Abonné. Les modifications apportées aux index de texte intégral à l’aide de ALTER FULLTEXT INDEX ne sont pas répliquées.

Apporter des modifications de schéma aux objets publiés

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

• MODIFIER TABLE

• MODIFIER LA VUE

• MODIFIER PROCÉDURE

• ALTER FUNCTION

• ALTER TRIGGER

Pour plus d’informations, consultez Modifier le schéma dans les bases de données de publication.

Considérations relatives à la publication

Gardez à l’esprit les problèmes suivants lors de la publication d’objets de base de données :

• La base de données est accessible aux utilisateurs pendant la création de la publication et de l’instantané initial, mais il est conseillé de créer des publications lors des périodes de faible activité sur l'éditeur.

• Une base de données ne peut pas être renommée après la création d’une publication. Pour le renommer, vous devez d’abord supprimer la réplication de la base de données.

• Si vous publiez un objet de base de données qui dépend d’un ou de plusieurs autres objets de base de données, vous devez publier tous les objets référencés. Par exemple, si vous publiez une vue qui dépend d’une table, vous devez également publier la table.

  Remarque

  Si vous ajoutez un article à une publication de fusion et qu’un article existant dépend du nouvel article, vous devez spécifier une commande de traitement pour les deux articles à l’aide du paramètre @processing_order de sp_addmergearticle et de sp_changemergearticle. Considérez le scénario suivant : vous publiez une table, mais vous ne publiez pas de fonction référencée par la table. Si vous ne publiez pas la fonction, la table ne peut pas être créée chez l’abonné. Lorsque vous ajoutez la fonction à la publication : spécifiez la valeur 1 pour le paramètre @processing_order de sp_addmergearticle ; et spécifiez la valeur 2 pour le paramètre @processing_order de sp_changemergearticle, en spécifiant le nom de table du paramètre @article. Cet ordre de traitement garantit que vous créez la fonction à l’Abonné avant la table qui en dépend. Vous pouvez utiliser des nombres différents pour chaque article tant que le nombre de la fonction est inférieur au nombre de la table.

• Les noms de publication ne peuvent pas inclure les caractères suivants : % * [ ] | : " ? \ / <>.

Limitations relatives à la publication d’objets

• Le nombre maximal d’articles et de colonnes pouvant être publiés diffère du type de publication. Pour plus d’informations, consultez la section « Objets de réplication » des spécifications de capacité maximale pour SQL Server.

• Les procédures stockées, les vues, les déclencheurs et les fonctions définies par l’utilisateur définies comme WITH ENCRYPTION ne peuvent pas être publiées dans le cadre de la réplication SQL Server.

• Les collections de schémas XML peuvent être répliquées, mais les modifications ne sont pas répliquées après l’instantané initial.

• Les tables publiées pour la réplication transactionnelle doivent avoir une clé primaire. Si une table se trouve dans une publication de réplication transactionnelle, vous ne pouvez pas désactiver les index associés aux colonnes clés primaires. Ces index sont requis par la réplication. Pour désactiver un index, vous devez d’abord supprimer la table de la publication.

• Les valeurs par défaut liées créées avec sp_bindefault (Transact-SQL) ne sont pas répliquées (les valeurs par défaut liées sont déconseillées en faveur des valeurs par défaut créées avec le mot clé DEFAULT de ALTER TABLE ou CREATE TABLE).

• Les fonctions contenant l’indicateur NOEXPAND sur les vues indexées ne peuvent pas être publiées dans la même publication que les tables et vues indexées référencées, en raison de l’ordre dans lequel l’agent de distribution les livre. Pour contourner ce problème, placez la table et la création d'une vue indexée dans une première publication. Ensuite, ajoutez les fonctions contenant l'indicateur NOEXPAND aux vues indexées dans une deuxième publication, que vous publiez après avoir terminé la première publication. Vous pouvez également créer des scripts pour ces fonctions et fournir le script à l’aide du paramètre @post_snapshot_script de sp_addpublication.

Schémas et propriété d’objet

La réplication a le comportement par défaut suivant dans l’Assistant Nouvelle publication en ce qui concerne les schémas et la propriété de l’objet :

• Pour les articles dans les publications de fusion avec un niveau de compatibilité de 90 ou supérieur, les publications d'instantané et les publications transactionnelles : par défaut, le propriétaire de l'objet chez le Subscriber est le même que le propriétaire de l'objet correspondant chez le Publisher. Si les schémas qui possèdent des objets n’existent pas sur l’Abonné, ils sont créés automatiquement.

• Pour les articles dans les publications de fusion avec un niveau de compatibilité inférieur à 90 : par défaut, le propriétaire est laissé vide et est spécifié comme dbo lors de la création de l’objet sur l’Abonné.

• Pour les articles dans les publications Oracle : par défaut, le propriétaire est spécifié en tant que dbo.

• Pour les articles dans les publications qui utilisent des captures instantanées en mode caractère (qui sont utilisées pour les abonnés non-SQL Server et les abonnés SQL Server Compact) : par défaut, le propriétaire est laissé vide. Le propriétaire par défaut est le propriétaire associé au compte utilisé par l’Agent de distribution ou l’Agent de fusion pour se connecter à l’abonné.

Le propriétaire de l’objet peut être modifié via la boîte de dialogue Propriétés de l’article - < Boîte de dialogue Article> et via les procédures stockées suivantes : sp_addarticle, sp_addmergearticle, sp_changearticle et sp_changemergearticle. Pour plus d’informations, consultez Afficher et modifier les propriétés de publication, Définir un article et afficher et modifier les propriétés de l’article.

Publication de données sur des abonnés exécutant des versions précédentes de SQL Server

• Si vous publiez sur un Abonné exécutant une version précédente de SQL Server, vous êtes limité aux fonctionnalités de cette version, à la fois en termes de fonctionnalités spécifiques à la réplication et aux fonctionnalités du produit dans son ensemble.

• Les publications de fusion utilisent un niveau de compatibilité, qui détermine les fonctionnalités qui peuvent être utilisées dans une publication et vous permet de prendre en charge les Abonnés exécutant des versions antérieures de SQL Server.

Publication de tables dans plusieurs publications

La réplication prend en charge la publication d’articles dans plusieurs publications (y compris la republier des données) avec les restrictions suivantes :

• Si un article est publié dans une publication transactionnelle et une publication de fusion, vérifiez que la propriété @published_in_tran_pub a la valeur TRUE pour l’article de fusion. Pour plus d’informations sur la définition des propriétés, consultez Afficher et Modifier les propriétés de publicationet Afficher et Modifier les propriétés de l’article.

  Vous devez également définir la propriété @published_in_tran_pub si un article fait partie d’un abonnement transactionnel et est inclus dans une publication de fusion. Si c’est le cas, sachez que par défaut, la réplication transactionnelle s’attend à ce que les tables de l’Abonné soient traitées en lecture seule ; si la réplication de fusion apporte des modifications de données à une table dans un abonnement transactionnel, la non-convergence des données peut se produire. Pour éviter cette possibilité, nous vous recommandons de spécifier une table de ce type en tant que téléchargement uniquement dans la publication de fusion. Cela empêche un Abonné de fusion de charger des modifications de données dans la table. Pour plus d’informations, consultez Optimiser les performances de la réplication de fusion avec les articles en téléchargement seul.

• Un article ne peut pas être publié à la fois dans une publication de fusion et une publication transactionnelle avec des abonnements de mise à jour en file d’attente.

• Les articles inclus dans les publications transactionnelles qui prennent en charge la mise à jour des abonnements ne peuvent pas être republiées.

• Si un article est publié dans plusieurs publications transactionnelles qui prend en charge les abonnements mis à jour en file d’attente, les propriétés suivantes doivent avoir la même valeur pour l’article dans toutes les publications :

  Propriété	Paramètre dans sp_addarticle
  Gestion des plages d’identités	@auto_identity_range (déconseillé) et @identityrangemanagementoption
  Gamme d’identité de l’éditeur	@pub_identity_range
  Plage d’identités	@identity_range
  Seuil de plage d’identité	@threshold

  Pour plus d’informations sur ces paramètres, consultez sp_addarticle (Transact-SQL).

• Si un article est publié dans plusieurs publications de fusion, les propriétés suivantes doivent avoir la même valeur pour l’article dans toutes les publications :

  Propriété	Paramètre dans sp_addmergearticle
  Suivi des colonnes	@column_tracking
  Options de schéma	@schema_option
  Filtrage de colonnes	@vertical_partition
  Options de chargement de l’abonné	@options_de_téléchargement_abonné
  Suivi de suppression conditionnelle	@delete_tracking
  Compensation des erreurs	@compensate_for_errors
  Gestion des plages d’identités	@auto_identity_range (déconseillé) et @identityrangemanagementoption
  Plage d’identité de l’éditeur	@pub_identity_range
  Plage d’identités	@identity_range
  Seuil de plage d’identité	@threshold
  Options de partition	@partition_options
  Flux des colonnes blob	@stream_blob_columns
  Type de filtre	@filter_type (paramètre dans sp_addmergefilter)

  Pour plus d’informations sur ces paramètres, consultez sp_addmergearticle (Transact-SQL) et sp_addmergefilter (Transact-SQL).

• La réplication transactionnelle et la réplication de fusion sans filtre permettent de publier une table dans plusieurs publications, puis de s'abonner à cette table unique dans la base de données d'abonnement (souvent appelée un scénario de regroupement). La consolidation des données est souvent utilisée pour agréger des sous-ensembles de données provenant de plusieurs emplacements dans une table chez un abonné central. Les publications de fusion filtrées ne prennent pas en charge le scénario d’Abonné central. Pour la réplication de fusion, le cumul est généralement implémenté via une publication unique avec des filtres de lignes paramétrés. Pour plus d’informations, consultez Filtres de lignes paramétrables.

Voir aussi

Ajouter des articles à des publications existantes et supprimer des articles
Configurer la distribution
Initialiser un abonnement
Réplication de script
Sécuriser l'éditeur
S’abonner aux Publications