Liste de contrôle : Maintenance et résolution des problèmes des bases de données BizTalk Server

BizTalk Server bases de données et leur intégrité sont très importants pour un environnement de messagerie de base de données BizTalk Server réussi. Cette rubrique répertorie les étapes que vous devez suivre lors de la maintenance ou de la résolution des problèmes liés aux bases de données BizTalk Server.

• Maintenance des bases de données BizTalk Server

• Résolution des problèmes BizTalk Server bases de données

Maintenance des bases de données BizTalk Server

• Désactivez les options Mettre à jour automatiquement les statistiques et Créer automatiquement des statistiques (s’applique uniquement aux bases de données MessageBox BizTalk Server). Par défaut, ces paramètres sont configurés dans le cadre de la configuration BizTalk Server. Vous ne devez pas apporter de modifications à ces paramètres.

  Pour voir si ces paramètres sont désactivés, exécutez les procédures stockées suivantes dans SQL Server :

  SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoCreateStatistics') AS IsAutoCreateStatistics
  SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoUpdateStatistics') AS IsAutoUpdateStatistics
  

  Les valeurs retournées doivent être 0 pour indiquer que le paramètre est désactivé. Si la valeur 0 n’est pas retournée, désactivez le paramètre en exécutant la commande suivante dans SQL Server :

  ALTER DATABASE BizTalkMsgBoxDB SET AUTO_CREATE_STATISTICS OFF
  ALTER DATABASE BizTalkMsgBoxDB SET AUTO_UPDATE_STATISTICS OFF
  

  Pour plus d’informations sur ces paramètres, accédez à Vous rencontrez des problèmes de blocage, d’interblocage ou d’autres problèmes de SQL Server lorsque vous essayez de vous connecter à la base de données BizTalkMsgBoxDb dans BizTalk Server.

• Définissez la propriété Degré maximal de parallélisme. Par défaut, ces paramètres sont configurés dans le cadre de la configuration BizTalk Server. Vous ne devez pas apporter de modifications à ces paramètres.

  Définissez les propriétés Max Degree of Parallelism run_value et config_value sur une valeur (1) sur les instances SQL Server qui hébergent les bases de données MessageBox BizTalk Server. Pour case activée le paramètre Degré maximal de parallélisme, exécutez la procédure stockée suivante sur la base de données Master dans SQL Server :

  exec sp_configure 'max degree of parallelism'
  

  Si les run_value et les config_value ne sont pas définis sur une valeur de une (1), exécutez la procédure stockée suivante dans SQL Server :

  exec sp_configure 'max degree of parallelism', '1' reconfigure with override
  

  Pour plus d’informations sur la façon dont le paramètre Degré maximal de parallélisme affecte BizTalk Server, accédez à Vous rencontrez des problèmes de blocage, d’interblocage ou d’autres problèmes de SQL Server lorsque vous essayez de vous connecter à la base de données BizTalkMsgBoxDb dans BizTalk Server.

• Déterminez quand vous pouvez reconstruire BizTalk Server index.

  La plupart des index dans BizTalk Server bases de données sont en cluster (ID d’index : 1). La commande DBCC SHOWCONTIG peut être utilisée pour afficher des informations de fragmentation pour les tables dans les bases de données BizTalk Server. Ces index sont basés sur un GUID. Il est donc normal que la fragmentation se produise. Si la valeur de densité d’analyse de DBCC SHOWCONTIG est inférieure à 30 %, les index peuvent être reconstruits pendant les temps d’arrêt. De nombreuses tables des bases de données BizTalk Server contiennent des colonnes qui utilisent des définitions DataType où l’indexation en ligne ne peut pas être effectuée. Par conséquent, les index des tables dans les bases de données BizTalk Server ne doivent jamais être reconstruits pendant que BizTalk traite les données.

  Pour plus d’informations sur la façon de reconstruire les index BizTalk, consultez Vous rencontrez des problèmes de blocage, d’interblocage ou d’autres problèmes de SQL Server lorsque vous essayez de vous connecter à la base de données BizTalkMsgBoxDb dans BizTalk Server.

  Vous pouvez également utiliser la fonction sys.dm_db_index_physical_stats pour rechercher des informations de fragmentation dans SQL Server. Pour plus d’informations, consultez sys.dm_db_index_physical_stats (Transact-SQL).

