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

S'applique à :SQL Server

La réplication transactionnelle prend en charge les mises à jour chez les abonnés via des abonnements pouvant être mis à jour et la réplication poste à poste. Les deux types d’abonnements pouvant être mis à jour sont les suivants :

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

• Les mises à jour en file d'attente : L'Publisher et l'Abonné n'ont pas besoin d'être connectés pour mettre à jour les données chez l'abonné. Vous pouvez mettre à jour les données pendant que l’abonné ou le Publisher est hors ligne.

Lorsque vous mettez à jour les données chez un abonné, la mise à jour va d’abord au Publisher puis aux autres abonnés. Si vous utilisez une mise à jour immédiate, les modifications sont effectuées immédiatement en utilisant le protocole de validation en deux phases. Si vous utilisez la mise à jour en file d’attente, les modifications vont dans une file d’attente. Les transactions en file d’attente sont envoyées au Publisher de manière asynchrone lorsque la connectivité réseau est disponible. Comme les mises à jour sont envoyées au Publisher de manière asynchrone, les mêmes données peuvent être mises à jour par le Publisher ou par un autre abonné, et des conflits peuvent survenir lors de l’application des mises à jour. Le système détecte et résout les conflits selon une politique de résolution des conflits que vous définissez lors de la création de la publication.

Si vous créez une publication transactionnelle avec des abonnements qui peuvent être mis à jour dans l'Assistant Nouvel abonnement, les deux modes de mise à jour, immédiate et en attente, sont activés. Si vous créez une publication avec des procédures stockées, vous pouvez n'en activer qu'un seul ou les deux. 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, le cas échéant. Pour plus d'informations, consultez la section « Basculement d'un mode de mise à jour à un autre ».

Pour permettre les abonnements à jour pour les publications transactionnelles, voir Activer la mise à jour des abonnements pour les publications transactionnelles.

Pour créer des abonnements à jour pour les publications transactionnelles, voir Créer un abonnement à mise à jour à une publication transactionnelle (Management Studio).

Passage entre les modes de mise à jour

Lorsque vous utilisez des abonnements à mise à jour, vous pouvez spécifier un mode de mise à jour pour un abonnement et passer à l’autre mode si l’application l’exige. Par exemple, vous pouvez spécifier qu’un abonnement utilise une mise à jour immédiate, mais passe à une mise à jour en file d’attente si une défaillance système entraîne une perte de connectivité réseau.

Si vous passez de la mise à jour immédiate à la mise à jour en file d'attente, vous ne pouvez pas revenir à la mise à jour immédiate tant que l'Abonné et le Publisher ne sont pas connectés et que l'Agent de Lecture de File d'attente applique tous les messages en attente dans la file d'attente au Publisher.

Pour basculer d'un mode de mise à jour vers un autre

Pour passer d’un mode de mise à jour à l’autre, activez la publication et l’abonnement pour les deux modes de mise à jour, puis basculez entre les deux si nécessaire. Pour plus d'informations, consultez la rubrique
Basculer entre les modes de mise à jour d'un abonnement transactionnel pouvant être mis à jour.

Considérations pour l’utilisation des abonnements à mettre à jour

• Après avoir activé une publication pour mettre à jour les abonnements ou les abonnements en file d’attente, vous ne pouvez pas désactiver l’option pour la publication (même si les abonnements n’ont pas besoin de l’utiliser). Pour désactiver cette option, supprimez la publication et créez-en une nouvelle.

• 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. Grâce à cette colonne supplémentaire, incluez une liste de colonnes dans toutes les instructions INSERT.

• Pour effectuer des modifications de schéma sur une table dans une publication qui supporte la mise à jour des abonnements, arrêtez toute activité sur la table au niveau du Publisher et des Abonnés, et propagez les modifications de données en attente à tous les nœuds avant d’effectuer toute modification de schéma. Ce processus garantit que les transactions en suspens ne sont pas en conflit avec le changement de schéma en attente. Après que les changements de schéma se propagent à tous les nœuds, l’activité peut reprendre sur les tables publiées. Pour plus d’informations, consultez Mettre en suspens une topologie de réplication (Programmation Transact-SQL de la réplication).

• Pour passer d’un mode de mise à jour à l’autre, l’agent de lecture de file d’attente doit s’exécuter au moins une fois après l’initialisation de l’abonnement (par défaut, l’agent de lecteur de file d’attente s’exécute en continu).

• Si la base de données des abonnés est partitionnée horizontalement et qu'il y a des lignes dans la partition qui existent au niveau de l'abonné mais pas du Publisher, l'abonné ne peut pas mettre à jour les lignes préexistantes. Toute tentative de mise à jour de ces lignes renvoie un message d'erreur. Supprimez les lignes du tableau puis ajoutez-les dans le Publisher.

