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 réplication sur l'Abonné mais pas 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 :

1. 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 la validation du compteur de lignes, mais cette méthode ne détecte 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).

2. 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 corrigent les causes exposées à 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 AdventureWorks
    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 correctement gérés afin de ne pas provoquer de non-convergence ou autres problèmes :

  • Les déclencheurs ne doivent provoquer des modifications de données sur l'Abonné que 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. Soit 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 sur 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 sur 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 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 à utiliser avant et après l'application de la capture instantanée. 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 durant le 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 sur l'Abonné lors de l'initialisation de l'abonnement ; lorsque 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 exécute une action différente sur l'Abonné ou n'agit pas sur les même données que sur le serveur de publication, il peut se produire une non-convergence. Soit une procédure qui exécute un calcul puis insère des données résultant de 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 contraintes sont traitées comme des conflits ; elles sont enregistrées dans le journal, mais elles n'amènent pas l'Agent de distribution à cesser la synchronisation. Pour ces deux types de réplications, les violations de contraintes peuvent provoquer une non-convergence si une insertion, une mise à jour ou une suppression qui ont réussi sur un nœud échouent sur un autre.

  Lors de la publication d'une table, les options de schéma par défaut spécifient qu'aucune contrainte de clé étrangère ou de validation ne doit être créée dans la base de données d'abonnement lorsque l'option NOT FOR REPLICATION est sélectionné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).

Voir aussi

Concepts

Dépannage (réplication)