Les données du serveur de publication et de l'Abonné ne concordent pas
Les données du serveur de publication et de l'Abonné sont considérées comme non-convergentes (ne concordent pas) si :
Le nombre de lignes sur l'Abonné et sur le serveur de publication n'est pas identique, et si la publication n'est pas filtrée. Si la publication est filtrée, il se peut que le nombre de lignes diffère.
Le contenu d'une ou plusieurs lignes est différent au niveau du serveur de publication et de l'Abonné.
Explication
Les données du serveur de publication et de l'Abonné peuvent ne pas concorder pour plusieurs raisons :
Les données sont mises à jour sur un Abonné qui devrait être traité en lecture seule. La base de données d'abonnement doit être traitée en lecture seule sauf si vous utilisez la réplication de fusion, la réplication transactionnelle avec des abonnements pouvant être mis à jour, ou la réplication transactionnelle d'égal à égal.
Des déclencheurs sont utilisés sur l'Abonné. Les déclencheurs peuvent modifier les données sur l'Abonné ou empêcher leur mise à jour si le déclencheur émet un ROLLBACK.
Des scripts sont exécutés par la réplication sur l'Abonné mais pas par la réplication sur le serveur de publication.
La réplication de l'exécution de procédures stockées pour une publication transactionnelle produit des résultats différents sur l'Abonné.
Des violations de contraintes ou d'autres problèmes empêchent l'insertion, la mise à jour ou la suppression de lignes sur l'Abonné.
Action de l'utilisateur
Les actions suivantes expliquent comment déterminer si les données ne sont pas convergentes, et comment les faire converger :
Déterminer si les données sont non-convergentes à l'aide de la validation ou de l'utilitaire tablediff :
Si l'Agent de distribution ou l'Agent de fusion est en mesure de s'exécuter, déterminez s'il manque des données en exécutant une validation du total de contrôle binaire. Vous pouvez aussi utiliser une validation de comptage des lignes, mais cette méthode ne révèle pas les différences dans le contenu des données. Pour plus d'informations, consultez Validation des données répliquées.
Si l'Agent de distribution ou l'Agent de fusion n'est pas en mesure de s'exécuter, déterminez s'il y a non-convergence des données en exécutant l'utilitaire tablediff. Pour plus d'informations sur l'utilisation de cet utilitaire sur les tables répliquées, consultez Procédure : comparer les tables répliquées pour les différences (programmation de réplication).
Si les données ne sont pas convergentes, vous pouvez recourir à l'utilitaire tablediff pour générer un script Transact-SQL afin de faire converger ces données. Pour plus d'informations, consultez Utilitaire tablediff.
Corriger la cause de non-convergence
Les actions qui suivent permettent de résoudre les problèmes décrits à la section « Explication » :
Les données sont mises à jour sur l'Abonné hors réplication :
Si vous voulez autoriser des utilisateurs à insérer, mettre à jour et supprimer des données sur l'Abonné, utilisez la réplication de fusion, la réplication transactionnelle avec des abonnements pouvant être mis à jour, ou la réplication transactionnelle d'égal à égal. Pour plus d'informations, consultez Présentation de la réplication de fusion et Types de publication pour la réplication transactionnelle.
Si vous souhaitez empêcher les utilisateurs d'insérer, mettre à jour et supprimer des données sur l'Abonné, créez un déclencheur pour chaque table contenant le mot ROLLBACK et utilisant l'option NOT FOR REPLICATION (qui empêche le déclencheur de s'exécuter lorsqu'un Agent de réplication exécute une opération). Par exemple :
USE AdventureWorks2008R2; GO CREATE TRIGGER prevent_user_dml ON Person.Address FOR INSERT, UPDATE, DELETE NOT FOR REPLICATION AS ROLLBACK;Pour plus d'informations, consultez CREATE TRIGGER (Transact-SQL) et Contrôle des contraintes, des identités et des déclencheurs avec l'option NOT FOR REPLICATION.
Des déclencheurs sont utilisés sur l'Abonné. Les déclencheurs sur l'Abonné doivent être gérés correctement de façon à ce qu'ils ne provoquent pas une non-convergence ou d'autres problèmes :
Les déclencheurs doivent seulement provoquer des modifications de données sur l'Abonné si vous utilisez la réplication de fusion, la réplication transactionnelle avec des abonnements pouvant être mis à jour ou la réplication transactionnelle d'égal à égal. Pour plus d'informations, consultez Présentation de la réplication de fusion et Types de publication pour la réplication transactionnelle.
Dans de nombreux cas, les déclencheurs doivent utiliser l'option NOT FOR REPLICATION. Prenons l'exemple d'un déclencheur qui insère des données dans une table de suivi : lorsque l'utilisateur insère la ligne à l'origine, il est normal que le déclencheur s'exécute et entre une ligne dans la table de suivi, mais il ne doit pas se déclencher lorsque ces données sont répliquées vers l'Abonné, parce que cela provoquerait l'insertion d'une ligne inutile dans la table de suivi.
Si un déclencheur comporte une instruction ROLLBACK et s'il n'utilise pas l'option NOT FOR REPLICATION, les lignes qui ont été répliquées vers un Abonné risquent de ne pas être appliquées.
Pour la réplication transactionnelle, il existe d'autres considérations à propos du paramètre XACT_ABORT et de l'utilisation des instructions COMMIT et ROLLBACK dans un déclencheur. Pour plus d'informations, consultez la section « Déclencheurs » de Considérations pour la réplication transactionnelle.
Des scripts sont exécutés par la réplication sur l'Abonné mais pas par la réplication sur le serveur de publication.
Les paramètres @pre_snapshot_script et @post_snapshot_script de sp_addpublication et sp_addmergepublication vous permettent de spécifier des scripts à exécuter avant et après l'application de l'instantané. Pour plus d'informations, consultez Exécution de scripts avant et après l'application de la capture instantanée. La procédure stockée sp_addscriptexec vous permet d'exécuter un script au cours du processus de synchronisation. Pour plus d'informations, consultez Procédure : exécuter des scripts pendant la synchronisation (programmation Transact-SQL de la réplication).
Ces scripts sont en général utilisés pour des tâches d'administration, telles que l'ajout d'informations de connexion sur l'Abonné. Si des scripts sont utilisés pour mettre à jour sur l'Abonné des données qui doivent être traitées en lecture seule, l'administrateur doit s'assurer qu'il ne se produit pas de non-convergence.
La réplication de l'exécution de procédures stockées pour une publication transactionnelle produit des résultats différents sur l'Abonné.
Si vous répliquez l'exécution d'une procédure stockée, la définition de la procédure est répliquée vers l'Abonné quand l'abonnement est initialisé ; quand la procédure est exécutée sur le serveur de publication, la réplication exécute la procédure correspondante sur l'Abonné. Pour plus d'informations, consultez Publication de l'exécution de procédures stockées dans la réplication transactionnelle.
Si la procédure stockée effectue une action différente sur l'Abonné ou agit sur des données différentes de celles du serveur de publication, une non-convergence peut se produire. Supposons une procédure qui effectue un calcul puis insère des données basées sur ce calcul. Si l'Abonné est filtré de telle sorte que le calcul sur l'Abonné soit basé sur des données différentes, le résultat inséré sur l'Abonné peut être différent, ou il se peut que l'insertion ne soit pas effectuée.
Des violations de contraintes ou d'autres problèmes empêchent l'insertion, la mise à jour ou la suppression de lignes sur l'Abonné.
Pour la réplication transactionnelle, les violations de contraintes sont traitées comme des erreurs ; par défaut elles amènent l'Agent de distribution à cesser la synchronisation lorsqu'elles se produisent (pour plus d'informations sur le moyen d'ignorer ces erreurs, consultez Omission des erreurs lors de la réplication transactionnelle). Pour la réplication de fusion, les violations de contrainte sont traitées comme des conflits ; elles sont journalisées mais ne provoquent pas l'arrêt de la synchronisation de l'Agent de fusion. Pour les deux types de réplication, les violations de contrainte peuvent conduire à la non-convergence si une insertion, une mise à jour ou une suppression qui a réussi sur un nœud échoue sur un autre.
Quand une table est publiée, les options de schéma par défaut spécifient que les contraintes de clé étrangère et les contraintes de validation doivent être créées dans la base de données d'abonnement avec l'option NOT FOR REPLICATION activée. Si votre application nécessite des paramètres différents pour les contraintes, modifiez les options de schéma. Pour plus d'informations, 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).