Forum Aux Questions pour les Administrateurs de 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'une capture instantanée utilise de nombreuses ressources, il est donc préférable de générer les captures instantanées lors de périodes de faible activité sur la base de données (une capture instantanée est générée 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 de capture instantanée n'utilise aucun verrou.

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

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

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

Un abonnement est disponible après que la capture instantanée ait été appliquée à 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 la capture instantanée n'a pas été appliquée. Utilisez le Moniteur de réplication pour vérifier l'état de génération et d'application de capture instantanée :

• La capture instantanée est générée par l'Agent de capture instantanée. Affichez l'état de génération de la capture instantanée sur l'onglet Agents pour une publication du moniteur de réplication. Pour plus d'informations, consultez Procédure : afficher des informations et effectuer des tâches pour les agents associés à une publication (moniteur de réplication).

• La capture instantanée est appliquée par l'Agent de distribution ou par l'Agent de fusion. Affichez l'état d'application de capture instantanée sur la page Agent de distribution ou Agent de fusion du Moniteur de réplication. Pour plus d'informations, consultez Procédure : afficher des informations et effectuer des tâches pour les agents associés à un abonnement (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 de capture instantanée. 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 la capture instantanée une fois que l'Agent de capture instantanée 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'aucune capture instantanée n'est disponible pendant que l'Agent s'exécute, l'Agent s'arrêtera en affichant un message indiquant qu'une capture instantanée n'est pas encore disponible. Vous devez relancer l'exécution de l'Agent pour appliquer la capture instantanée une fois que l'Agent de capture instantanée est terminé. Pour plus d'informations sur l'exécution d'agents, consultez Procédure : synchroniser un abonnement par envoi de données (SQL Server Management Studio), Procédure : synchroniser un abonnement par extraction de données (SQL Server Management Studio) 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 Création de scripts de réplication.

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.

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 de capture instantanée 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, consultez Contrôle des contraintes, des identités et des déclencheurs avec l'option NOT FOR REPLICATION.

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 Procédure : spécifier des options de schéma (SQL Server Management Studio) et Procédure : spécifier des options de schéma (programmation Transact-SQL de la réplication).

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éplication de colonnes d'identité.

Oui, mais avec quelques restrictions. Pour plus d'informations, consultez la section « Publication de tables dans plusieurs publications » dans la rubrique Publication de données et d'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 la manière d'accéder à la boîte de dialogue, consultez Procédure : afficher et modifier les propriétés du serveur de distribution (SQL Server Management Studio).

Ces informations sont disponibles via SQL Server Management Studio et plusieurs procédures stockées de réplication. Pour plus d'informations, consultez Propriétés de la réplication et Script d'information du serveur de distribution et du serveur de publication.

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 Vue d'ensemble de la sécurité (réplication).

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

• Un réseau privé virtuel (VPN). Pour plus d'informations, consultez Publication de 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, consultez Synchronisation Web pour la réplication de fusion.

Tous les types de réplication Microsoft SQL Server peuvent répliquer des données via un réseau privé virtuel (VPN), mais vous devrez plutôt utiliser la synchronisation Web si vous utilisez une 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 Regroupements des 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. Pour plus d'informations concernant la réplication sur les connexions à faible bande passante, consultez Un réseau lent provoque des problèmes.

Non. Vous pourriez créer un package DTS pour transférer les noms d'accès et mots de passe d'un serveur de publication sur un ou plusieurs abonnés. Pour plus d'informations, consultez Conception et implémentation de packages (Integration Services).

À commencer par Microsoft SQL Server 2005, 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. Pour plus d'informations sur les schémas, consultez Schémas (moteur de base de données).

• 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 de capture instantanée 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 dans les publications Oracle : le propriétaire est spécifié comme dbo par défaut.

• Pour les articles dans les publications qui utilisent les captures instantanées en mode caractère (qui sont utilisées pour les Abonnées non-SQL Server et pour les Abonnés SQL Server Compact 3.5 SP1) : 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 Procédure : Affichage et modification des propriétés de l'article et de la publication (SQL Server Management Studio), Procédure : définir un article (programmation Transact-SQL de la réplication) et Procédure : afficher et modifier les propriétés des articles (programmation Transact-SQL de la réplication).

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 la capture instantanée pour exécuter les instructions. Pour plus d'informations, consultez Exécution de scripts avant et après l'application de la capture instantanée.

