Abonnements pouvant être mis à jour pour la réplication transactionnelle

S’applique à : SQL Server 2008 (et versions ultérieures)

Dans SQL Server 2014, la réplication transactionnelle prend en charge les mises à jour sur les Abonnés via des abonnements pouvant être mis à jour et la réplication d’égal à égal. Voici les deux types d’abonnements pouvant être mis à jour :

• Mise à jour immédiate. Le serveur de publication et l’Abonné doivent être connectés pour mettre à jour les données sur l’Abonné.

• La mise à jour en file d’attente du serveur de publication et de l’abonné n’a pas besoin d’être connectée pour mettre à jour les données sur l’Abonné. Les mises à jour peuvent être effectuées pendant que l’Abonné ou le serveur de publication est hors connexion.

Lorsque les données sont mises à jour sur un Abonné, elles sont d’abord propagées au serveur de publication, puis propagées à d’autres Abonnés. Si la mise à jour immédiate est utilisée, les modifications sont propagées immédiatement à l’aide du protocole de validation en deux phases. Si la mise à jour en file d’attente est utilisée, les modifications sont stockées dans une file d’attente ; les transactions mises en file d’attente sont ensuite appliquées de manière asynchrone au serveur de publication chaque fois que la connectivité réseau est disponible. Étant donné que les mises à jour sont propagées de manière asynchrone vers le serveur de publication, les mêmes données peuvent avoir été mises à jour par le serveur de publication ou par un autre Abonné et des conflits peuvent se produire lors de l’application des mises à jour. Les conflits sont détectés et résolus en fonction d’une stratégie de résolution de conflit définie lors de la création de la publication.

Si vous créez une publication transactionnelle avec des abonnements pouvant être mis à jour dans l’Assistant Nouvelle publication, la mise à jour immédiate et la mise à jour mise en file d’attente sont activées. Si vous créez une publication avec des procédures stockées, vous pouvez activer une ou les deux options. Lorsque vous créez un abonnement à la publication, vous spécifiez le mode de mise à jour à utiliser. Vous pouvez ensuite basculer entre les modes de mise à jour si nécessaire. Pour plus d’informations, consultez la section suivante « Basculer entre les modes de mise à jour ».

Pour activer les abonnements pouvant être mis à jour pour les publications transactionnelles, activez la mise à jour des abonnements pour les publications transactionnelles

Pour créer des abonnements pouvant être mis à jour pour les publications transactionnelles, consultez Créer un abonnement pouvant être mis à jour dans une publication transactionnelle

Basculement entre les modes de mise à jour

Lorsque vous utilisez des abonnements pouvant être mis à jour, vous pouvez spécifier qu’un abonnement doit utiliser un mode de mise à jour, puis basculer vers l’autre si l’application l’exige. Par exemple, vous pouvez spécifier qu’un abonnement doit utiliser la mise à jour immédiate, mais passer à la mise à jour mise en file d’attente si une défaillance du système entraîne la perte de connectivité réseau.

Si vous passez de la mise à jour immédiate à la mise à jour mise en file d’attente, vous ne pouvez pas revenir à la mise à jour immédiate tant que l’Abonné et le serveur de publication ne sont pas connectés et que l’Agent de lecture de file d’attente a appliqué tous les messages en attente dans la file d’attente au serveur de publication.

Pour basculer entre les modes de mise à jour

Pour basculer entre les modes de mise à jour, vous devez activer la publication et l’abonnement pour les deux modes de mise à jour, puis basculer entre eux si nécessaire. Pour plus d'informations, consultez la rubrique
Basculer entre les modes de mise à jour pour un abonnement transactionnel pouvant être mis à jour.

Considérations relatives à l’utilisation d’abonnements pouvant être mis à jour

• Une fois qu’une publication est activée pour la mise à jour des abonnements ou des abonnements mis à jour en file d’attente, l’option ne peut pas être désactivée pour la publication (bien que les abonnements n’aient pas besoin de l’utiliser). Pour désactiver l’option, la publication doit être supprimée et une autre créée.

• La republication des données n’est pas prise en charge.

• La réplication ajoute la colonne msrepl_tran_version aux tables publiées à des fins de suivi. En raison de cette colonne supplémentaire, toutes les INSERT instructions doivent inclure une liste de colonnes.

• Pour modifier le schéma d'une table dans une publication qui autorise la mise à jour des abonnements, toutes les activités sur la table doivent être arrêtées à l'Éditeur et chez les abonnés, et les modifications de données en attente doivent être propagées à tous les nœuds avant d'effectuer tout changement de schéma. Cela garantit que les transactions en attente ne sont pas en conflit avec la modification du schéma en attente. Une fois que les modifications de schéma ont été propagées à tous les nœuds, l’activité peut reprendre sur les tables publiées. Pour plus d’informations, consultez Suspension d’une topologie de réplication (programmation Transact-SQL de la réplication).

• Si vous envisagez de basculer entre les modes de mise à jour, l’Agent de lecture de file d’attente doit s’exécuter au moins une fois que l’abonnement a été initialisé (par défaut, l’Agent de lecture de file d’attente s’exécute en continu).

• Si la base de données de l’Abonné est partitionnée horizontalement et qu’il existe des lignes dans la partition qui existent sur l’Abonné, mais pas sur le serveur de publication, l’Abonné ne peut pas mettre à jour les lignes préexistantes. La tentative de mise à jour de ces lignes retourne une erreur. Les lignes doivent être supprimées de la table, puis ajoutées au niveau du Publisher.

Mises à jour chez l’Abonné