• Surveillez la base de données à la recherche de verrous, de blocs ou d’interblocages.

  Il s’agit d’un comportement attendu pour les verrous et les blocs sur les bases de données SQL Server utilisées par BizTalk Server. Toutefois, il n’est pas prévu que ces verrous ou blocs continuent pendant une période prolongée. Le blocage et l’interblocage étendus sur les bases de données SQL Server utilisées par BizTalk Server sont des indicateurs d’un problème potentiel.

  Pour connaître les causes connues actuelles du blocage et du blocage sur les bases de données SQL Server utilisées par BizTalk Server, accédez à Vous rencontrez des problèmes de blocage, d’interblocage ou d’autres problèmes de SQL Server lorsque vous essayez de vous connecter à la base de données BizTalkMsgBoxDb dans BizTalk Server.

• Surveillez la taille des bases de données et des tables.

  La taille de la base de données MessageBox BizTalk Server ne doit généralement pas dépasser 5 Go environ. La base de données BizTalkMsgBoxDb ne doit contenir aucune donnée et doit être considérée comme une mémoire tampon jusqu’à ce que les données soient traitées ou déplacées vers la base de données BizTalkDTADb. Un environnement avec un back-end de SQL Server puissant et de nombreuses orchestrations de longue durée peut avoir une base de données BizTalkMsgBoxDb supérieure à 5 Go. Un environnement à volume élevé sans orchestrations de longue durée doit avoir une base de données MessageBox BizTalk Server bien inférieure à 5 Go.

  La taille de la base de données de suivi BizTalk Server peut varier considérablement, mais si les performances des requêtes diminuent considérablement, la base de données de suivi est probablement trop volumineuse. En règle générale, une base de données de suivi BizTalk Server supérieure à 15 à 20 Go est considérée comme trop volumineuse et peut avoir un impact négatif sur les performances.

  Les problèmes suivants peuvent être attribuables à des bases de données BizTalk Server trop volumineuses :

  • La base de données MessageBox BizTalk Server continue de croître tandis que la taille des données (pas seulement le fichier journal) reste importante. BizTalk Server prend plus de temps que d’habitude pour traiter même un scénario de flux de messages simple.
  • Les requêtes hub de groupe prennent plus de temps que d’habitude et peuvent même expirer.
  • Le fichier journal de la base de données n’est jamais tronqué.
  • Les travaux de l’Agent SQL BizTalk s’exécutent plus lentement que d’habitude.
  • Certaines tables sont considérablement volumineuses ou ont trop de lignes par rapport à la normale.

  Les bases de données BizTalk Server peuvent devenir volumineuses pour plusieurs raisons, notamment :

  • Travaux BizTalk SQL Agent non en cours d’exécution
  • Nombre excessif d’instances de message ou de service suspendus
  • Erreurs disque
  • Niveaux élevés de suivi
  • limitation BizTalk Server
  • Performances SQL Server médiocres
  • Problèmes de latence réseau

  De même, vous pouvez avoir trop de lignes dans une table. Il n’existe aucun nombre défini de lignes trop nombreuses. En outre, ce nombre de lignes varie selon le type de données stocké dans la table. Par exemple, une table dta_DebugTrace qui a plus d’un million de lignes a probablement trop de lignes. Une HostNameQ_Suspended table qui a plus de 200 000 lignes a probablement trop de lignes.

  Assurez-vous que vous savez ce qui est attendu dans votre environnement pour déterminer si un problème de données se produit.

• Activez le suivi sur BizTalk Server hôte.

  Par défaut, le suivi est activé sur l’hôte par défaut. BizTalk nécessite que l’option Autoriser le suivi de l’hôte soit cochée sur un seul hôte. Lorsque le suivi est activé, le service TDDS (Tracking Data Decode Service) déplace les données d’événement de suivi de la base de données MessageBox BizTalk Server vers la base de données de suivi BizTalk Server. Si aucun hôte BizTalk Server n’est configuré avec l’option Autoriser le suivi de l’hôte ou si l’hôte de suivi est arrêté, TDDS ne s’exécute pas et les tables TrackingData_x_x dans la base de données MessageBox BizTalk Server ne sont pas cochées.

  Par conséquent, un hôte BizTalk Server dédié doit être configuré avec l’option Autoriser le suivi de l’hôte. Pour plus d’informations sur la configuration d’un hôte de suivi dédié, consultez Configuration d’un hôte de suivi dédié.

  Pour permettre à TDDS de gérer de nouveaux événements de suivi dans des scénarios de volume élevé, vous pouvez créer plusieurs instances d’un hôte de suivi unique, mais pas plus d’un hôte ne doit être configuré pour le suivi.

