Dans l'article précédent, Configuration et configuration de la réplication SQL Server, nous avons discuté en profondeur du concept de réplication SQL Server, de ses composants, de ses types et de la configuration étape par étape de la réplication transactionnelle SQL. Il est fortement recommandé de parcourir l'article précédent et de comprendre le concept de réplication et ses composants avant de lire cet article. Dans cet article, nous verrons comment dépanner un site de réplication SQL Server existant.
Présentation du dépannage
L'objectif principal de la réplication SQL Server est de maintenir la synchronisation des données dans l'éditeur et l'abonné. Dans le scénario heureux, si une transaction est effectuée et validée dans la base de données de publication, elle sera copiée dans la base de données de distribution, puis synchronisée et appliquée à tous les abonnés connectés à cet éditeur. Si un problème survient à n'importe quelle étape de ce processus, les modifications de l'éditeur ne seront pas disponibles du côté de l'abonné. Dans ce cas, nous devons dépanner et résoudre ce problème dès que possible avant de nous retrouver avec un site de réplication SQL expiré qui doit être à nouveau synchronisé à partir de zéro ou une base de données avec son fichier journal des transactions à court d'espace libre, interrompant toutes les transactions de base de données. .
L'identification de l'étape à laquelle la synchronisation de la réplication échoue et l'attribution d'un message d'erreur indicatif permettant de résoudre le problème constituent la partie la plus difficile du processus de dépannage de la réplication SQL Server. En outre, la vérification de l'heure de la dernière synchronisation et des modifications effectuées à / après cette heure qui peuvent provoquer cet échec peut également aider à résoudre l'échec de la synchronisation de la réplication.
Comprendre le rôle de l'agent de réplication SQL Server vous aidera à identifier à quelle étape la synchronisation échoue. N'oubliez pas qu'il existe trois agents de réplication communs à la plupart des types de réplication SQL Server. L'agent d'instantanés est responsable de la création de l'instantané de synchronisation initial. L'Agent de lecture du journal est chargé de lire les modifications à partir du fichier journal des transactions de la base de données et de le copier dans la base de données de distribution et enfin, le Distribution agent responsable de la synchronisation des modifications apportées aux abonnés.
Dans cet article, nous tirerons parti du Moniteur de réplication et moniteur d'activité professionnelle fenêtres pour surveiller l'état de la réplication SQL Server et obtenir des informations sur toute erreur d'échec de synchronisation.
Scénarios de dépannage
La meilleure et la plus simple façon de comprendre comment résoudre les problèmes de réplication SQL Server consiste à fournir des scénarios pratiques et à montrer comment résoudre ce problème particulier. Commençons à discuter des scénarios un par un.
Problème de service de l'agent SQL Server
Le service SQL Server Agent joue un rôle essentiel dans le processus de synchronisation de la réplication SQL Server. Cela est dû au fait que chaque agent de réplication s'exécutera sous un travail d'agent SQL.
En tant qu'administrateur de base de données proactif, vous devez vérifier quotidiennement l'état du site de réplication SQL. Pour vérifier l'état du site de réplication, cliquez avec le bouton droit sur la publication, sous le nœud Réplication -> Publications locales, et choisissez Lancer le moniteur de réplication option, comme indiqué ci-dessous :
Dans la fenêtre du moniteur de réplication, vous pouvez voir un message d'avertissement indiquant que la réplication va bientôt expirer ou a déjà expiré, sans voir de message d'erreur indicatif, comme ci-dessous :
Si la fenêtre du moniteur de réplication ne nous fournit aucune information utile sur la raison pour laquelle le site de réplication expire bientôt, l'étape suivante consiste à vérifier le moniteur d'activité des travaux sous le nœud SQL Server Agent. En visitant le nœud SQL Server Agent, vous verrez directement que le service SQL Server Agent n'est pas en cours d'exécution (à partir du cercle rouge à côté). Si le service SQL Server Agent n'est pas en cours d'exécution, cela signifie que tous les travaux créés sous cette instance ne fonctionnent pas, y compris les travaux de l'agent de réplication. Par conséquent, le site de réplication global ne fonctionne pas.
Pour résoudre ce problème, nous devons démarrer le service SQL Server Agent à partir de SQL Server Management Studio directement ou à l'aide du gestionnaire de configuration SQL Server (recommandé), comme indiqué ci-dessous :
Après avoir démarré le service SQL Server Agent, vérifiez à nouveau le moniteur de réplication et assurez-vous que l'état de l'abonné est En cours d'exécution et toutes les transactions en attente sont synchronisées avec succès avec l'Abonné. Vous pouvez vérifier ces étapes une par une, en vérifiant que les enregistrements sont copiés de la section Éditeur vers Distributeur :
Synchronisé ensuite du distributeur à l'abonné avec succès, comme ci-dessous :
Et enfin assurez-vous qu'il n'y a pas de transaction non distribuée du dernier onglet, comme indiqué ci-dessous :
Après cela, nous devons nous assurer que les travaux des agents de réplication sont opérationnels sans problème. Les travaux de l'agent SQL peuvent être vérifiés en développant le nœud de l'agent SQL Server sous l'explorateur d'objets SSMS et en affichant le moniteur d'activité des travaux, puis en vérifiant si l'agent de lecture du journal et l'agent de distribution sont en cours d'exécution, en tenant compte du fait que l'agent d'instantané ne fonctionnera que pendant le processus de création d'instantané, comme indiqué ci-dessous :
Vous pouvez également consulter l'historique des tâches des agents de réplication et vérifier la raison de l'échec précédent, en cliquant avec le bouton droit sur cette tâche et en choisissant Afficher l'historique comme ci-dessous :
Où vous pouvez trouver un message d'erreur indicatif qui vous aidera à résoudre ce problème à l'avenir, comme ci-dessous :
Pour résoudre le problème précédent, le mode de démarrage du service SQL Server Agent doit être modifié de Manuel à Automatique, de cette façon vous vous assurerez que le service démarrera automatiquement lorsque le serveur d'hébergement sera redémarré.
Problème d'autorisation de l'agent d'instantané
Supposons que lors de la vérification de l'état de la réplication SQL Server, à l'aide du moniteur de réplication, vous avez remarqué qu'il y a un échec de réplication, à partir du signe X à l'intérieur du cercle rouge. Et le moniteur de réplication indique que l'échec provient de l'un des agents de réplication, à partir du signe X à l'intérieur du cercle rouge en haut de l'onglet Agents.
Pour identifier cet échec de réplication, nous devons parcourir l'onglet Agents et vérifier quel agent est défaillant. À partir de la page Agents, vous verrez que l'Agent d'instantané est celui qui est défaillant. Double-cliquez sur l'Agent d'instantané et lisez le message d'erreur ci-dessous :
L'agent de réplication n'a pas enregistré de message de progression depuis 10 minutes. Cela peut indiquer un agent qui ne répond pas ou une activité système élevée. Vérifiez que les enregistrements sont répliqués vers la destination et que les connexions à l'abonné, à l'éditeur et au distributeur sont toujours actives.
Malheureusement, ce message d'erreur est générique et indique uniquement que l'Agent d'instantané ne fonctionne pas sans en préciser la raison, comme suit :
Ensuite, nous devons rechercher des informations utiles dans un autre endroit, qui est le travail Snapshot Agent. Dans la fenêtre Job Activity Monitor, sous le nœud SQL Server Agent, vous pouvez voir que le travail de l'Agent de capture instantanée a échoué. Et à partir de cet historique des travaux, vous pouvez voir qu'il a échoué récemment, en raison du problème d'authentification du proxy. En d'autres termes, les informations d'identification du compte sous lequel l'Agent de capture instantanée s'exécute ne sont pas correctes, comme indiqué ci-dessous :
Pour résoudre le problème d'informations d'identification de l'Agent d'instantané, cliquez avec le bouton droit sur la publication, sous le nœud Réplication -> Publication locale, et choisissez les Propriétés option. Dans la fenêtre Propriétés de la publication, parcourez la Sécurité de l'agent et réinsérez les informations d'identification du compte sous lequel l'Agent de capture instantanée sera exécuté.
Après avoir actualisé les informations d'identification du compte de l'Agent de capture instantanée, redémarrez la tâche de l'Agent de capture instantanée à partir de la fenêtre Moniteur d'activité des tâches et assurez-vous que la tâche fonctionne correctement, comme ci-dessous :
Vérifiez également si l'Agent d'instantané fonctionne correctement maintenant et si le message d'erreur n'apparaît plus sous le moniteur de réplication, comme indiqué ci-dessous :
Problème d'autorisation du dossier d'instantanés
Supposons que, lors de la tentative de synchronisation de l'éditeur et de l'abonné à l'aide de l'instantané initial ou de la resynchronisation du site de réplication de l'instantané à l'aide d'un nouvel instantané, le processus de création de l'instantané a échoué avec le message d'erreur d'accès ci-dessous :
Ce message d'erreur indique que le compte sous lequel l'Agent d'instantané s'exécute n'a pas l'autorisation d'accéder au dossier d'instantanés spécifié dans le message d'erreur.
Pour résoudre ce problème, nous devons vérifier le compte sous lequel l'Agent d'instantané s'exécute, à partir de la page Sécurité de l'agent de la fenêtre Propriétés de la publication, comme indiqué ci-dessous :
Ensuite, parcourez le dossier d'instantané spécifié dans le message d'erreur et assurez-vous que ce compte d'instantané dispose d'une autorisation minimale en lecture-écriture sur ce dossier, puis exécutez à nouveau l'agent d'instantané et voyez que le problème est résolu maintenant et que l'instantané de synchronisation est créé avec succès, comme ci-dessous :
Problème d'autorisation d'abonné
Supposons que, lors de la vérification de l'état du site de réplication SQL Server, à l'aide du moniteur de réplication, vous constatez qu'il y a un échec avec l'abonné, comme indiqué ci-dessous :
Si vous cliquez sur l'icône d'erreur, vous verrez que l'échec s'est produit lors de la tentative de synchronisation des transactions du Distributeur vers l'Abonné. Et d'après le message d'erreur, il est clair que le distributeur n'est pas en mesure de se connecter à l'instance SQL Server de l'abonné en raison d'un problème d'autorisation, comme indiqué ci-dessous :
Pour résoudre ce problème, nous devons vérifier et actualiser les informations d'identification utilisées pour se connecter à l'instance de l'abonné. Pour vérifier les informations d'identification, cliquez avec le bouton droit sur l'abonnement sous le nœud Réplication -> Publications locales -> le nom de la publication actuelle et choisissez l'option Propriétés. À partir de la connexion abonné sous la fenêtre Propriétés de l'abonné, actualisez les informations d'identification du compte qui sera utilisé pour se connecter à l'instance de l'abonné, comme indiqué ci-dessous :
Après cela, vérifiez à nouveau l'état de la réplication à partir du moniteur de réplication et vous verrez que le problème de connexion de l'abonné n'est plus disponible et que le site de réplication fonctionne normalement, comme indiqué ci-dessous :
Abonné non joignable
Un autre problème d'échec de la réplication SQL Server auquel vous pouvez être confronté du côté de l'abonné est que le distributeur n'est pas en mesure de se connecter à l'abonné, ce qui indique sous la page du distributeur à l'abonné qu'il n'est pas en mesure d'ouvrir une connexion avec l'abonné en raison de "Réseau Related … ” erreur de connectivité, affichée dans la fenêtre du moniteur de réplication ci-dessous :
Ce message d'erreur indique qu'il existe un problème de connexion entre l'instance du distributeur et l'instance de l'abonné. Le premier moyen simple de vérifier ce problème de connectivité consiste à s'assurer que l'instance SQL Server de l'abonné est en ligne. Cela peut être vérifié à partir du gestionnaire de configuration SQL Server du côté de l'abonné. Dans notre situation, nous pouvons voir que le service SQL Server côté abonné est arrêté. Pour résoudre ce problème, démarrez le service SQL Server et vérifiez à partir du moniteur de réplication que le site de réplication est à nouveau synchronisé, comme indiqué ci-dessous. Pour un problème de connectivité SQL plus avancé, consultez le document MS de dépannage de la connectivité :
Problème d'autorisation de la base de données d'abonnés
Supposons que vous vérifiez l'état de synchronisation de la réplication SQL Server, à l'aide du moniteur de réplication, et qu'il s'avère que la réplication échoue lors de la tentative de répliquer les modifications du distributeur à l'abonné. En cliquant sur l'erreur de l'abonné, vous verrez que le Le distributeur est en mesure d'atteindre l'abonné et de s'y connecter, mais pas en mesure de se connecter à la base de données d'abonnement en raison d'un problème d'absence d'autorisation, comme indiqué ci-dessous :
Pour résoudre ce problème, connectez-vous à l'Abonné et assurez-vous que le compte utilisé pour se connecter à la base de données de l'Abonné est membre du rôle fixe de base de données db_Owner, comme indiqué ci-dessous :
Après cela, vérifiez à nouveau le moniteur de réplication et assurez-vous que le distributeur est en mesure d'accéder à la base de données d'abonnement et de répliquer les modifications, comme ci-dessous :
Problème de différence de données
Supposons que l'une des équipes de développement de la base de données affirme que certaines modifications apportées à la table Shifts sur l'éditeur (SQL1) ne sont pas reflétées dans les rapports quotidiens exécutés sur l'instance de l'abonné (SQL2), et il a fourni l'instantané ci-dessous qui montre que les modifications ne sont pas répliquées :
La première étape de la vérification du problème de synchronisation de la réplication consiste à ouvrir le moniteur de réplication et à trouver à quelle étape il échoue. Dans le moniteur de réplication, vous pouvez voir que l'agent de lecture du journal échoue, car les modifications ne sont pas répliquées du distributeur vers l'abonné, mais aucun message clair n'est renvoyé par cet agent, comme indiqué ci-dessous :
Comme nous ne pouvons pas trouver de message d'erreur significatif du moniteur de réplication, nous allons vérifier l'historique du travail de l'agent de lecture du journal, à l'aide du moniteur d'activité du travail, qui montre que les informations d'identification du compte sous lequel l'agent de lecture du journal s'exécute sont incorrectes. , comme indiqué ci-dessous :
Pour résoudre le problème d'informations d'identification de l'Agent de lecture du journal, parcourez la page Sécurité de l'agent de la fenêtre Propriétés de la publication et actualisez les informations d'identification de l'Agent de lecture du journal avec une valeur valide, comme ci-dessous :
En vérifiant à nouveau le moniteur de réplication, vous verrez que les modifications sont répliquées avec succès et que les données sont mises à jour avec les nouvelles modifications d'équipes, comme indiqué ci-dessous :
Ligne introuvable chez l'abonné
Regardons la question d'un autre côté. Supposons qu'un changement soit effectué dans le tableau des équipes, comme indiqué ci-dessous :
Mais cette modification n'est pas répliquée sur l'Abonné et le site de réplication SQL Server global échoue. À partir du moniteur de réplication, vous pouvez voir qu'il échoue lors de la tentative de modification du distributeur à l'abonné, et qu'il a échoué en raison du fait qu'il n'est pas en mesure de mettre à jour cet enregistrement spécifique avec un ID égal à 3, car cet enregistrement n'est pas disponible dans la table de la base de données des abonnés, comme indiqué ci-dessous :
En vérifiant cet enregistrement côté abonné (SQL2), vous verrez que l'enregistrement n'est pas disponible, comme ci-dessous :
Pour résoudre ce problème, nous devons insérer à nouveau cet enregistrement dans la table de la base de données des abonnés et laisser le distributeur essayer de le mettre à jour à nouveau, en résolvant le problème d'échec de la synchronisation de la réplication, comme indiqué ci-dessous :
SQL Server nous offre une option pour laisser le site de réplication continuer à fonctionner même si un problème d'incohérence des données est détecté, où vous pouvez résoudre manuellement ce problème d'incohérence plus tard. Pour ce faire, à partir du moniteur de réplication, cliquez avec le bouton droit sur l'abonné et choisissez Profil de l'agent option, comme indiqué ci-dessous :
À partir de la fenêtre affichée, vous pouvez mettre à jour le profil de l'agent de lecture du journal et lui permettre de continuer à répliquer les modifications de données en cas de problème d'incohérence des données, comme indiqué ci-dessous :
Problème d'abonnement non initialisé
Si le site de réplication est laissé sans surveillance pendant une longue période et qu'une panne s'est produite sans aucun correctif pendant plus de trois jours, le site de réplication expirera et l'abonnement sera marqué comme non initialisé, en attente d'être réinitialisé à nouveau à l'aide d'un nouvel instantané. . Le même scénario peut être rencontré lors de la création d'un nouvel abonnement sans l'initialiser, comme indiqué ci-dessous :
Pour résoudre ce problème, nous devons réinitialiser cet abonnement en cliquant avec le bouton droit sur l'abonnement sous le nœud Réplication -> Publications locales et développer la publication, puis choisir l'option Réinitialiser et marquer cet abonnement pour initialisation et le préparer à recevoir un nouveau instantané, comme illustré ci-dessous :
Si l'état de l'abonnement reste Non initialisé après sa réinitialisation, vérifiez le travail de l'Agent d'instantané à l'aide de la fenêtre Moniteur d'activité des travaux et voyez pourquoi il échoue. Dans l'historique des tâches de l'Agent d'instantané, vous verrez que la tâche a échoué en raison d'un problème de détermination du propriétaire de cette tâche d'agent, comme indiqué ci-dessous :
Pour résoudre ce problème, ouvrez la tâche de l'Agent d'instantané et modifiez le propriétaire de la tâche en SA ou tout autre utilisateur administrateur valide, et la tâche s'exécutera avec succès, comme ci-dessous :
Vous verrez maintenant que l'état de l'abonnement est passé à En cours d'exécution, ce qui signifie qu'il attend l'instantané initial pour démarrer le processus de synchronisation, comme indiqué ci-dessous :
Pour générer un nouvel instantané, cliquez avec le bouton droit sur la publication, sous le nœud Réplication-> Publications locales, et sélectionnez Afficher l'état de l'agent d'instantané option.
Dans la fenêtre ouverte, cliquez sur le bouton Démarrer pour démarrer le processus de création d'instantané. Lorsque l'instantané contenant tous les articles de l'éditeur a été créé avec succès, ouvrez à nouveau le moniteur de réplication et vérifiez l'état de l'abonnement, où vous verrez que l'instantané est appliqué à l'abonné et synchronisé avec l'éditeur, comme indiqué ci-dessous :
Problème de propriétaire de la base de données de l'éditeur
Supposons également que, lors de la vérification de l'état du site de réplication SQL Server, à l'aide du moniteur de réplication, le site de réplication a échoué et que l'échec a été détecté au niveau de l'agent de lecture du journal. En vérifiant le message d'erreur renvoyé par cet agent, il s'avère qu'il existe un problème pour déterminer le propriétaire actuel de la base de données de publication, comme indiqué ci-dessous :
Pour résoudre ce problème, nous devons mettre à jour le propriétaire actuel de la base de données de publication, en le remplaçant par un utilisateur de base de données valide, en utilisant le SP_changedbowner procédure stockée du système, ou simplement à partir de la fenêtre des propriétés de la base de données. Après cela, exécutez à nouveau le travail de l'agent de lecture du journal, à l'aide de la fenêtre Moniteur d'activité du travail, puis validez si le problème de l'agent n'est plus disponible, à l'aide du moniteur de réplication, comme indiqué ci-dessous :
Conclusion
Dans cet article, nous avons présenté différents problèmes auxquels vous pouvez être confronté lors de l'utilisation de la fonctionnalité de réplication SQL Server pour copier des données entre différents sites, et comment résoudre ces problèmes.
Il est fortement recommandé de maintenir le moteur SQL Server à jour, avec les derniers SP et CU, afin que tous les bogues liés aux fonctionnalités de réplication SQL Server soient corrigés automatiquement. Enfin, en tant qu'administrateur de base de données SQL Server proactif, gardez un œil sur votre site de réplication pour résoudre tout problème dès le début avant qu'il ne devienne plus important et plus difficile à résoudre.