• 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 une valeur « pre_creation_cmd » (sp_changearticle) ou « pre_creation_command » (sp_changemergearticle) pour le paramètre @property et une valeur « none », « delete » ou « truncate » pour le paramètre @value.

  • Dans la boîte de dialogue Propriétés de l'article - <Article> de la section Objet de destination, sélectionnez Conserver l'objet existant inchangé, Supprimez les données. Si l'article possède un filtre de lignes, supprimez uniquement les données qui correspondent au filtre. ou Tronquer toutes les données dans l'objet existant pour l'option Action si le nom est déjà utilisé. Pour plus d'informations sur l'accès à cette boîte de dialogue, consultez Procédure : Affichage et modification des propriétés de l'article et de la publication (SQL Server Management Studio).

TRUNCATE TABLE est une opération non journalisée qui n'exécute pas de déclencheurs. Cette opération n'est pas autorisée car la réplication ne peut 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, la réplication de fusion via des déclencheurs sur 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. Pour plus d'informations, consultez la section « Insertion en bloc de données dans des tables publiées » dans Considérations sur la réplication de fusion.

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 Sauvegarde et restauration de bases de données répliquées.

La réplication de fusion et la réplication de capture instantanée 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 Procédure : afficher des informations et effectuer des tâches pour les agents associés à une publication (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 l'enregistrement et la restauration de bases de données concernées par la réplication transactionnelle, consultez Stratégies de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée.

Il existe différents mécanismes pour la reconstruction d'index. Il 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 qu'elle soit prise en compte.

Dans les versions de SQL Server antérieures à SQL Server 2005, 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, 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 à l'aide de sp_droparticle, de sp_dropmergearticle ou de 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'une capture instantanée ou de publications transactionnelles après avoir ajouté les abonnements, vous devez d'abord supprimer les abonnements. Pour plus d'informations, consultez Ajout et suppression d'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, si l'instruction ALTER TABLE … DROP COLUMN est exécutée sur le serveur de publication, l'instruction est répliquée sur 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 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 Modification du 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 Validation 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 à l'aide 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 Ajout et suppression d'articles de publications existantes.

Supprimez une table de la publication à l'aide de sp_droparticle, sp_dropmergearticle ou de la boîte de dialogue Propriétés de la publication - <Publication>. Vous ne pouvez pas supprimer d'articles d'une capture instantanée ou de publications transactionnelles après avoir ajouté les abonnements, vous devez d'abord supprimer les abonnements. Pour plus d'informations, consultez Ajout et suppression d'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 Modification des propriétés des publications et des articles.

Il existe de nombreuses modifications d'articles et de publications qui invalident les captures instantanées et nécessitent de générer une nouvelle capture instantanée. Pour plus d'informations, consultez Modification des 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 plus d'informations, consultez Suppression de la réplication.

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 Procédure : 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 Procédure : afficher des informations et effectuer des tâches pour les agents associés à un abonnement (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 :

• Le nombre de commandes dans la base de données de distribution n'ayant pas été remises à l'Abonné sélectionné. Une commande comprend une instruction de langage de manipulation de données (DML) Transact-SQL ou une instruction de langage de définition de données (DDL).

• Le délai estimé pour livrer les commandes à l'Abonné. Si cette valeur est supérieure au délai nécessaire pour générer et appliquer une capture instantanée sur l'Abonné, envisagez de réinitialiser l'Abonné. Pour plus d'informations, consultez Réinitialisation d'un abonnement.

Pour plus d'informations, consultez sp_replmonitorsubscriptionpendingcmds (Transact-SQL) et Procédure : afficher des informations et effectuer des tâches pour les agents associés à un abonnement (Moniteur de réplication).

Oui. Pour plus d'informations, consultez Réplication et copie des journaux de transaction et Réplication et mise en miroir des bases de données.

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.