Résoudre les problèmes liés au service de réplication de base de données dans Configuration Manager

Ce guide aide les administrateurs à diagnostiquer et résoudre les problèmes de service de réplication de base de données (DRS) dans le gestionnaire de configuration.

Version du produit d’origine :   Microsoft Endpoint Configuration Manager (branche actuelle), Microsoft System Center 2012 R2 Configuration Manager, gestionnaire de configuration Microsoft System Center 2012
Numéro de la base de connaissances initiale :   20033

Lorsque vous observez un problème DRS dans le gestionnaire de configuration, la phase d’enquête de début est le point le plus critique. Tout type de modification ou de correctif doit être effectué uniquement après avoir soigneusement étudié et compris le problème.

Prise en main

Commencez par collecter des informations relatives à l’historique du problème. De nombreux problèmes de DRS peuvent finalement être suivis jusqu’à une modification récente effectuée dans l’environnement. N’oubliez pas que vous ne devez pas vous concentrer uniquement sur le gestionnaire de configuration, car les modifications apportées à Windows ou à SQL Server peuvent également entraîner des problèmes DRS. Une bonne compréhension de toutes les modifications récentes de l’environnement peut donner des indications importantes sur la source du problème.

Une fois que vous avez analysé les modifications environnementales et vérifié que vos mises à jour sont dans l’ordre, l’étape suivante consiste à exécuter l’analyseur de liaisons de réplication (RLA). Pour lancer RLA, ouvrez l’espace de travail analyse et sélectionnez le nœud réplication de base de données , puis cliquez avec le bouton droit sur le lien qui rencontre un problème et sélectionnez Analyseur de liens de réplication, comme illustré dans l’exemple suivant :

Capture d’écran de l’analyseur de liens de réplication.

Notes

RLA s’exécute dans le cadre de son lancement à partir de la console, assurez-vous que le compte que vous utilisez dispose de privilèges d’administrateur sur SQL Server et les serveurs de site.

RLA vérifie les éléments suivants sur les deux sites :

  • Le service SMS est en cours d’exécution.
  • Le composant moniteur de configuration de la réplication SMS est en cours d’exécution.
  • Les ports requis pour la réplication SQL Server sont activés.
  • La version de SQL Server est prise en charge.
  • Le réseau est disponible entre les deux sites.
  • Il y a suffisamment d’espace pour la base de données SQL Server.
  • La configuration du Service Broker SQL Server existe.
  • Le certificat du service de service Broker SQL Server existe.
  • Erreurs connues dans les fichiers journaux SQL Server.
  • Indique si les files d’attente de réplication sont désactivées.
  • L’heure est synchronisée.
  • La transmission de données est-elle bloquée ?
  • Existe-t-il un conflit de clés ?

Si RLS détecte des problèmes connus, il vous propose de les corriger. Le rapport de sortie RLA est également simple. Elle vous indique ce qu’elle a vérifié et les règles qui ont été exécutées en plus de savoir si elles ont réussi ou échoué. Voici un exemple :

Capture d’écran de l’exemple de rapport de sortie RLA

Obtenir des détails avec SPDiagDRS

Si l’analyseur de liaisons de réplication ne peut pas détecter et résoudre le problème, exécutez le SPDiagDRS pour voir s’il peut vous donner des indications sur ce qui peut être à l’échec.

Pour exécuter SPDiagDRS , ouvrez SQL Server Management Studio et connectez-vous aux deux serveurs de chaque côté du lien présentant le problème. Sur chaque base de données CM_xxx , exécutez la Exec SPDiagDRS commande.

Voici une répartition des différentes SPDiagDRS sections, ainsi que des emplacements communs pour rechercher des problèmes. Une recherche simple de messages d’erreur et de codes trouvés ici vous guide souvent vers la source du problème.

Capture d’écran d’une répartition des différentes sections SPDiagDRS

Section 1

  • SiteStatus: indique si le site est répliqué ou non. Tout élément autre qu' actif n’est pas correct.

  • CertificateThumbprint: empreinte du certificat utilisé pour l’authentification, qui contient la clé publique du site (base de données de base de données distante locale approuvé).

Capture d’écran des champs SiteStatus et CertificateThumbprint

