Partager via

  • Article

Forum Aux Questions pour les Administrateurs de réplication

Les questions et réponses suivantes fournissent des indications sur une variété de tâches auxquelles les administrateurs de bases de données répliquées sont confrontés.

Configuration d'une réplication

L'activité doit-elle être arrêtée sur une base de données lorsqu'elle est publiée ?

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).

Les tables sont-elles verrouillées pendant la génération d'une capture instantanée ?

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.

Quand un abonnement est-il disponible, quand la base de données d'abonnement peut-elle être utilisé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 :

Que se passe-t-il si l’Agent de capture instantanée n’a pas terminé lorsque l’Agent de distribution ou l'Agent de fusion démarre ?

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 :

Dois-je créer un script de ma configuration 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.

Quel est le mode de récupération nécessaire sur une base de données répliquée ?

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.

Pourquoi la réplication ajoute-t-elle une colonne aux tables répliquées, sera-t-elle supprimée si la table n'est pas publiée ?

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.

Comment puis-je gérer les contraintes sur les tables publiées ?

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).

Comment puis-je gérer les colonnes d'identité ?

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é.

Les mêmes objets peuvent-ils être publiés dans différentes publications ?

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.

Plusieurs publications peuvent-elles utiliser la même base de données de distribution ?

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).

Comment puis-je trouver des informations sur le serveur de distribution et de publication, par exemple quels objets d'une base de données sont publiés ?

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.

La réplication chiffre-t-elle les données ?

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).

Comment puis-je répliquer des données via Internet ?

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

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.

La réplication reprend-elle si une connexion est supprimée ?

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.

La réplication fonctionne-t-elle sur les connexions à faible bande passante ? Utilise-t-elle la compression ?

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.

Noms d'accès et propriété d'objet

Les noms d'accès et mots de passe sont-ils répliqués ?

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).

Que sont les schémas et comment sont-ils répliqués ?

À 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).

Comment configurer les demandes sur la base de données d'abonnement afin qu'elles correspondent aux demandes sur la base de données de publication ?

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 :

Qu'advient-il des autorisations accordées dans une base de données d'abonnement si un abonnement est réinitialisé ?

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).

Maintenance de la base de données

Pourquoi ne puis-je pas exécuter TRUNCATE TABLE sur une table publiée ?

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.

Quel est l'effet de l'exécution d'une commande d'insertion en bloc sur une base de données répliquée ?

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.

Existe-t-il des règles de réplication pour l'enregistrement et la restauration ?

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 affecte-t-elle la taille du journal des transactions ?

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.

Comment puis-je reconstruire les index ou les tables dans des bases de données répliquées ?

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.

Comment puis-je ajouter ou modifier des index sur des bases de données de publication ou d'abonnement ?

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.

Comment puis-je déplacer ou renommer des fichiers pour des bases de données impliquées dans une réplication ?

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).

Comment puis-je supprimer une table en cours de réplication ?

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.

Comment puis-je ajouter ou supprimer des colonnes sur une table publiée ?

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.

Maintenance de réplication

Comment puis-je déterminer si les données sur les abonnés sont synchronisées avec celles du serveur 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.

Comment puis-je ajouter une table à une publication existante ?

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.

Comment puis-je supprimer une table d'une publication ?

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.

Quelles actions nécessitent de réinitialiser les abonnements ?

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.

Quelles actions entraînent l'invalidation des captures instantanées ?

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.

Comment puis-je supprimer une réplication ?

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.

Comment puis-je déterminer s'il existe des transactions ou des lignes à répliquer ?

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).

L'Agent de distribution est-il en retard ? Dois-je réinitialiser ?

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).

Réplication et autres fonctionnalités de base de données

La réplication fonctionne-t-elle conjointement avec la copie des journaux et la mise en miroir de bases de données ?

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.

La réplication fonctionne-t-elle conjointement avec le clustering ?

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.