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

Article
11/10/2015

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.

Objet de base de données	Réplication d'instantané et réplication transactionnelle	Réplication de fusion
Tables	X	X
Tables partitionnées	X	X
Procédures stockées – Définition (Transact-SQL et CLR)	X	X
Procédures stockées – Exécution (Transact-SQL et CLR)	X	non
Vues	X	X
Vues indexées	X	X
Vues indexées comme des tables	X	non
Types définis par l'utilisateur (CLR)	X	X
Fonctions définies par l'utilisateur (Transact-SQL et CLR)	X	X
Types de données d'alias	X	X
Index de texte intégral	X	X
Objets de schéma (contraintes, index, déclencheurs DML utilisateur, propriétés étendues et classement)	X	X

Création de publications

Pour créer une publication, vous 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é.
Les 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 la file d'attente pour les publications transactionnelles qui autorisent les abonnements pouvant être mis à jour.
Nom et description de la publication.

Pour plus d'informations sur la manière de travailler avec des publications, consultez les rubriques suivantes :

[!REMARQUE]

La suppression d'un article ou d'une publication ne supprime pas les objets sur l'Abonné.

Publication de tables

L'objet le plus couramment publié est une table. Les liens suivants donnent des informations supplémentaires sur les éléments relatifs à la publication des tables :

Lors de la publication d'une table pour la réplication, vous pouvez spécifier les objets de schéma qui doivent être copiés vers l'Abonné, tels que l'intégrité référentielle déclarée (contraintes de clé primaire, contraintes référentielles, contraintes uniques), des index, des déclencheurs DML utilisateur (des déclencheurs DDL qui ne peuvent pas être répliqués), des propriétés étendues et des classements. Les propriétés étendues sont répliquées uniquement lors de 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é, 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.

Publication de procédures stockées

Tous les types de réplication vous permettent de répliquer des définitions de procédure stockée : L'instruction CREATE PROCEDURE est copiée sur chaque Abonné. Dans le cas de procédures stockées CLR (Common Language Runtime), l'assembly associé est également copié. Les modifications des procédures sont répliquées vers les Abonnés ; les modifications des assemblys 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. Ceci est particulièrement utile lors de la réplication des résultats de procédures stockées de maintenance qui affectent de gros volumes de données. Pour plus d'informations, consultez Publication de l'exécution de procédures stockées dans la réplication transactionnelle.

Publication de vues

