Identification des goulots d'étranglement dans la base de données MessageBox
Pour identifier les goulots d'étranglement dans la base de données MessageBox, commencez par vous assurer que le service SQL-Server-Agent est démarré. Modifiez l’état de démarrage du service de Manuel à Auto afin que, si le serveur est redémarré, le service redémarre automatiquement.
Par défaut, le service BizTalk limite si les tables Spool, TrackingData ou ApplicationQ augmentent. Ces tables sont nettoyées par SQL-Agent travaux, qui, s’ils ne sont pas en cours d’exécution, entraînent la croissance du Spool, ce qui entraîne le démarrage de la limitation et protège la base de données contre une pression supplémentaire. Vérifiez l'état des compteurs de performances suivants :
BizTalk : agent des messages (nom de l'hôte) état de limitation de remise de messages
BizTalk : agent des messages (nom de l'hôte) état de limitation de publication de messages
La valeur « 0 » indique qu’aucune limitation ne se produit. La valeur « 6 » indique que le système est limité en raison de la croissance de la base de données. Pour plus d’informations sur l’interprétation des valeurs de ces compteurs, consultez Qu’est-ce que la limitation de l’hôte (https://go.microsoft.com/fwlink/?LinkID=154694) et Les compteurs de performances de limitation de l’hôte (https://go.microsoft.com/fwlink/?LinkID=155285) dans la documentation BizTalk Server 2010.
Croissance de la table de pool
Le spouleur peut augmenter pour de multiples raisons. L’une des raisons de la croissance de Spool est si les files d’attente d’applications augmentent. Elles peuvent augmenter pour des raisons telles que des goulots d’étranglement en aval et/ou une contention de ressources.
Si les files d’attente d’applications sont petites et que le Spool est toujours volumineux, vérifiez que les travaux de vidage sont en cours. Vérifiez que le service SQL-Agent est en cours d'exécution puis que les travaux suivants s'effectuent correctement :
MessageBox_Message_Cleanup_BizTalkMessageBoxDb
MessageBox_Parts_Cleanup_BizTalkMessageBoxDb
Si la table MessageZeroSum est volumineuse, elle indique que les messages ont été traités. Cela signifie que DeQueue a correctement terminé et supprimé les données des tables file d’attente d’applications et que les lignes ont été marquées pour suppression. Cependant, les travaux de purge ne sont pas capables de suivre la cadence de suppression des données. Cela peut se produire si l’ordinateur exécutant SQL Server rencontre une contention grave du processeur, ce qui affecte la capacité des travaux de vidage à se maintenir en raison d’une insuffisance de processeur.
Croissance de la table de file d’attente d’application
Les files d’attente d’applications hébergent les données de transition en cours qui, une fois traitées, sont nettoyées par DeQueue.
Une fois ces messages traités, la table Spool (contenant des références à ces lignes) peut être nettoyée.
Par exemple, RxHostQ publie des données sur l’orchestration PxHostQ. Cette file d’attente publie des données sur le TxHostQ d’envoi, chacun référençant une ligne dans la table Spool. Une fois que les messages d’un HostQ particulier ont été correctement traités via le système, ces lignes sont supprimées par DeQueue. Une fois ces rangées supprimées, le spouleur (qui n'est plus référencé par ces rangées) peut alors être nettoyé par les travaux de purge.
La croissance de la file d’attente des applications indique que les instances hôtes responsables du drainage de la file d’attente des applications ne peuvent pas suivre le rythme entrant.
Par exemple, la file d'attente de l'application d'orchestration (PxHostQ) peut augmenter parce que le serveur chargé du traitement des orchestrations est lié à l'UC et incapable de les traiter plus rapidement. Toutefois, si le serveur de réception est rapide, il peut publier plus rapidement que ce que le serveur d’orchestration peut traiter, ce qui entraîne la croissance de la file d’attente des applications.
Une autre raison de la croissance de la file d’attente d’orchestration peut être due à une contention de mémoire. Lorsque de nombreuses instances d’orchestration de longue durée sont instanciées simultanément en mémoire, le ballonnement de la mémoire entraîne indirectement la limitation de la réduction du pool de threads jusqu’à ce que la pression de la mémoire soit soulagée.
L’une des raisons pour lesquelles la file d’attente d’envoi d’applications peut augmenter est si le système en aval ne parvient pas à recevoir des messages (sortants de BizTalk Server) suffisamment rapidement. Ainsi, les messages continueront de résider dans le système BizTalk, ce qui entraîne la croissance de la file d’attente des applications. Cela peut entraîner le démarrage de la limitation et réduire le taux de réception ayant un impact sur le débit global du système.
Croissance de la table TrackingData
La table TrackingData de la base de données MessageBox est une table de transition dans laquelle les intercepteurs écrivent des données de suivi à la fois pour le suivi de l’intégrité et de l’activité (HAT) et du suivi bam (Business Activity Monitoring). Si le suivi a été désactivé, cette table doit être vide. Par défaut, le suivi HAT est activé pour les événements d’entrée/sortie des pipelines et des orchestrations.
Si le suivi du corps du message est activé, vérifiez que le serveur de base de données MessageBox (autrement dit, l’hôte avec « autoriser le suivi de l’hôte ») est en cours d’exécution. S’assurer que l’hôte avec « autoriser le suivi de l’hôte » est en cours d’exécution réduit le risque de goulot d’étranglement lorsque l’hôte déplace les données de la table TrackingData de la base de données MessageBox vers les tables de base de données suivi BizTalk.
Il est possible de suivre des événements personnalisés en activant le suivi HAT personnalisé, par exemple, sur les propriétés promues et le suivi du corps des messages. En plus des données de suivi HAT, les données BAM sont également écrites dans la table TrackingData. Le service TDDS (Tracking Data Decode Service, qui s’exécute sur le instance hôte sur lequel le suivi est activé) est chargé de déplacer ces données de la base de données MessageBox vers les bases de données BizTalk Tracking et BAM Primary Import. Ensuite, une fois les données déplacées, TDDS supprime ces données. Les données de suivi des corps de message sont déplacées séparément par le travail de SQL-Agent TrackedMessages_Copy_BizTalkMsgBoxDb.
Si TDDS ne parvient pas à suivre la vitesse à laquelle les intercepteurs écrivent des données dans la table TrackingData, cette table augmente, ce qui entraîne le démarrage de la limitation. Cela a un impact sur le débit durable. Pour atténuer ce problème, vérifiez qu’au moins un hôte est en cours d’exécution avec le suivi activé.
Si les données s’accumulent toujours, assurez-vous que la base de données de suivi BizTalk n’est pas hors de contrôle. Vérifiez également que le travail d’archivage et de vidage est en cours d’exécution et qu’il est en mesure de suivre la vitesse d’arrivée des données.
Notes
Par défaut, le travail de vidage ne peut pas supprimer des données des tables de base de données de suivi BizTalk tant que ces données n’ont pas été archivées. Si vous n’avez pas besoin d’archiver les données de suivi, vous pouvez modifier le travail pour vider la base de données de suivi BizTalk sans archivage en suivant les étapes décrites dans Comment vider les données de la base de données de suivi BizTalk (https://go.microsoft.com/fwlink/?LinkID=153817).