Section 2

  • IncomingMessageInQueue: indique le backlog entrant d’un site. Si le retard est élevé en raison du nombre de sites dans lesquels il a été signalé, il se peut que les liens vers un État détérioré ou échec soient signalés car les synchronisations de pulsations ne sont pas traitées dans le temps.

  • OutgoingMessageInQueue: indique la file d’attente qui n’a pas encore été clairement précisée lorsque nous patientons jusqu’à ce que les sites reçoivent les messages. Cela fluctue, toutefois, si elle continue de croître, cela peut représenter un problème. Un autre dépannage doit être effectué pour déterminer quel site ne reçoit pas les messages.

Capture d’écran des champs IncomingMessageInQueue et OutgoingMessageInQueue

Section 3

Il s’agit simplement de l’affichage détaillé des Détails d’initialisation dans la console.

Capture d’écran des détails d’initialisation.

Section 4

Il s’agit de l’affichage détaillé des détails de la réplication   dans la console. Elle fournit davantage d’informations sur le flux entre chaque groupe de réplication.

Capture d’écran des détails de la réplication.

Section 5

Cette section contient des informations importantes et utiles sur les sites auxquels nous nous connectons. Dans cet exemple, nous sommes sur le serveur de site principal 002 et 001 est le site Administration centrale. Si nous avions un site secondaire sous 002, il serait indiqué ici. Sur un site d’administration centrale, tous les sites principaux seraient reflétés, mais pas les sites secondaires.

Site principal 002-exemple :

Capture d’écran du site principal 002-exemple

Site Administration centrale 001 exemple :

Capture d’écran de l’exemple de site Administration centrale

Section 6

Cela fournit des informations générales sur les sites de la hiérarchie, les  SiteServerName    DBServer   noms et, ainsi que l’État et la version. Vous pouvez voir ici qu’un autre site principal (003) apparaît en mode maintenance. Sur les systèmes de travail, la section 6 doit être identique entre le site Administration centrale et tous les sites principaux de la hiérarchie.

Capture d’écran d’un site principal en mode maintenance

Section 7

Les deux dernières sections contiennent des informations détaillées sur la pulsation ou LastSentStatus pour chaque groupe conversationIDs , et ainsi de suite, ainsi que sur les options de réplication intégrées configurées pour chaque groupe.

Vérifier RCMCtrl. log pour les erreurs

Ensuite, vous devez vérifier RCMCtrl. log sur chaque site pour en savoir plus sur les erreurs, car cela vous fournira souvent des indices précieux concernant la source du problème. Par exemple, vous pouvez constater que la réplication est en état d' échec pour un site et que la réplication n’a pas été effectuée pendant un certain temps. Dans ce scénario, vous pouvez constater que RCMCtrl. log contient des entrées semblables à ce qui suit :

7/4/2016 1:25:36 PM : ReplicationLinkAnalysis informations : 1 : fin du thread d’analyse de lien de réplication.
7/4/2016 1:25:37 PM : erreur ReplicationLinkAnalysis : 1 : CodeSite ou SiteNumber
7/4/2016 1:25:37 PM : erreur ReplicationLinkAnalysis : 1 : Microsoft.ConfigurationManager. ManagedBase. LocalServerDataNotFoundException : CodeSite ou SiteNumber
au Microsoft.ConfigurationManager. ManagedBase. SiteData. Refresh ()
at Microsoft.ConfigurationManager.ReplicationLinkAnalyzer.ReplicationLinkAnalysisEngine.Initialize ()
at Microsoft.ConfigurationManager. ReplicationLinkAnalyzer. ReplicationLinkAnalysisEngine. RunRulesInBackground (Object sender, DoWorkEventArgs e)
sur System. ComponentModel. BackgroundWorker. WorkerThreadStart (argument objet)

Si vous voyez des entrées semblables à celles-ci, assurez-vous que les services SMS Executive et Gestionnaire de composants de site sont en cours d’exécution sur le site en question. Si ce n’est pas le cas, il peut s’agir de l' échec de la réplication. Si elle n’est pas en cours d’exécution, démarrez manuellement les services SMS Executive et/ou Gestionnaire de composants de site et dépannez les services s’ils ne parviennent pas à démarrer.

Un autre exemple d’erreur que vous pouvez trouver dans RCMCtrl. log est le suivant :

