Questions fréquentes (FAQ) pour les administrateurs de la réplication

Non. L'activité peut continuer sur une base de données pendant la création d'une publication. Sachez que la création d'un instantané utilise de nombreuses ressources, il est donc préférable de générer les instantanés lors de périodes de faible activité sur la base de données (un instantané est généré par défaut lorsque vous terminez l'Assistant Nouvelle publication).

La durée de verrouillage dépend du type de réplication utilisé :

• Pour les publications de fusion, l'Agent d'instantané n'utilise aucun verrou.

• Pour les publications transactionnelles, par défaut l'Agent d'instantané utilise des verrous uniquement lors de la phase initiale de génération d'instantané.

• Pour les publications d'instantané, l'Agent d'instantané utilise des verrous pendant toute la durée du processus de génération d'instantané.

Comme les verrous empêchent les autres utilisateurs de mettre à jour les tables, l'exécution de l'Agent d'instantané devrait être planifiée lors de périodes de faible activité sur la base de données, principalement pour les publications d'instantané.

Un abonnement est disponible après que l'instantané ait été appliqué à la base de données d'abonnement. Bien que la base de données d'abonnement soit accessible avant, il est conseillé de ne pas l'utiliser tant que l'instantané n'a pas été appliqué. Utilisez le Moniteur de réplication pour vérifier l'état de génération et d'application d'instantané :

• L'instantané est généré par l'Agent d'instantané. Affichez l'état de génération de l'instantané sur l'onglet Agents pour une publication du moniteur de réplication. Pour plus d’informations, consultez Afficher des informations et effectuer des tâches à l’aide du moniteur de réplication.

• L'instantané est appliqué par l'Agent de distribution ou par l'Agent de fusion. Affichez l'état d'application d'instantané sur la page Agent de distribution ou Agent de fusion du Moniteur de réplication. Pour plus d’informations, consultez Afficher des informations et effectuer des tâches à l’aide du moniteur de réplication.

Cela n'entraînera aucune erreur si l'Agent de distribution ou l'Agent de fusion s'exécute en même temps que l'Agent d'instantané. Vous devez cependant prendre en compte les éléments suivants :

• Si l'Agent de distribution ou l'Agent de fusion est configuré pour une exécution en continu, l'Agent applique automatiquement l'instantané une fois que l'Agent d'instantané est terminé.

• Si l'Agent de distribution ou l'Agent de fusion est configuré pour une exécution planifiée ou à la demande, et qu'aucun instantané n'est disponible pendant que l'Agent s'exécute, l'Agent s'arrêtera en affichant un message indiquant qu'un instantané n'est pas encore disponible. Vous devez relancer l'exécution de l'Agent pour appliquer l'instantané une fois que l'Agent d'instantané est terminé. Pour plus d’informations sur l’exécution des agents, consultez Synchroniser un abonnement par émission de données, Synchroniser un abonnement par extraction et Concepts des exécutables de l’agent de réplication.

Oui. Le script de la configuration de réplication est un composant clé de tout plan de récupération d'urgence pour une topologie de réplication. Pour plus d'informations sur les scripts, consultez Scripting Replication.

La réplication fonctionne correctement à l'aide de n'importe quel mode de récupération : simple, journalisé en bloc ou restauration complète. La réplication de fusion assure le suivi des modifications en stockant les informations dans des tables de métadonnées. La réplication transactionnelle assure le suivi des modifications par un marquage du journal des transactions, mais ce processus de marquage n'est pas concerné par le mode de récupération.

Afin d'assurer le suivi des modifications, la réplication de fusion et la réplication transactionnelle avec mise à jour d'abonnements en attente doivent pouvoir identifier de manière unique chaque ligne dans chaque table publiée. À cet effet :

