Taille d'enregistrement dans les bases de données de suivis
Pour vous aider à planifier la configuration matérielle requise pour BizTalk, le tableau suivant indique la taille d'enregistrement prévue pour différents enregistrements d'événement dans la base de données des suivis.
Type d’action | Taille | Notes |
---|---|---|
Déploiement d'un service | 1864 + taille des informations symboliques | Les informations symboliques dépendent de la taille de l'orchestration. Par exemple, une orchestration qui reçoit un message et renvoie un message contenant 2 formes nécessite environ 4 000 octets. |
Instance de service ayant démarré et abouti | Normalement, 252 octets. 735 octets dans les cas extrêmes. |
|
Instance de service ayant démarré et échoué ou rencontré une erreur | Normalement, 252 octets + informations sur l'erreur. 735 octets + les informations sur l'erreur dans les cas extrêmes. |
Les informations sur l'erreur sont les données texte renvoyées par un composant BizTalk ou utilisateur. Elles peuvent nécessiter de 100 octets à 2 Ko. |
Début/fin d'une forme dans une orchestration | 120 octets chacun. | |
Événements d'entrée/sortie de message | 162 octets au minimum. Premier affichage du message : 202 octets + propriétés du message (si un suivi est effectué). 2 930 octets dans les cas extrêmes. |
Si aucun suivi des propriétés des messages n'est effectué, vous pouvez compter sur une taille moyenne de 128 octets. |
Taille des propriétés des messages | 40 à 288 octets si DTA reconnaît les propriétés de suivi. Ajoutez jusqu'à 268 octets s'il s'agit du suivi initial d'une propriété. |
Voir aussi
Qu’est-ce que le suivi des messages ?
Architecture de gestion et de suivi
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour