[Déconseillé] Le LSN spécifié pour l'analyse du journal repldone est avant le début de la réplication dans le journal

Résumé

Le numéro séquentiel dans le journal spécifié pour l'analyse du journal repldone survient avant le début de réplication dans le journal.

Causes

Le journal des transactions contient des transactions non répliquées marquées pour la réplication, mais aucun Agent de lecture du journal n'est disponible pour les lire. L'Agent de lecture du journal livre des commandes et des transactions répliquées dans des transactions à la base de données de distribution. Chaque fois qu'une transaction est validée, l'Agent de lecture du journal appelle sp_repldone dans la base de données du serveur de publication pour marquer les informations comme le numéro de séquence de la dernière transaction distribuée et l'enregistrement de validation de la transaction suivante à analyser, le cas échéant. Comme sp_repldone est appelée dans la base de données du serveur de publication, après validation de la transaction dans la base de données de distribution, il est possible que certaines données de suivi de cette base de données soient incorrectes.

Par exemple, le lecteur du journal a validé avec succès une transaction (appelons-la T1) dans la base de données de distribution, et sp_repldone a été appelée pour mettre à jour les données de suivi de la base de données du serveur de publication pour mémoriser l'envoi de T1 et que la transaction T2 doit ensuite être analysée. L'Agent de lecture du journal passe alors à la transaction T2. Admettons que le serveur de publication soit arrêté immédiatement après la validation de la transaction T2 par l'Agent de lecture du journal dans la base de données de distribution, mais avant que sp_repldone ne soit appelé pour mettre à jour les informations de suivi de la base de données du serveur de publication. Lors du retour du serveur de publication, les données de suivi indiquent que la transaction T1 a été envoyée et que la transaction T2 doit être analysée ensuite. Cependant, cela ne correspond pas au fait que T2 ait déjà été validée dans la base de données de distribution. L'Agent de lecture du journal gère cette situation en interne. Lors du démarrage suivant de l'Agent de lecture du journal, il interroge la base de données de distribution afin d'obtenir le numéro de séquence de la dernière transaction distribuée (LSN). Ensuite, il appelle sp_repldone pour réinitialiser les données de suivi de la base de données du serveur de publication, pour que l'ensemble des commandes et des transactions fournies ne soit pas renvoyé.

Cette erreur peut être émise si le numéro de séquence de la transaction extrait par l'Agent de lecture du journal de la base de données de distribution est plus petit que celui de la dernière transaction fournie, comme indiqué par ses données de suivi. Cette condition signifie qu'il manque dans la base de données de distribution des commandes et des transactions envoyées par l'Agent de lecture du journal. Par exemple, si sync with backup n'a pas été activé dans la base de données de distribution, quand la base de données de distribution a été restaurée en fonction d'une version antérieure alors que l'Agent de lecture du journal avait fourni les commandes et les transactions à la base de données de distribution. Autre cause possible : l'utilisateur supprime manuellement des enregistrements de la table MSrepl_transactions de la base de données de distribution.

L'erreur peut également se produire si la réplication n'a pas été complètement supprimée ou si la base de données contenait une incohérence.

Solutions

Pour essayer de corriger ce problème, procédez comme suit :

• Utilisez DBCC CHECKDB pour vérifier la cohérence de la base de données.

• S'il n'existe pas d'autre moyen pour effacer le journal des transactions, exécutez sp_repldone et choisissez la valeur NULL pour @xactid, la valeur NULL pour @xact_seqno et la valeur 1 pour @reset, afin que toutes les transactions répliquées du journal soient marquées comme distribuées. Ceci est utile quand le journal des transactions contient des transactions répliquées qui ne sont plus valides et que vous voulez tronquer le journal. Attention : Cette procédure peut être utilisée en cas d'urgence pour permettre la troncature du journal des transactions quand des transactions en attente de réplication sont présentes. Ceci fait que des enregistrements du journal existant sont ignorés, ce qui aboutit à des incohérences entre le serveur de publication et l'abonné.

• EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1

Pour assurer la cohérence, supprimez et recréez, si possible, toutes les publications et tous les abonnements.

Paramètres remplaçables