• La réplication de fusion ajoute la colonne rowguid à chaque table, à moins que la table ne dispose déjà d'une colonne de type de données uniqueidentifier avec la propriété ROWGUIDCOL définie (auquel cas cette colonne est utilisée). Si la table est supprimée de la publication, la colonne rowguid est supprimée, si une colonne existante était utilisée pour le suivi, la colonne n'est pas supprimée.

• Si une publication transactionnelle prend en charge la mise à jour d'abonnements en attente, la réplication ajoute la colonne msrepl_tran_version à chaque table. Si la table est supprimée de la publication, la colonne msrepl_tran_version n'est pas supprimée.

• Aucun filtre ne doit inclure le rowguidcol utilisé par la réplication pour identifier les lignes. Par défaut, il s'agit de la colonne ajoutée lorsque vous avez configuré la réplication de fusion et qui a pour nom rowguid.

Il convient de tenir compte de plusieurs problèmes concernant les contraintes sur les tables publiées :

• La réplication transactionnelle nécessite une contrainte de clé primaire sur chaque table publiée. La réplication de fusion ne nécessite pas de clé primaire, mais s'il en existe une, elle doit être répliquée. La réplication d'instantané ne nécessite pas de clé primaire.

• Par défaut, les contraintes de clé primaire, les index et les contraintes de validation sont répliquées aux abonnés.

• L'option NOT FOR REPLICATION est spécifiée par défaut pour les contraintes de clé étrangère et les contraintes de validation, les contraintes étant renforcées pour les opérations d'utilisateurs mais pas pour les opérations d'agents.

Pour plus d'informations sur le paramétrage des options de schéma permettant de contrôler si les contraintes sont répliquées, consultez Specify Schema Options.

La réplication fournit une gestion automatique de plages d'identité pour les topologies de réplication comprenant des mises à jour sur l'Abonné. Pour plus d’informations, consultez Répliquer des colonnes d’identité.

Oui, mais avec quelques restrictions. Pour plus d’informations, consultez la section « Publication de tables dans plusieurs publications » de la rubrique Publier des données et des objets de base de données.

Oui. Il n'existe aucune restriction sur le nombre ou les types de publications pouvant utiliser la même base de données de distribution. Toutes les publications d'un serveur de publication donné doivent utiliser le même serveur de distribution et la même base de données de distribution.

Si vous avez plusieurs publications, vous pouvez configurer plusieurs bases de données de distribution sur l'Abonné pour garantir que les données passant dans chaque base de données de distribution proviennent d'une seule publication. Utilisez la boîte de dialogue Propriétés du serveur de distribution ou sp_adddistributiondb (Transact-SQL) pour ajouter une base de données de distribution. Pour plus d’informations sur l’accès à cette boîte de dialogue, consultez Afficher et modifier les propriétés d’un serveur de distribution ou d’un serveur de publication.

Ces informations sont disponibles via SQL Server Management Studio et plusieurs procédures stockées de réplication. Pour plus d’informations, voir Distributor and Publisher Information Script.

Non. La réplication ne chiffre pas les données stockées dans la base de données ou transférées sur le réseau. Pour plus d’informations, consultez la section « Chiffrement » de la rubrique Afficher et modifier les paramètres de sécurité de la réplication.

Vous pouvez répliquer des données via Internet en utilisant :

• Un réseau privé virtuel (VPN). Pour plus d’informations, consultez Publier des données sur Internet à l’aide d’un réseau privé virtuel.

• L'option de synchronisation Web pour la réplication de fusion. Pour plus d’informations, voir Web Synchronization for Merge Replication.

Même si tous les types de réplication Microsoft SQL Server peuvent répliquer des données via un réseau privé virtuel (VPN), utilisez plutôt la synchronisation Web avec la réplication de fusion.

Oui. Le traitement de la réplication reprend là où il s'est interrompu si une connexion est supprimée. Si vous utilisez une réplication de fusion sur un réseau non fiable, envisagez d'utiliser des enregistrements logiques qui garantissent que les modifications liées sont traitées en tant qu'unité. Pour plus d’informations, consultez Regrouper les modifications apportées à des lignes connexes à l’aide d’enregistrements logiques.