• Utilisez les travaux de SQL Server Agent BizTalk appropriés.

  L’exécution des travaux BizTalk Server SQL Agent est essentielle pour gérer les bases de données BizTalk Server et maintenir des performances optimales.

  • Le travail SQL Server Agent BizTalk Server de sauvegarde est la seule méthode prise en charge pour sauvegarder les bases de données BizTalk Server. Ce travail vous oblige à configurer toutes les bases de données BizTalk Server pour utiliser un modèle de récupération complète. Vous devez configurer ce travail pour un environnement BizTalk Server sain. Vous pouvez utiliser les méthodes SQL Server pour sauvegarder les bases de données BizTalk Server uniquement si le service SQL Server est arrêté et si tous les processus BizTalk Server sont arrêtés.

    Pour plus d’informations sur l’utilisation du modèle de récupération complète SQL Server lors de la configuration du travail de sauvegarde sql Agent BizTalk Server, consultez Copie des journaux de transaction ou Sauvegarde sous le modèle de récupération complète.

  • Le travail SQL Server Agent MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb est conçu pour s’exécuter indéfiniment. Par conséquent, l’historique des travaux de SQL Agent peut ne pas indiquer que ce travail SQL Agent s’est terminé avec succès ; ce comportement est par conception. En cas d’échec, le travail redémarre dans un délai de 1 minute et continue de s’exécuter sans relâche. Par conséquent, les notifications d’échec pour ce travail peuvent généralement être ignorées.

    Si l’historique des travaux pour le travail MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent indique que ce travail échoue et redémarre constamment, il peut être nécessaire d’examiner plus en détail la cause du cycle d’échec/redémarrage.

  • Le MessageBox_Message_Cleanup_BizTalkMsgBoxDb travail SQL Server Agent est le seul travail qui ne doit pas être activé manuellement, car il est lancé par le travail MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb.

  • Le travail de vidage et d’archivage SQL Server Agent DTA gère la base de données de suivi BizTalk Server en vidant et en archivant les messages suivis. Ce travail lit chaque ligne du tableau et compare l’horodatage de chaque ligne pour déterminer si l’enregistrement doit être supprimé.

    Lors de la résolution des problèmes des travaux BizTalk Server SQL Server Agent, vérifiez que tous les travaux de l’Agent SQL, à l’exception de la MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb, se terminent sans erreurs.

  Pour plus d’informations sur les travaux BizTalk Server SQL Agent utilisés dans SQL Server :

  • Structure et travaux de base de données
  • Description des travaux de l’Agent SQL Server dans BizTalk Server

• Surveillez et arrêtez les instances suspendues.

  Les instances de service peuvent être suspendues (pouvant être reprises) ou suspendues (non reprises). Ces instances de service peuvent être messagerie, orchestration ou port. BizTalk Server prend en charge l’arrêt et la suppression de ces instances à l’aide de la page Hub de groupe dans la console d’administration BizTalk Server ou à l’aide du script Terminate.vbs. Pour plus d’informations sur le script Terminate.vbs, consultez Suppression de l’instance de service suspendue.

  Vous pouvez également utiliser l’outil Terminator pour supprimer les instances suspendues. L’outil Terminator est inclus dans le BizTalk Health Monitor.

  Les termes « orphelins » et « zombies » sont souvent utilisés de manière interchangeable. Un message orphelin ou zombie est un message qui n’a pas de instance de service associé, généralement parce que le service instance s’est arrêté avant la réception du message. Un service orphelin ou zombie est un service qui n’a aucun message associé. Pour plus d’informations sur les messages zombies et les instances de service dans BizTalk Server consultez Zombies dans BizTalk Server.

• Surveillez les compteurs de performances de l’objet de performance PhysicalDisk .

  BizTalk Server effectue un grand nombre de transactions courtes et très rapides pour SQL Server en moins d’une minute. Si le SQL Server ne peut pas soutenir cette activité, vous pouvez rencontrer des problèmes de performances BizTalk Server. Surveillez les compteurs de performances Avg. Disk sec/Read, Avg. Disk sec/Transfer et Avg. Disk sec/Write dans l’objet de performance PhysicalDisk . La valeur optimale est inférieure à 10 ms (millisecondes). Une valeur de 20 ms ou plus est considérée comme des performances médiocres.

  Pour plus d’informations sur la haute disponibilité de BizTalk Server base de données, consultez Fournir une haute disponibilité pour les bases de données BizTalk Server.

• Suivez les meilleures pratiques pour les bases de données BizTalk Server. Consultez Meilleures pratiques pour la gestion des bases de données BizTalk Server.

Résolution des problèmes BizTalk Server bases de données

Effectuez les tâches suivantes pour résoudre les problèmes liés aux bases de données BizTalk Server.

• Vérifiez que tous les travaux bizTalk SQL Server Agent requis sont activés et en cours d’exécution.

  Tous les travaux bizTalk SQL Server Agent, à l’exception du travail MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb, doivent être activés et exécutés correctement. Ne désactivez pas d’autres travaux.
  
  En cas d’échec, utilisez l’option Afficher l’historique dans SQL Server pour afficher les informations d’erreur, puis résoudre l’échec en conséquence. N’oubliez pas que la tâche MessageBox _Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent s’exécute à l’infini. Par conséquent, vous ne devez être concerné que si l’historique des travaux indique que le travail échoue constamment et redémarre.

• Utilisez l’outil MsgBoxViewer pour analyser bizTalk MessageBox et d’autres bases de données.

  L’outil MsgBoxViewer est inclus dans le BizTalk Health Monitor. L’outil MsgBoxViewer est utile pour résoudre les problèmes, car il fournit un rapport HTML qui contient des informations détaillées sur les tailles de table et le nombre de lignes. Le rapport peut également aider à déterminer si BizTalk Server est en cours de limitation. En outre, l’outil fournit une instantané des bases de données BizTalk Server et de la configuration BizTalk Server.

  Quand BizTalk Server s’exécute plus lentement que d’habitude, exécutez l’outil MsgBoxViewer, cliquez pour sélectionner toutes les requêtes sous l’onglet Requêtes facultatives, puis passez en revue le rapport HTML généré pour tout problème. La section Rapport récapitulatif répertorie les avertissements en jaune et les problèmes potentiels en rouge.

  En outre, vous pouvez utiliser l’outil MsgBoxViewer pour déterminer quelles tables sont les plus grandes et ont le plus d’enregistrements. Pour obtenir la liste des tables qui augmentent généralement les grandes quantités et pour obtenir des instructions sur la gestion de ces tables, consultez Tables de base de données BizTalk Server volumineuses.

• Utilisez l’outil Terminator pour résoudre les problèmes, le cas échéant, identifiés par l’outil MsgBoxViewer.

  L’outil Terminator est inclus dans le BizTalk Health Monitor. Cet outil permet aux utilisateurs de résoudre facilement tous les problèmes identifiés par l’outil BizTalk MsgBoxViewer.

• Examinez les scénarios d’interblocage.

  Dans un scénario d’interblocage, activez le suivi DBCC sur le SQL Server afin que les informations d’interblocage soient écrites dans le journal SQLERROR. Dans SQL Server, exécutez l’instruction suivante pour activer le suivi DBCC pour les scénarios d’interblocage :

  DBCC TRACEON (1222,-1)
  

  Vous pouvez également utiliser l’utilitaire PSSDIAG pour collecter des données sur l’événement Lock :Deadlock et l’événement Lock :Deadlock Chain . Pour plus d’informations, consultez Utilitaire de collecte de données PSSDIAG.

  La base de données BizTalkMsgBoxDB est une base de données OLTP (Traitement des transactions en ligne) à volume élevé et à transaction élevée. Avec ces bases de données, un certain blocage est attendu et ce blocage est géré en interne par le moteur de BizTalk Server. Lorsque ce comportement se produit, aucune erreur n’est répertoriée dans les journaux d’erreurs. Lorsque vous examinez un scénario d’interblocage, l’interblocage que vous examinez dans la sortie doit être corrélé avec une erreur d’interblocage dans les journaux des événements.