• Les mises à jour sur l’Abonné sont propagées vers le serveur de publication même si un abonnement a expiré ou est inactif. Vérifiez que ces abonnements sont supprimés ou réinitialisés.

• Si les colonnes TIMESTAMP ou IDENTITY sont utilisées et répliquées en tant que leurs types de données de base, les valeurs de ces colonnes ne doivent pas être mises à jour chez le Abonné.

• Les abonnés ne peuvent pas mettre à jour ou insérer des valeurs text, ntext ou image car il n’est pas possible de lire à partir des tables insérées ou supprimées à l’intérieur des déclencheurs de suivi des modifications de réplication. De même, les Abonnés ne peuvent pas mettre à jour ou insérer les valeurs text ou image à l’aide de WRITETEXT ou UPDATETEXT parce que les données sont remplacées par l'Éditeur. Au lieu de cela, vous pouvez répartir les colonnes text et image en une table distincte et modifier les deux tables au sein d'une transaction.

  Pour mettre à jour des objets volumineux sur un abonné, utilisez les types de données varchar(max), nvarchar(max), varbinary(max) au lieu des types de données text, ntext, et image, respectivement.

• Les mises à jour des clés uniques (y compris les clés primaires) qui génèrent des doublons (par exemple, une mise à jour du formulaire UPDATE <column> SET <column> =<column>+1 n’est pas autorisée et seront rejetées en raison d’une violation d’unicité. Cela est dû au fait que les mises à jour effectuées sur l’Abonné sont propagées par réplication en tant qu’instructions individuelles UPDATE pour chaque ligne affectée.

• Si la base de données de l’Abonné est partitionnée horizontalement et qu’il existe des lignes dans la partition qui existent sur l’Abonné, mais pas sur le serveur de publication, l’Abonné ne peut pas mettre à jour les lignes préexistantes. La tentative de mise à jour de ces lignes retourne une erreur. Les lignes doivent être supprimées de la table et insérées à nouveau.

Déclencheurs définis par l’utilisateur

• Si l'application nécessite des déclencheurs chez l'Abonné, les déclencheurs doivent être définis avec l'option NOT FOR REPLICATION à la fois chez l'Éditeur et chez l'Abonné. Cela garantit que les déclencheurs se déclenchent uniquement pour la modification de données d’origine, mais pas lorsque cette modification est répliquée.

  Vérifiez que le déclencheur défini par l’utilisateur ne se déclenche pas lorsque le déclencheur de réplication met à jour la table. Pour ce faire, appelez la procédure sp_check_for_sync_trigger dans le corps du déclencheur défini par l’utilisateur. Pour plus d’informations, consultez sp_check_for_sync_trigger (Transact-SQL).

Mise à jour immédiate

• Pour la mise à jour immédiate des abonnements, les modifications apportées à l’Abonné sont propagées au serveur de publication et appliquées à l’aide de Microsoft Distributed Transaction Coordinator (MS DTC). Assurez-vous que MS DTC est installé et configuré sur l'éditeur et l'abonné. Pour plus d'informations, consultez la documentation Windows.

• Les déclencheurs utilisés par les abonnements à mise à jour immédiate nécessitent une connexion au serveur de publication pour répliquer les modifications.

• Si la publication autorise la mise à jour instantanée des abonnements et qu'un article de la publication a un filtre de colonnes, vous ne pouvez pas exclure les colonnes obligatoires sans valeur par défaut.

Mise à jour en file d’attente

• Les tables incluses dans une publication de fusion ne peuvent pas également être publiées dans le cadre d’une publication transactionnelle qui autorise la mise à jour en file d’attente des abonnements.

• Les mises à jour apportées aux colonnes de clé primaire ne sont pas recommandées lors de l’utilisation de la mise à jour en file d’attente, car la clé primaire est utilisée comme localisateur d’enregistrements pour toutes les requêtes. Lorsque la stratégie de résolution des conflits est définie sur L'abonné l'emporte, les mises à jour des clés primaires doivent être effectuées avec prudence. Si les mises à jour de la clé primaire sont effectuées à la fois sur le serveur de publication et sur l’Abonné, le résultat est de deux lignes avec des clés primaires différentes.

• Pour les colonnes de type SQL_VARIANTde données : lorsque les données sont insérées ou mises à jour sur l’Abonné, elles sont mappées de la manière suivante par l’Agent de lecture de file d’attente lorsqu’elles sont copiées de l’Abonné vers la file d’attente :

  • BIGINT, , NUMERICDECIMAL, MONEYet SMALLMONEY sont mappés à NUMERIC.

  • BINARY et VARBINARY sont mappés aux VARBINARY données.

Détection et résolution des conflits

• Pour la stratégie de conflit de l’Abonné Wins : la résolution des conflits n’est pas prise en charge pour les mises à jour des colonnes clés primaires.

• Les conflits causés par des échecs de contraintes de clés étrangères ne sont pas résolus par réplication.

  • Si les conflits ne sont pas attendus et que les données sont bien partitionnées (les Abonnés ne mettent pas à jour les mêmes lignes), vous pouvez utiliser des contraintes de clé étrangère sur le serveur de publication et les Abonnés.

  • Si des conflits sont attendus : vous ne devez pas utiliser de contraintes de clés étrangères sur le serveur de publication ou l’Abonné si vous utilisez la résolution des conflits « l’Abonné gagne », vous ne devez pas utiliser de contraintes de clés étrangères sur l’Abonné si vous utilisez la résolution des conflits « le serveur de publication gagne ».

Voir aussi

Réplication transactionnelle d’égal à égal
Réplication transactionnelle
Publier des données et des objets de base de données
S’abonner aux Publications