Oui, la réplication fonctionne sur les connexions à faible bande passante. Pour les connexions via TCP/IP, elle utilise la compression fournie par le protocole mais ne fournit pas de compression supplémentaire. Pour les connexions à synchronisation Web via HTTPS, elle utilise la compression fournie par le protocole ainsi qu'une compression supplémentaire des fichiers XML utilisés pour répliquer les modifications.

Non, la réplication fonctionne uniquement quand vous utilisez le nom réel du serveur. À compter de SQL Server Management Studio (SSMS) 18.0 (et versions ultérieures), la réplication peut être configurée en utilisant le nom réel du serveur et le numéro de port.

Non. Vous pourriez créer un package SSIS pour transférer des connexions et des mots de passe d'un serveur de publication vers un ou plusieurs abonnés.

À compter de Microsoft SQL Server 2005 (9.x), le schéma a deux significations :

• La définition d'un objet, par exemple une instruction CREATE TABLE. Par défaut, la réplication copie les définitions de tous les objets répliqués sur l'Abonné.

• L’espace de noms dans lequel un objet est créé : <Base de données>.<Schéma>.<Objet>. Les schémas sont définis à l'aide de l'instruction CREATE SCHEMA.

• 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 dans les publications qui utilisent des instantanés en mode caractère (qui sont utilisés 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 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 changé par le biais de 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.

Par défaut, la réplication n'exécute pas d'instructions GRANT sur la base de données d'abonnement. Si vous voulez que les autorisations sur la base de données d'abonnement correspondent à celles de la base de données de publication, utilisez une des méthodes suivantes :

• Exécutez les instructions GRANT directement sur la base de données d'abonnement.

• Utilisez un script après l'instantané pour exécuter les instructions. Pour plus d’informations, consultez Exécuter des scripts avant et après l’application de l’instantané.

• Utilisez la procédure stockée sp_addscriptexec pour exécuter les instructions.

Par défaut, les objets sur l'Abonné sont supprimés et recréés lorsqu'un abonnement est réinitialisé, ce qui entraîne la suppression de toutes les autorisations accordées à ces objets. Il existe deux moyens de gérer cela :

• Appliquer à nouveau les demandes après la réinitialisation à l'aide des techniques décrites dans la section précédente.

• Spécifier de ne pas supprimer les objets lorsque l'abonnement est réinitialisé. Avant la réinitialisation, vous pouvez au choix :

  • Exécutez sp_changearticle ou sp_changemergearticle. Spécifiez la valeur « pre_creation_cmd » (sp_changearticle) ou « pre_creation_command » (sp_changemergearticle) pour le paramètre @property et la valeur « none », « delete » ou « truncate » pour le paramètre @value.

  • Dans la boîte de dialogue Propriétés de l’article - <Article> dans la section Objet de destination, sélectionnez une valeur de Conserver l’objet existant inchangé, Supprimer des données. Si l’article a un filtre de lignes, supprimez uniquement les données qui correspondent au filtre. ou tronquer toutes les données de l’objet existant pour l’action d’option si le nom est utilisé. Pour plus d’informations sur l’accès à cette boîte de dialogue, consultez Afficher et modifier les propriétés d’un serveur de publication.

TRUNCATE TABLE est une instruction DDL qui ne consigne pas les suppressions de lignes individuelles et qui n’exécute pas de déclencheurs DML. Cette opération n’est pas autorisée, car la réplication ne peut pas assurer le suivi des modifications engendrées par cette opération : la réplication transactionnelle assure le suivi des modifications via le journal des transactions, tandis que la réplication de fusion s’en charge par le biais de déclencheurs DMS dans les tables publiées.

Pour la réplication transactionnelle, les insertions en bloc sont suivies et répliquées comme les autres insertions. Pour la réplication de fusion, vous devez vérifier que les métadonnées de suivi des modifications sont correctement mises à jour.

Oui. Il existe de nombreuses règles spécifiques pour les bases de données impliquées dans une réplication. Pour plus d’informations, consultez Sauvegarder et restaurer des bases de données répliquées.

La réplication de fusion et la réplication d'instantané n'affectent pas la taille du journal des transactions, contrairement à la réplication transactionnelle. Si une base de données comprend une ou plusieurs publications transactionnelles, le journal n'est pas tronqué tant que toutes les transactions relatives aux publications n'ont pas été remises à la base de données de distribution. Si la taille du journal des transactions devient trop importante et que l'Agent de lecture du journal s'exécute de manière planifiée, envisagez de réduire l'intervalle entre les exécutions. Ou, définissez-le pour qu'il s'exécute en mode continu. S'il est paramétré pour s'exécuter en mode continu (par défaut), vérifiez qu'il fonctionne. Pour plus d’informations sur la vérification de l’état de l’Agent de lecture du journal, consultez Afficher des informations et effectuer des tâches à l’aide du moniteur de réplication.

De plus, si vous avez défini l'option « sync with backup » sur la base de données de publication ou la base de données de distribution, le journal des transactions n'est pas tronqué tant que toutes les transactions ne sont pas sauvegardées. Si la taille du journal des transactions devient trop importante et que cette option est définie, envisagez de réduire l'intervalle entre les enregistrements du journal des transactions. Pour plus d’informations sur la sauvegarde et la restauration des bases de données impliquées dans la réplication transactionnelle, consultez Stratégies de sauvegarde et de restauration de la réplication transactionnelle et d’instantané.

Il existe différents mécanismes pour la reconstruction d'index. Ils peuvent tous être utilisés sans règle spécifique à la réplication, à l'exception suivante près : des clés primaires sont nécessaires sur les tables dans les publications transactionnelles, vous ne pouvez donc pas supprimer et recréer de clés primaires sur ces tables.

Les index peuvent être ajoutés sur le serveur de publication ou sur les abonnés sans règle spécifique à la réplication (sachez que les index peuvent affecter les performances). CREATE INDEX et ALTER INDEX ne sont pas répliqués, donc si par exemple vous ajoutez ou modifiez un index sur le serveur de publication, vous devez effectuer le même ajout ou la même modification sur l'abonné si vous souhaitez qu'il ou elle soit prise en compte.

Dans les versions de SQL Server antérieures à SQL Server 2005 (9.x), le déplacement ou le changement de noms de fichiers de base de données nécessitait le détachement et le rattachement de la base de données. Comme une base de données répliquée ne peut pas être détachée, la réplication a d'abord du être supprimée de ces bases de données. Avec SQL Server 2005 (9.x),, vous pouvez déplacer ou renommer les fichiers sans détachement ou rattachement de la base de données, sans aucune incidence sur la réplication. Pour plus d’informations sur le déplacement et le changement de noms de fichiers, consultez ALTER DATABASE (Transact-SQL).

Commencez par supprimer l’article de la publication en utilisant sp_droparticle, sp_dropmergearticle ou la boîte de dialogue Propriétés de la publication - <Publication>, puis supprimez-le de la base de données à l’aide de DROP <Object>. Vous ne pouvez pas supprimer d'articles d'un instantané ou de publications transactionnelles après avoir ajouté les abonnements, vous devez d'abord supprimer les abonnements. Pour plus d’informations, consultez Ajouter et supprimer des articles de publications existantes.

SQL Server prend en charge une large variété de modifications de schéma sur les objets publiés, y compris l'ajout et la suppression de colonnes. Par exemple, exécutez ALTER TABLE … DROP COLUMN sur le serveur de publication et l’instruction est répliquée vers les abonnés, puis exécutée pour supprimer la colonne. Les abonnés qui exécutent des versions de SQL Server antérieures à SQL Server 2005 (9.x) prennent en charge l'ajout et la suppression de colonnes à travers les procédures stockées sp_repladdcolumn et sp_repldropcolumn. Pour plus d’informations, consultez Modifier le schéma dans les bases de données de publication.

Utilisez la validation. La validation fournit un rapport sur la synchronisation ou non de l'Abonné avec le serveur de publication. Pour plus d’informations, consultez Valider des données répliquées. La validation ne fournit pas d'informations sur les lignes non correctement synchronisées, à l'inverse de l'utilitaire tablediff utility .

Il n'est pas nécessaire d'arrêter l'activité sur les bases de données de publication ou d'abonnement pour ajouter une table (ou un autre objet). Ajoutez une table à une publication par le biais de la boîte de dialogue Propriétés de la publication - <Publication> ou des procédures stockées sp_addarticle et sp_addmergearticle. Pour plus d’informations, consultez Ajouter et supprimer des articles de publications existantes.

Supprimez une table de la publication en utilisant sp_droparticle, sp_dropmergearticle ou la boîte de dialogue Propriétés de la publication - <Publication>. Vous ne pouvez pas supprimer d'articles d'un instantané ou de publications transactionnelles après avoir ajouté les abonnements, vous devez d'abord supprimer les abonnements. Pour plus d’informations, consultez Ajouter et supprimer des articles de publications existantes.

Il existe de nombreuses modifications d'articles et de publications qui nécessitent de réinitialiser les abonnements. Pour plus d’informations, consultez Modifier les propriétés des publications et des articles.

Il existe de nombreuses modifications d'articles et de publications qui invalident les instantanés et nécessitent de générer un nouvel instantané. Pour plus d’informations, consultez Modifier les propriétés des publications et des articles.

Les actions nécessaires à la suppression de la réplication d'une base de données varient suivant que la base de données ait servi de base de données de publication, de base de données d'abonnement, ou des deux à la fois.

Pour la réplication transactionnelle, utilisez les procédures stockées ou l'onglet Commandes non distribuées du Moniteur de réplication. Pour plus d’informations, consultez Afficher les commandes répliquées et autres informations dans la base de données de distribution (Programmation Transact-SQL de la réplication) et Afficher des informations et effectuer des tâches à l’aide du moniteur de réplication.

Pour la réplication de fusion, utilisez la procédure stockée sp_showpendingchanges. Pour plus d’informations, consultez sp_showpendingchanges (Transact-SQL).

Utilisez la procédure stockée sp_replmonitorsubscriptionpendingcmds ou l'onglet Commandes non distribuées du Moniteur de réplication. La procédure stockée et l'onglet affichent :

• Nombre de commandes dans la base de données de distribution qui n'ont pas été distribuées à l'abonné sélectionné. Une commande est constituée d'une instruction DML (Data Manipulation Language) Transact-SQL ou d'une instruction DDL (Data Definition Language).

• Délai estimé de distribution des commandes à l'Abonné. Si cette valeur est supérieure au délai nécessaire pour générer et appliquer un instantané à l'Abonné, réinitialisez l'Abonné. Pour plus d’informations, consultez Réinitialiser des abonnements.

Pour plus d’informations, consultez sp_replmonitorsubscriptionpendingcmds (Transact-SQL) et Afficher des informations et effectuer des tâches à l’aide du moniteur de réplication.

Oui. Pour plus d’informations, consultez Copie des journaux de transaction et réplication (SQL Server) et Mise en miroir de bases de données et réplication (SQL Server).

Oui. Aucune règle spécifique n'est nécessaire car toutes les données sont stockées sur un ensemble de disques sur le cluster.

Nous vous recommandons de contacter le fournisseur tiers pour toute question de support. En règle générale, si le problème est isolé par le fournisseur pour être un problème de réplication de base fourni avec SQL Server, Support Microsoft est impliqué pour aider davantage.

Voir aussi

FAQ sur l’administration de la réplication
Best Practices for Replication Administration