Tous les types de réplication vous permettent de répliquer des vues. La vue (et l'index qui l'accompagne s'il s'agit d'une vue indexée) peut être copiée vers l'Abonné, mais la table de base doit aussi être répliquée.

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 pour les fonctions CLR et pour les fonctions Transact-SQL sont copiées vers chaque Abonné. Dans le cas des fonctions CLR, l'assembly associé est également copié. Les modifications des fonctions sont répliquées vers les Abonnés ; les modifications aux assemblys associés ne le sont pas.

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

Les colonnes qui utilisent des types définis par l'utilisateur et des types de données alias sont répliquées vers les Abonnés, tout comme les autres colonnes. L'instruction CREATE TYPE 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'assembly associé est également copié vers chaque Abonné. Les modifications aux types définis par l'utilisateur et aux types de données alias ne sont pas répliquées vers les Abonnés.

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

Publication d'index de texte intégral

L'instruction CREATE FULLTEXT INDEX est copiée sur chaque Abonné, et l'index de texte intégral est créé sur l'Abonné. Les modifications apportées aux index de texte intégral à l'aide d'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 large gamme de modifications de schémas sur les objets publiés. Quand vous effectuez une des modifications de schéma suivantes sur l'objet publié approprié sur un Abonné 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

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

Considérations sur la publication

Soyez attentif aux problèmes suivants lors de la publication d'objets de base de données :

La base de données est accessible aux utilisateurs lors de la création de la publication et de l'instantané initial, mais il est conseillé de créer les publications à des moments où l'activité est faible sur le serveur de publication.
Une base de données ne peut pas être renommée après qu'une publication y ait été créée. Pour la 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'autres objets de base de données, vous devez publier tous les objets référencés. Par exemple, si vous publiez une vue dépendant d'une table, vous devez également publier la table en question.

[!REMARQUE]

Si vous ajoutez un article à une publication de fusion et qu'un article existant dépend du nouvel article, vous devez spécifier un ordre de traitement pour les deux articles à l'aide du paramètre @processing_order de sp_addmergearticle et sp_changemergearticle. Examinez le cas suivant : vous publiez une table mais vous ne publiez pas une fonction référencée par la table. Si vous ne publiez pas la fonction, la table ne peut pas être créée au niveau de 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 de publication ne peuvent pas contenir les caractères suivants : % * [ ] | : " ? \ / < >.

Limitations de la publication d'objets

Le nombre maximal d'articles et de colonnes publiables diffère selon le type de publication. Pour plus d'informations, consultez la section « Réplication d'objets » de Spécifications des capacités maximales pour SQL Server.
Les procédures stockées, les vues, les déclencheurs et les fonctions définies par l'utilisateur qui sont définies avec WITH ENCRYPTION ne peuvent pas être publiées en tant que composants d'une 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 d'index associés à des 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éés avec sp_bindefault (Transact-SQL) ne sont pas répliquées (les valeurs par défaut liées sont déconseillées et remplacées par des valeurs par défaut créés avec le mot clé DEFAULT de ALTER TABLE ou CREATE TABLE).
Les fonctions contenant l'indicateur NOEXPAND sur des vues indexées ne peuvent pas être publié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, et ajoutez les fonctions qui contiennent l'indicateur NOEXPAND sur les vues indexées dans une seconde publication que vous publierez une fois que la première publication est terminée. Ou bien, créez des scripts pour ces fonctions et délivrez le script à l'aide du paramètre @post\_snapshot\_script de sp_addpublication.

Schémas et propriété des objets

La réplication a le comportement par défaut suivant dans l'Assistant Nouvelle publication par rapport aux schémas et à la propriété d'objet :

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 des publications de fusion avec 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 : le propriétaire est spécifié comme dbo par défaut.
Pour les articles de publications utilisant les instantanés en mode caractère (utilisées pour les abonnés non-SQL Server 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é.

Le propriétaire de l'objet peut être modifié via la boîte de dialogue Propriétés de l'article - <Article> et 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 sur un Abonné exécutant une version antérieure de SQL Server, vous êtes limité par les fonctionnalités de cette version, en termes de fonctionnalités spécifiques à la réplication et en termes de fonctionnalités globales du produit.
Les publications de fusion utilisent un niveau de compatibilité, qui détermine les fonctionnalités qui peuvent être utilisées dans une publication et qui vous permet de prendre en charge des 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 réédition de données) avec les restrictions suivantes :

Si un article est publié dans une publication transactionnelle et dans 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 d'une publication et Afficher et modifier les propriétés d'un article.

Vous devez également définir la propriété @published\_in\_tran\_pub si un article fait partie d'un abonnement transactionnel et qu'il est inclus dans une publication de fusion. Si tel est le cas, gardez à l'esprit que, par défaut, la réplication transactionnelle suppose que les tables sur l'Abonné soient traitées en tant qu'objets accessibles en lecture seule ; si la réplication de fusion apporte des modifications aux données d'une table dans un abonnement transactionnel, une non-convergence de données peut se produire. Pour éviter cette éventualité, il est recommandé de spécifier toute table de ce type en tant qu'objet en téléchargement seul dans la publication de fusion. Cela empêche un Abonné de fusion de télécharger les modifications apportées aux données de 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 dans une publication transactionnelle avec des abonnements mis à jour en file d'attente.
Les articles inclus dans les publications transactionnelles qui prennent en charge les abonnements mis à jour ne peuvent pas être republiés.

Si un article est publié dans plusieurs publications transactionnelles qui prennent en charge les abonnements mis à jour en 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 de plages d'identités	@auto_identity_range (déconseillé) et @identityrangemangementoption
Plage d'identités du serveur de publication	@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 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 de colonne	@column_tracking
Options de schéma	@schema_option
Filtrage de colonne	@vertical_partition
Options de chargement de l'Abonné	@subscriber_upload_options
Suivi des suppressions conditionnelles	@delete_tracking
Compensation d'erreur	@compensate_for_errors
Gestion de plages d'identités	@auto_identity_range (déconseillé) et @identityrangemangementoption
Plage d'identités du serveur de publication	@pub_identity_range
Plage d'identités	@identity_range
Seuil de plage d'identités	@threshold
Options de la 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 de fusion non filtrée prennent en charge la publication d'une table dans plusieurs publications, puis les abonnements dans une table unique de la base de données d'abonnement (communément appelée un scénario de cumul (roll up)). Le cumul est souvent utilisé pour agréger en une seule table des sous-ensembles de données provenant de plusieurs emplacements sur un Abonné central. Les publications de fusion filtrées ne prennent pas en charge le scénario avec un Abonné central. Pour la réplication de fusion, le cumul est généralement mis en œuvre via une seule publication avec des filtres de lignes personnalisés. Pour plus d'informations, consultez Filtres de lignes paramétrés.