• La réplication transactionnelle avec des abonnés pouvant être mis à jour en file d’attente peut présenter des performances médiocres lorsque des index filtrés uniques sont utilisés. Si un conflit survient sur un article qui possède des index filtrés uniques, la résolution des conflits entraîne des suppressions et des insertions supplémentaires sur l’abonné pour les lignes non couvertes par l’index filtré unique.

Mises à jour chez l’abonné

• Les mises à jour au niveau de l’abonné sont propagées au Publisher même si un abonnement est expiré ou inactif. Assurez-vous de supprimer ou de réinitialiser ces abonnements.

• Si vous utilisez des colonnes TIMESTAMP ou IDENTITY et les répliquez sous la forme de leurs types de données de base, ne mettez pas à jour les valeurs de ces colonnes sur l’Abonné.

• Les abonnés ne peuvent pas mettre à jour ni insérer des valeurs text, ntext ou image, car les déclencheurs de suivi des modifications de la réplication ne peuvent pas lire dans les tables inserted et deleted. De même, les abonnés ne peuvent pas mettre à jour ou insérer des valeurs de texte ou d'image en utilisant WRITETEXT ou UPDATETEXT car le Publisher écrase les données. À la place, vous pourriez partitionner les colonnes texte et image dans une table séparée et modifier les deux tables au sein d’une transaction.

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

• Les mises à jour des clés uniques (y compris les clés primaires) qui génèrent des doublons, comme une mise à jour du formulaire UPDATE <column> SET <column> =<column>+1, ne sont pas autorisées et sont rejetées en raison d’une violation d’unicité. Les mises à jour des ensembles effectuées à l’abonné se propagent par réplication sous forme d’instructions individuelles UPDATE pour chaque ligne affectée.

• Si la base de données des abonnés est partitionnée horizontalement et que la partition contient des lignes existantes chez l'abonné mais pas chez le Publisher, l'abonné ne peut pas mettre à jour les lignes préexistantes. Toute tentative de mise à jour de ces lignes renvoie un message d'erreur. Supprimez et réinsérez ces lignes.

Déclencheurs définis par l’utilisateur

• Si l’application nécessite des déclencheurs au niveau de l’Abonné, définissez les déclencheurs à l’aide de l’option NOT FOR REPLICATION au niveau du Serveur de publication et de l’Abonné. Cette option garantit que les déclenchements ne s’activent que pour le changement de données initial, mais pas lorsque la réplication propage le changement.

  Assurez-vous 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. 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 les abonnements à mise à jour immédiate, les modifications au niveau de l’abonné se propagent au Publisher et s’appliquent en utilisant Microsoft Distributed Transaction Coordinator (MS DTC). Vérifiez que ce dernier est installé et configuré sur le serveur de publication 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 avec le Publisher pour reproduire les changements.

• Si la publication autorise les abonnements avec mise à jour immédiate et qu’un article de cette publication comporte un filtrage de colonnes, vous ne pouvez pas exclure du filtrage les colonnes qui n’acceptent pas les valeurs Null et qui n’ont pas de valeurs par défaut.

Mise à jour en attente

• Vous ne pouvez pas publier de tables incluses dans une publication de fusion dans le cadre d’une publication transactionnelle qui permet des abonnements à jour en file d’attente.

• Ne mettez pas à jour les colonnes de clé primaire lorsque vous utilisez la mise à jour en file d’attente, car la clé principale sert de localisateur d’enregistrement pour toutes les requêtes. Lorsque la politique de résolution des conflits est définie sur Priorité à l’abonné, faites preuve de prudence lors de la mise à jour des clés primaires. Si le Publisher et l’Abonné mettent à jour la clé primaire, le résultat est deux lignes avec des clés primaires différentes.

• Pour les colonnes de type de données SQL_VARIANT : lorsque des données sont insérées ou mises à jour chez l’abonné, l’agent lecteur de file les mappe de la manière suivante lorsqu’il copie les données de l’abonné à la file d’attente :

  • BIGINT, DECIMAL, NUMERIC, MONEY, et SMALLMONEY sont mappés sur NUMERIC.

  • BINARY et VARBINARY correspondent aux données VARBINARY .

Détection et résolution des conflits

• Pour la politique de conflit « Abonné gagne » : la résolution des conflits ne prend pas en charge les mises à jour des colonnes clés principales.

• La réplication ne résout pas les conflits dus à des défaillances de contraintes de clé étrangère :

  • Si vous ne vous attendez pas à des conflits et que les données sont bien partitionnées (les abonnés ne mettent pas à jour les mêmes lignes), utilisez les contraintes de clé étrangère sur le Publisher et les abonnés.

  • Si vous vous attendez à des conflits : n'utilisez pas de contraintes de clé étrangère chez l'Publisher ou l'Abonné si vous utilisez la résolution de conflits « L'abonné gagne ». N'utilisez pas de contraintes de clé étrangère au niveau de l'Abonné si vous utilisez la résolution de conflits « l'Éditeur l'emporte ».

Contenu connexe

• 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