07/04/2016 12:33:34 PM 6352 (0x18D0) CSqlBCP :: ReadRowCount : impossible d’ouvrir le fichier [F:\Program Files\Microsoft Configuration Manager\inboxes\rcm.box\GUID\ INSTALLED_EXECUTABLE_DATA. bcp. RowCount]. SMS_REPLICATION_CONFIGURATION_MONITOR
07/04/2016 12:33:34 PM 6352 (0x18D0) CSqlBCP ::D RS_Init_BCPIN : ReadRowCount a échoué. SMS_REPLICATION_CONFIGURATION_MONITOR
07/04/2016 12:33:34 PM 6352 (0x18D0) * * * DRS_Init_BCPIN () a échoué SMS_REPLICATION_CONFIGURATION_MONITOR
07/04/2016 12:33:34 PM 6352 (0x18D0) CBulkInsert ::D RS_Init_BCPIN : échec de l’BCP dans SMS_REPLICATION_CONFIGURATION_MONITOR
07/04/2016 12:33:34 PM 6352 (0x18D0) BCP in result est 2147500037. SMS_REPLICATION_CONFIGURATION_MONITOR
07/04/2016 12:33:34 PM 6352 (0x18D0) erreur : échec de l’BCP dans le INSTALLED_EXECUTABLE_DATA de tableau avec le code d’erreur 2147500037. SMS_REPLICATION_CONFIGURATION_MONITOR
07/04/2016 12:33:34 PM 6352 (0x18D0) erreur : échec de l’application de BCP pour tous les Articles de la publication Hardware_Inventory_7. SMS_REPLICATION_CONFIGURATION_MONITOR
07/04/2016 12:33:34 PM 6352 (0x18D0) essaiera de nouveau d’appliquer les fichiers BCP lors de la prochaine exécution.

Voici ce qui se passe ici : Le fichier CAB envoyé depuis le parent a été décompressé par le désspouleur, l’espace sur le lecteur étant épuisé, de sorte qu’il ne puisse décompresser qu’un certain nombre de fichiers. Si vous affichez la mise en file d’attente. log, il y aura une erreur 2147024784 qui se rapporte à un espace disque insuffisant. Pour résoudre ce type de problème, libérez de l’espace disque sur le lecteur.

Vérifier les problèmes BCP

Si vous n’avez toujours pas trouvé la source du problème, il se peut que le processus de réplication ait été interrompu car le programme de copie en bloc (BCP) était trop lent.

L’expéditeur est-il limité à ce site et peut-être le ralentissement du transfert BCP ?

Pour vérifier, ouvrez la console et accédez à > vue d’ensemblede la configuration de la hiérarchie du fichier de > configuration de hiérarchie > File Replication, puis cliquez avec le bouton droit sur le site qui doit envoyer les données. Vérifiez que la disponibilité de la planification est définie sur ouverte pour toutes les prioritéset que les limites de taux sont définies sur illimitée pour ce site.

Vérifier le site dans la réplication de fichiers

Si les éléments fonctionnent mais que le jeu de données du processus BCP est volumineux et que leur envoi prend beaucoup de temps, vous pouvez augmenter le nombre de threads d’expéditeurs pour accélérer le processus. Les paramètres par défaut sont répertoriés ci-dessous. Si votre journal des expéditeurs ne conseille toujours pas plus de threads disponibles , ni l’utilisation de 5 ou 5 ou l’utilisation de 3 sur 3, il s’agit d’une excellente indication que vous souhaiterez peut-être augmenter les threads de l’expéditeur.

Notes

Si elle augmente, le paramètre prend effet en temps réel sans aucun redémarrage.

Augmenter le nombre de threads d’expéditeurs

De même, si vous avez une limite de débit définie sur limité à des taux de transfert maximaux spécifiés par heure (comme indiqué ci-dessous), le gestionnaire de configuration n’utilise qu’un seul thread d’expéditeur à la fois lors du transfert vers ce site, quel que soit le nombre de threads d’expéditeur défini sur. Le paramètre par défaut, illimité lors de l’envoi vers cette destination , utilisera tous les threads des expéditeurs configurés.

Capture d’écran du paramètre de limite de débit

Plus d’informations

Pour plus d’informations sur DRS, consultez les articles suivants :

Vous pouvez également publier une question sur notre Forumde support du gestionnaire de configuration.