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

S’applique à :SQL ServerAzure SQL Managed Instance

Lors de la création d'une publication, vous choisissez les tables et les autres objets de base de données à 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, fournissez les informations suivantes :

• Le serveur de distribution.
• L'emplacement des fichiers d'instantanés.
• La base de données de publication.
• Le type de publication à créer (instantané, transactionnelle, transactionnelle avec abonnements pouvant être mis à jour ou fusion).
• les données et les objets de base de données (articles) à inclure à la publication ;
• Filtres de lignes statiques et filtres de colonnes statiques pour tous les types de publications, et filtres de lignes paramétrés et filtres de jointure pour les publications de fusion.
• La planification de l'Agent d'instantané.
• Comptes utilisés par les agents suivants : l’Agent d’instantané pour toutes les publications ; l’Agent de lecture du journal pour toutes les publications transactionnelles ; l’Agent de lecture de la file d’attente pour les publications transactionnelles autorisant la mise à jour des abonnements.
• Nom et description de la publication.

Pour des informations sur la façon de travailler avec les publications, voir les articles suivants :

• 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

Tableaux de publication

L'objet le plus couramment publié est une table. Les liens suivants fournissent plus d’informations sur la publication des tableaux :

• Filtrer des données publiées
• Options d'article pour la réplication transactionnelle
• Options d’articles pour la réplication de fusion
• Répliquer des colonnes d’identité

Lorsque vous publiez un tableau pour la réplication, vous pouvez spécifier quels objets de schéma copier vers l’abonné, tels que l’intégrité référentielle déclarée (contraintes de clé primaire, contraintes de référence, contraintes uniques), les index, les déclencheurs DML utilisateur (les déclencheurs DDL ne peuvent pas être répliqués), les propriétés étendues et la collation. 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 support dépend du type de réplication que vous utilisez, ainsi que des options que vous spécifiez pour la publication et les articles associés aux tables partitionnées. Pour plus d’informations, consultez Répliquer des tables et des index partitionnés.

Publier des procédures stockées

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

En plus de répliquer 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. Cette fonctionnalité est utile pour reproduire les résultats de procédures stockées orientées maintenance qui affectent de grandes quantités de données. Pour plus d’informations, consultez Publishing Stored Procedure Execution in Transactional Replication.

Publier des vues

Tous les types de réplication vous permettent de répliquer des vues. Vous pouvez copier la vue et son index associé (s’il s’agit d’une vue indexée) vers l’abonné, mais vous devez aussi reproduire la table de base.

Pour les vues indexées, la réplication transactionnelle vous permet aussi de répliquer la vue indexée en tant que table et non pas en tant que vue, éliminant ainsi la nécessité de répliquer aussi la table de base. Pour cela, spécifiez 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 de fonctions définies par l’utilisateur

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

Publication de types définis par l'utilisateur et de types de données alias

La réplication traite les colonnes qui utilisent des types de données définis par l’utilisateur ou des types d’alias comme d’autres colonnes et les réplique aux abonnés. Le processus exécute l’instruction CREATE TYPE pour chaque type répliqué auprès de l’abonné avant de créer la table. Pour les types définis par l’utilisateur, la réplication copie également l’assembleur associé à chaque abonné. La réplication ne réplique pas les modifications des types définis par l’utilisateur ni des types de données d’alias vers les abonnés.

Si vous définissez un type dans une base de données mais ne le référencez dans aucune colonne lors de la création d’une publication, la réplication ne copie pas le type vers les abonnés. Si vous créez ensuite 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’assembleur associé pour un type défini par l’utilisateur) à chaque abonné.

Publication des index de texte intégral

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

Modifications de schéma pour des objets publiés

La réplication prend en charge une grande variété de modifications de schéma pour les objets publiés. Lorsque vous effectuez l’un des changements de schéma suivants sur l’objet publié approprié à un SQL Server Publisher, la réplication par défaut propage ce changement à tous les SQL Server abonnés :