• Recherchez les processus bloqués.

  Vous pouvez utiliser le moniteur d’activité dans SQL Server pour obtenir l’identificateur de processus serveur (SPID) d’un processus système de verrouillage. Vous pouvez ensuite exécuter SQL Profiler pour déterminer l’instruction SQL qui s’exécute dans le SPID de verrouillage. Vous pouvez utiliser l’utilitaire PSSDIAG pour résoudre les problèmes de verrouillage et de blocage dans SQL Server. L’utilitaire capture tous les événements Transact-SQL dont le script de blocage est activé. Pour plus d’informations, consultez Utilitaire de collecte de données PSSDIAG

  Dans SQL Server, vous pouvez spécifier le paramètre de seuil de processus bloqué pour déterminer quels SPID ou SPID bloquent plus longtemps que le seuil que vous spécifiez. Pour plus d’informations sur l’option de seuil de processus bloqué, consultez Option de seuil de processus bloqué.

  Lorsque vous rencontrez un problème de verrouillage ou de blocage dans SQL Server, vous pouvez contacter les services de support technique Microsoft.

• Supprimez toutes les données indésirables.

  Si les bases de données sont devenues trop volumineuses et si les données contenues dans les bases de données ne sont plus nécessaires, la méthode recommandée consiste à supprimer les données. Attention: N’utilisez pas cette méthode dans un environnement où les données sont critiques pour l’entreprise ou si les données sont nécessaires.

  Pour vider la base de données BizTalkMsgBox :

  1. Téléchargez et installez l’outil Terminator, qui est inclus dans le BizTalk Health Monitor.

  2. Suivez les étapes de la rubrique Comment vider manuellement les données de la base de données MessageBox dans un environnement de test pour créer la procédure stockée bts_CleanupMsgbox dans la base de données BizTalk MessageBox.

  3. Utilisez l’outil Terminator pour exécuter la procédure stockée bts_CleanupMsgbox et vider la base de données BizTalk MessageBox.

     La procédure stockée bts_CleanupMsgbox supprime les données. Soyez prudent lors de l’exécution de cette procédure stockée dans un environnement de production.

  4. Redémarrez tous les hôtes et BizTalk Server services.

  Pour vider la base de données BizTalkDTADb :

  • Méthode 1

    1. Sauvegardez toutes les bases de données BizTalk Server.
    2. Exécutez la procédure stockée dtasp_PurgeAllCompletedTrackingData . Pour plus d’informations sur la procédure stockée, consultez Comment vider manuellement des données de la base de données de suivi BizTalk.

  • Méthode 2 : utilisez cette option uniquement si la base de données BizTalkDTADb contient de nombreuses instances incomplètes qui doivent être supprimées.

    1. Sauvegardez toutes les bases de données BizTalk Server.
    2. Arrêtez tous les hôtes, services et adaptateurs isolés personnalisés BizTalk. Si vous utilisez HTTP ou l’adaptateur SOAP, redémarrez les services IIS.
    3. Exécutez la procédure stockée dtasp_CleanHMData sur la base de données BizTalkDTADb.
    4. Redémarrez tous les hôtes et BizTalk Server services.

  Si vous devez disposer des données de suivi, sauvegardez la base de données BizTalkDTADb, restaurez la base de données sur un autre SQL Server, puis videz la base de données BizTalkDTADb d’origine.

Si vous souhaitez obtenir de l’aide sur l’analyse des données MsgBoxViewer ou de la sortie PSSDIAG, contactez les services de support technique Microsoft. Avant de contacter le support technique, compressez les données MsgBoxViewer, la sortie PSSDIAG et les journaux d’événements mis à jour (fichiers .evt). Vous devrez peut-être envoyer ces fichiers à un ingénieur de support BizTalk Server.

Suivant

• Bonnes pratiques pour la maintenance des bases de données BizTalk Server

• Tables de base de données BizTalk Server avec une croissance importante

• Outils et utilitaires pour la résolution des problèmes

Voir aussi

Paramètres de SQL Server qui ne doivent pas être modifiés