• ALTER TABLE

• ALTER VIEW

• ALTER PROCEDURE

• ALTER FUNCTION

• ALTER TRIGGER

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

Considérations pour la publication

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

• Les utilisateurs peuvent accéder à la base de données lors de la création de la publication et de l'instantané initial, mais il est préférable de créer des publications lors des périodes de faible activité sur le Publisher.

• Vous ne pouvez pas renommer une base de données après avoir créé une publication dedans. Pour renommer la base de données, vous devez d’abord retirer 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 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 publier la table également.

  Remarque

  Si vous ajoutez un article à une publication fusionnée et qu’un article existant dépend du nouvel article, vous devez spécifier un ordre de traitement pour les deux articles en utilisant les paramètres @processing_order sp_addmergearticle et sp_changemergearticle. Considérons le scénario suivant : vous publiez un tableau mais vous ne publiez pas une fonction que le tableau fait référence. Si vous ne publiez pas la fonction, la table ne peut pas être créée par l’abonné. Lorsque vous ajoutez la fonction à la publication : spécifiez la valeur 1 pour le paramètre @processing_order de sp_addmergearticle, spécifiez la valeur 2 pour le paramètre @processing_order de sp_changemergearticle, et spécifiez le nom de la table pour le paramètre @article. Cet ordre de traitement permet de créer la fonction au niveau de l'Abonné avant la table qui en dépend. Vous pouvez utiliser différents nombres pour chaque article tant que le nombre de la fonction est inférieur au nombre de la table.

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

Limitations sur la publication des objets

• Le nombre maximal d’articles et de chroniques que vous pouvez publier varie selon le type de publication. Pour plus d’informations, consultez la section « Objets de réplication » dans Spécifications des capacités maximales pour SQL Server.

• Vous ne pouvez pas publier des procédures stockées, des vues, des déclencheurs et des fonctions définies par l'utilisateur qui sont définies comme AVEC CHIFFREMENT dans le cadre de la réplication de SQL Server.

• Vous pouvez répliquer des collections de schémas XML mais les modifications ne sont pas reproduites 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. La réplication nécessite ces index. Pour désactiver un index, vous devez d'abord supprimer la table de la réplication.

• 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 au profit des valeurs par défaut créées avec le mot-clé DEFAULT de ALTER TABLE ou CREATE TABLE).

• Vous ne pouvez pas publier les fonctions contenant l’indice NOEXPAND sur les vues indexées dans la même publication que les tables référencées et les vues indexées, en raison de l’ordre dans lequel l’agent de distribution les délivre. Pour contourner ce problème, placez la création de la table et de la vue indexée dans une première publication, puis ajoutez les fonctions contenant l'indicateur NOEXPAND sur les vues indexées à une seconde publication que vous publierez à la fin de la première publication. Ou bien, créez des scripts pour ces fonctions et exécutez-les à l'aide du paramètre @post_snapshot_script de sp_addpublication.

Schémas et propriété des objets

La réplication fonctionne par défaut de la façon suivante dans l'Assistant Nouvelle publication quant aux schémas et à la propriété des objets :

• Pour les articles de publications de fusion d'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 sur l'Abonné est le même que le propriétaire de l'objet correspondant sur le serveur de publication. Si les schémas propriétaires des objets n'existent pas sur l'Abonné, ils sont créés automatiquement.

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

• Pour les articles des publications Oracle : par défaut, le propriétaire est spécifié comme dbo.

• Pour les articles de publications utilisant les instantanés en mode caractère (utilisées pour les abonnés non-SQL et les abonnés SQL Server Compact) : le propriétaire est laissé vide par défaut. Le propriétaire prend les valeurs par défaut du propriétaire associé au compte utilisé par l'Agent de distribution ou l'Agent de fusion pour se connecter à l'Abonné.

Vous pouvez changer le propriétaire de l’objet via la boîte de dialogue Propriétés de l’article - <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 d’une publication, Définir un article et Afficher et modifier les propriétés d’un article.

Publication de données sur les Abonnés exécutant des versions antérieures de SQL Server

• Si vous publiez auprès d'un abonné qui utilise une version précédente de SQL Server, vous êtes limité à la fonctionnalité de cette version. Cette limitation s’applique à la fois aux fonctionnalités spécifiques à la réplication et à la fonctionnalité globale du produit.

• Les publications de fusion utilisent un niveau de compatibilité, qui détermine quelles fonctionnalités vous pouvez utiliser dans une publication et vous permet de supporter les abonnés utilisant des versions précédentes de SQL Server.

Tableaux de publication dans plusieurs publications

La réplication permet de publier des articles dans plusieurs publications, y compris la republication de données, avec les restrictions suivantes :

• Si vous publiez un article à la fois dans une publication transactionnelle et dans une publication de fusion, définissez la propriété de @published_in_tran_pub à TRUE pour l’article de fusion. Pour plus d’informations sur la définition de propriétés, consultez Afficher et modifier les propriétés d’une publication et Afficher et modifier les propriétés d’un article.

  Définissez la propriété @published_in_tran_pub si un article fait partie d’un abonnement transactionnel et est inclus dans une publication de fusion. Par défaut, la réplication transactionnelle suppose que les tables de l’abonné sont en mode lecture seule. Si la réplication par fusion modifie une table dans un abonnement transactionnel, une non-convergence des données peut se produire. Pour éviter ce problème, spécifiez tout tableau comme téléchargeable uniquement dans la publication de la fusion. Ce paramètre empêche un Abonné de fusion d’envoyer les modifications de données vers la table. Pour plus d’informations, consultez Optimiser les performances de la réplication de fusion avec les articles en téléchargement seul.

• Vous ne pouvez pas publier un article à la fois dans une publication fusionnée et une publication transactionnelle avec des abonnements à mise à jour en file d’attente.

• Vous ne pouvez pas republier les articles inclus dans des publications transactionnelles qui soutiennent la mise à jour des abonnements.

• Si vous publiez un article dans plusieurs publications transactionnelles qui supportent les abonnements à mise à jour en file d’attente, l’article doit avoir la même valeur pour les propriétés suivantes dans toutes les publications :

  Propriété	Paramètre dans sp_addarticle
  Gestion de plages d'identités	@auto_identity_range (obsolète) et @identityrangemangementoption
  Plage d’identités de l’éditeur	@pub_identity_range
  Plage d'identités	@identity_range
  Seuil de plage d'identités	@threshold

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

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

  Propriété	Paramètre de sp_addmergearticle
  Suivi de colonne	@column_tracking
  Options de schéma	@schema_option
  Filtrage de colonnes	@vertical_partition
  Options de téléversement de l'abonné	@subscriber_upload_options
  Suivi conditionnel des suppressions	@delete_tracking
  Compensation d'erreur	@compensate_for_errors
  Gestion de plages d'identités	@auto_identity_range (obsolète) et @identityrangemangementoption
  Plage d’identités de l’éditeur	@pub_identity_range
  Plage d'identités	@identity_range
  Seuil de plage d'identités	@threshold
  Options de partition	@partition_options
  Diffusion de colonne de 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 par fusion non filtrée permettent de publier une table dans plusieurs publications puis de s’abonner dans une seule table dans la base de données d’abonnement (généralement appelé scénario de regroupement). Le rollup est souvent utilisé pour agréger des sous-ensembles de données provenant de plusieurs emplacements dans une même table au sein d’un abonné central. Les publications de fusion filtrée ne prennent pas en charge le scénario d’Abonné central. Pour la réplication de fusion, le rollup est généralement implémenté via une seule publication avec des filtres de lignes paramétrés. Pour plus d'informations, voir Parameterized Row Filters.

Contenu connexe

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