Gérer et résoudre les problèmes des bases de données BizTalk Server

Cet article fournit des informations détaillées sur la gestion et la résolution des problèmes BizTalk Server bases de données.

Version du produit d’origine : bases de données BizTalk Server
Numéro de la base de connaissances d’origine : 952555

Résumé

L’intégrité des bases de données Microsoft BizTalk Server est importante pour un environnement de messagerie BizTalk Server réussi. Cet article décrit les points importants à prendre en compte lorsque vous travaillez avec des bases de données BizTalk Server. Ces considérations incluent les éléments suivants :

  • Vous devez désactiver les auto update statistics options et auto create statistics SQL Server.
  • Vous devez définir l’option max degree of parallelism (MAXDOP) correctement.
  • Déterminez à quel moment vous pouvez reconstruire BizTalk Server index.
  • Le verrouillage, l’interblocage ou le blocage peut se produire.
  • Vous pouvez rencontrer des problèmes avec des bases de données ou des tables volumineuses.
  • Travaux bizTalk SQL Server Agent.
  • Les instances de service peuvent être suspendues.
  • Vous pouvez rencontrer des problèmes de performances SQL Server et BizTalk Server.
  • Vous devez suivre les meilleures pratiques dans BizTalk Server.

Introduction

Cet article explique comment gérer BizTalk Server bases de données et comment résoudre les problèmes de base de données BizTalk Server.

Vous devez désactiver les options créer automatiquement des statistiques et mettre à jour automatiquement les statistiques

Vous devez conserver les auto create statistics options et auto update statistics désactivées sur la BizTalkMsgBoxDb base de données. Pour déterminer si ces paramètres sont désactivés, exécutez les procédures stockées suivantes dans SQL Server :

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

Vous devez définir le paramètre actuel sur off. Si ce paramètre est défini sur on, désactivez-le en exécutant les procédures stockées suivantes dans SQL Server :

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

Vous devez définir correctement la propriété Max Degree of Parallelism

Sur l’ordinateur qui exécute SQL Server et héberge la BizTalkMsgBoxDb base de données, définissez le degré maximal de parallélisme run_value et config_value les propriétés sur la valeur 1. Dans les versions ultérieures de SQL, il est également possible de spécifier ce paramètre par base de données plutôt que par instance SQL. Pour plus d’informations, consultez Définir MAXDOP. Pour déterminer le max degree of parallelism paramètre, exécutez la procédure stockée suivante sur la base de données Master dans SQL Server :

EXEC sp_configure 'show advanced options', 1;
GO
EXEC sp_configure 'max degree of parallelism'

Si les run_value propriétés et config_value ne sont pas définies sur la valeur 1, exécutez la procédure stockée suivante dans SQL Server pour les affecter à 1 :

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

Déterminer quand vous pouvez reconstruire BizTalk Server index

La plupart des index BizTalk Server sont en cluster (ID d’index : 1). Vous pouvez utiliser l’instruction DBCC SHOWCONTIG SQL Server pour afficher des informations de fragmentation pour les tables BizTalk Server.

Les index BizTalk Server sont basés sur un GUID. Par conséquent, la fragmentation se produit généralement. Si la valeur de densité d’analyse retournée par l’instruction DBCC SHOWCONTIG est inférieure à 30 %, les index BizTalk Server peuvent être reconstruits pendant les temps d’arrêt.

De nombreuses tables BizTalk Server contiennent des colonnes qui utilisent des DataType définitions. L’indexation en ligne ne peut pas être effectuée dans ces colonnes. Par conséquent, vous ne devez jamais reconstruire les index BizTalk Server pendant que BizTalk Server traite les données.

Le verrouillage, l’interblocage ou le blocage peut se produire

En règle générale, les verrous et les blocs se produisent dans un environnement BizTalk Server. Toutefois, ces verrous ou blocs ne sont pas conservés pendant une période prolongée. Par conséquent, le blocage et l’interblocage indiquent un problème potentiel.

Vous pouvez rencontrer des problèmes avec des bases de données ou des tables volumineuses

Nous avons vu que lorsque la BizTalkMsgBoxDb base de données est plus grande, des problèmes de performances peuvent se produire. Dans l’idéal, la BizTalkMsgBoxDb base de données ne doit contenir aucune donnée. La BizTalkMsgBoxDb base de données 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 BizTalkDTADb base de données BAM ou .

Un environnement qui utilise une SQL Server puissante au niveau du serveur principal et de nombreuses orchestrations de longue durée peut avoir une BizTalkMsgBoxDb base de données supérieure à 5 Go. Un environnement à volume élevé qui n’utilise pas d’orchestrations longues doit avoir une BizTalkMsgBoxDb base de données bien inférieure à 5 Go.

La BizTalkDTADb base de données n’a pas de taille définie. Toutefois, si les performances diminuent, la base de données est probablement trop volumineuse. Pour certains clients, 20 Go peuvent être considérés comme trop volumineux, tandis que pour d’autres, avec 200 Go, cela peut fonctionner correctement avec un serveur SQL très puissant s’exécutant sur plusieurs processeurs, beaucoup de mémoire et un réseau et un stockage rapides. Lorsque vous avez des bases de données BizTalk Server volumineuses, vous pouvez rencontrer les problèmes suivants :

  • La BizTalkMsgBoxDb base de données continue de croître. Toutefois, le fichier journal et la taille des données restent volumineux.

  • BizTalk Server prend plus de temps que d’habitude pour traiter un scénario de flux de messages simple.

  • La console d’administration BizTalk ou les requêtes HAT (Health and Activity Tracking) prennent plus de temps que d’habitude et peuvent expirer.

  • Le fichier journal de base de données n’est jamais tronqué.

  • Les travaux bizTalk SQL Server Agent s’exécutent plus lentement que d’habitude.

  • Certaines tables sont plus grandes ou ont trop de lignes par rapport à la taille de table habituelle.

Les bases de données peuvent devenir volumineuses pour diverses raisons. Ces raisons peuvent être les suivantes :

  • Les travaux SQL Server Agent BizTalk ne sont pas en cours d’exécution
  • Grand nombre d’instances suspendues
  • Défaillances de disque
  • Suivi
  • Limitation
  • Performances de Microsoft SQL Server
  • Latence réseau

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

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 BizTalkMsgBoxDb base de données vers la BizTalkDTADb base de données. Si l’hôte de suivi est arrêté, TDDS ne déplace pas les données vers la BizTalkDTADb base de données et les TrackingData_x_x tables de la BizTalkMsgBoxDb base de données augmentent.

Il est recommandé de dédier un hôte au suivi. Pour permettre à TDDS de gérer de nouveaux événements de suivi dans des scénarios à volume élevé, créez plusieurs instances d’un hôte de suivi unique. Il ne doit pas exister plus d’un hôte de suivi.

Il peut y 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 dta_DebugTrace table qui a plus d’un million de lignes a probablement trop de lignes. Une <HostName>Q_Suspended table qui a plus de 200 000 lignes a probablement trop de lignes.

Utiliser les travaux de SQL Server Agent BizTalk appropriés

Les travaux de SQL Server Agent BizTalk sont importants pour la gestion des bases de données BizTalk Server et pour maintenir des performances élevées.

Le travail de BizTalk Server SQL Server Agent de sauvegarde est la seule méthode prise en charge pour sauvegarder les bases de données BizTalk Server lorsque SQL Server Agent et les instances d’hôte BizTalkServer sont démarrées. Ce travail nécessite que toutes les bases de données BizTalk Server utilisent un mode de récupération complète. Vous devez configurer ce travail pour un environnement BizTalk Server sain. Les méthodes SQL Server peuvent être utilisées pour sauvegarder les bases de données BizTalk Server uniquement si SQL Server Agent est arrêté et si toutes les instances d’hôte BizTalk Server sont arrêtées.

Le MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail SQL Server Agent s’exécute à l’infini. Par conséquent, l’historique des travaux SQL Server Agent n’affiche jamais d’achèvement réussi. Si une défaillance se produit, le travail redémarre dans la minute et continue à s’exécuter à l’infini. Par conséquent, vous pouvez ignorer en toute sécurité l’échec. En outre, l’historique des travaux peut être effacé. Vous devez être préoccupé uniquement si l’historique des travaux signale que ce travail échoue constamment et redémarre.

Le MessageBox_Message_Cleanup_BizTalkMsgBoxDb travail SQL Server Agent est le seul travail BizTalk Server qui ne doit pas être activé, car il est démarré par le MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail SQL Server Agent.

Le travail de purge et d’archivage DTA SQL Server Agent permet de gérer la BizTalkDTADb base de données en purgeant et en archivant les messages suivis. Ce travail lit chaque ligne de la table et compare l’horodatage pour déterminer si l’enregistrement doit être supprimé.

Tous les travaux BizTalk SQL Server Agent, à l’exception du MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail SQL Server Agent, doivent s’exécuter correctement.

Les instances de service peuvent être suspendues

Les instances de service peuvent être suspendues (pouvant être reprises) ou suspendues (ne pouvant pas être reprises). Ces instances de service peuvent être messagerie, orchestration ou port.

Ces instances de service peuvent augmenter inutilement la BizTalkMsgBoxDb base de données et peuvent être arrêtées. Vous pouvez utiliser le hub de groupe pour interroger, reprendre ou arrêter des messages. Vous pouvez également utiliser Terminate.vbs'outil de script ou de BizTalk Health Monitor (BHM) pour interroger, vider et gérer des bases de données BizTalk. Dans certaines situations, il peut y avoir des messages orphelins ou zombies laissés dans le système. L’outil BHM peut vous aider à corriger ces situations.

Pour plus d’informations sur le script Terminate.vbs , consultez Suppression d’instances de service suspendues.

Les instances de mise en cache n’apparaissent pas dans la page Hub de groupe , et vous ne pouvez pas les suspendre ou les arrêter. Cette restriction est une cause courante de la croissance des tables. Pour empêcher les nouveaux messages zombies pour les instances du service de cache dans BizTalk Server 2006, installez le correctif logiciel dans l’article 936536 de la Base de connaissances Microsoft. Ce problème est résolu dans BizTalk Server 2006 R2 et versions ultérieures.

Remarque

Un message zombie est un message qui a été routé mais qui n’a pas été consommé.

Pour obtenir une description des messages zombies, visitez le site web MSDN suivant : WebLog du moteur BizTalk Core

Vous pouvez rencontrer des problèmes de performances SQL Server et BizTalk Server

BizTalk Server effectue des centaines de transactions courtes et rapides à SQL Server en moins d’une minute. Si le SQL Server ne peut pas soutenir cette activité, BizTalk Server peut rencontrer des problèmes de performances. Dans Analyseur de performances, surveillez les compteurs Avg. Disk sec/Read, Avg. Disk sec/Transfer et Avg. Disk sec/Write Analyseur de performances dans l’objet de performance PhysicalDisk. La valeur optimale est inférieure à 10 ms (millisecondes). Une valeur supérieure ou égale à 20 ms est considérée comme de mauvaises performances.

Bonnes pratiques en BizTalk Server

Démarrez SQL Server Agent sur le SQL Server. Lorsque le SQL Server Agent est arrêté, les travaux BizTalk intégrés SQL Server Agent responsables de la maintenance de la base de données ne peuvent pas s’exécuter. Ce comportement provoque la croissance de la base de données, et cette croissance peut entraîner des problèmes de performances.

Placez les fichiers SQL Server fichier de base de données des journaux (LDF) et du fichier de base de données principale (MDF) sur des lecteurs distincts. Lorsque les fichiers LDF et MDF des BizTalkMsgBoxDb bases de données et se BizTalkDTADb trouvent sur le même lecteur, une contention de disque peut se produire.

Si vous ne bénéficiez pas du suivi du corps des messages, n’activez pas cette fonctionnalité. Toutefois, il est judicieux d’activer le suivi du corps des messages pendant que vous développez et dépannez une solution. Si vous procédez ainsi, veillez à désactiver le suivi du corps des messages lorsque vous avez terminé. Lorsque le suivi du corps des messages est activé, les bases de données BizTalk Server augmentent. S’il existe un besoin métier qui nécessite l’activation du suivi du corps des messages, vérifiez que les TrackedMessages_Copy_BizTalkMsgBoxDb travaux de purge et d’archivage des SQL Server Agent DTA s’exécutent correctement.

En règle générale, des journaux de transactions plus petits entraînent de meilleures performances. Pour réduire la taille des journaux des transactions, configurez le travail de BizTalk Server SQL Server Agent de sauvegarde pour qu’il s’exécute plus fréquemment.

La sp_ForceFullBackup procédure stockée dans la BizTalkMgmtDb base de données peut également être utilisée pour effectuer une sauvegarde complète ad hoc des fichiers de données et des fichiers journaux. La procédure stockée met à jour la adm_ForceFullBackup table avec la valeur 1. La prochaine fois que le travail BizTalk Server de sauvegarde s’exécute, un jeu de sauvegarde de base de données complet est créé.

L’outil BizTalk Health Monitor (BHM) peut être utilisé pour évaluer un déploiement BizTalk Server existant. BHM effectue de nombreuses vérifications liées à la base de données.

Résolution des problèmes

Les meilleures étapes de résolution des problèmes pour les bases de données BizTalk Server SQL Server dépendent du type de problème de base de données, tel que le blocage ou l’interblocage. Pour résoudre un problème de base de données BizTalk Server, procédez comme suit.

Étape 1 : Activer et exécuter tous les travaux BizTalk SQL Server Agent requis

Tous les travaux BizTalk SQL Server Agent, à l’exception du MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail, doivent être activés et s’exécuter correctement. Ne désactivez aucun autre travail.

Si un échec se produit, 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 le MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail SQL Server Agent s’exécute à l’infini. Par conséquent, vous ne devez vous inquiéter que si l’historique des travaux signale que le travail échoue constamment et redémarre.

Étape 2 : Utiliser l’outil BizTalk Health Monitor (BHM)/MsgBoxViewer

Collectez le rapport BHM pendant que vous reproduisez un problème.

L’outil BHM est utile pour la résolution des problèmes, car il fournit un rapport HTML qui contient des informations détaillées sur la taille des tables et le nombre de lignes. Le rapport peut également aider à déterminer si BizTalk Server est limité. En outre, l’outil fournit une vue instantané des bases de données BizTalk Server et de la configuration BizTalk Server.

Pour plus d’informations sur la limitation dans BizTalk Server, consultez Comment BizTalk Server implémente la limitation de l’hôte.

Lorsque BizTalk Server s’exécute plus lentement que d’habitude, exécutez l’outil BHM, puis passez en revue le rapport HTML généré pour tout problème. La section Résumé répertorie les avertissements en jaune et les problèmes potentiels en rouge.

En outre, vous pouvez utiliser la sortie de l’outil BHM pour déterminer quelles tables sont les plus volumineuses et ont le plus d’enregistrements. Le tableau suivant répertorie les tables BizTalk Server dont la croissance est généralement la plus importante. Vous pouvez utiliser ces données pour déterminer où un problème potentiel peut exister.

Tableau Description
<HostName>Q_Suspended Cette table contient une référence aux messages de la Spool table qui sont associés à des instances suspendues pour l’hôte particulier. Cette table se trouve dans la BizTalkMsgBoxDb base de données.
<HostName>Q Cette table contient une référence aux messages de la Spool table qui sont associés à l’hôte particulier et qui ne sont pas suspendus. Cette table se trouve dans la BizTalkMsgBoxDb base de données.
Spool

Parts

Fragments
Ces tables stockent les données de message réelles dans la BizTalkMsgBoxDb base de données.
Instances Cette table stocke toutes les instances et leurs status actuelles dans la BizTalkMsgBoxDb base de données.
TrackingData_0_x Ces quatre tables stockent les événements suivis bam (Business Activity Monitoring) dans la BizTalkMsgBoxDb base de données pour que TDDS déplace les événements vers la BAMPrimaryImport base de données.
TrackingData_1_x Ces quatre tables stockent les événements suivis dans la BizTalkMsgBoxDb base de données pour que TDDS déplace les événements vers la BizTalkDTADB base de données.
Tracking_Fragmentsx
Tracking_Partsx
Tracking_Spoolx
Deux de ces tables se trouve dans les BizTalkMsgBoxDb bases de données et BizTalkDTADb . L’un est en ligne et l’autre hors connexion.

Dans BizTalk Server 2004 SP2 et dans les versions ultérieures, le TrackedMessages_Copy_BizTalkMsgBoxDb travail SQL Server Agent déplace les corps des messages suivis directement vers ces tables dans la BizTalkDTADb base de données.

Dans BizTalk Server 2004 Service Pack 1 (SP1) et dans les versions antérieures de BizTalk Server 2004, le travail SQL Server Agent copie les TrackedMessages_Copy_BizTalkMsgBoxDb corps des messages suivis dans ces tables de la BizTalkMsgBoxDb base de données. Le TrackingSpool_Cleanup_BizTalkMsgBoxDb travail SQL Server Agent vide les tables hors connexion et les met en ligne, tandis que le travail met également les tables en ligne hors connexion.
dta_ServiceInstances Cette table stocke les événements suivis pour les instances de service dans la BizTalkDTADb base de données. Si cette table est volumineuse, la BizTalkDTADb base de données est probablement volumineuse.
dta_DebugTrace Cette table stocke les événements du débogueur Orchestration dans la base de données BizTalkDTADb.
dta_MessageInOutEvents Cette table stocke les messages d’événements suivis dans la BizTalkDTADb base de données. Ces messages d’événement suivis incluent des informations de contexte de message.
dta_ServiceInstanceExceptions Cette table stocke des informations d’erreur pour les instance de service suspendus dans la BizTalkDTADb base de données.

Prenons les cas de figure suivants.

  • <HostName>Q_Suspended Tables

    Si les <HostName>Q_Suspended tables ont de nombreux enregistrements, les tables peuvent être des instances suspendues valides qui apparaissent dans le hub de groupe ou dans HAT. Ces instances peuvent être arrêtées. Si ces instances n’apparaissent pas dans le hub de groupe ou dans HAT, les instances sont probablement des instances de mise en cache ou des rapports d’échec de routage orphelins. Lorsque les instances suspendues sont arrêtées, les éléments de cette table et les lignes associées dans les Spool tables et Instances sont nettoyés.

    Dans ce scénario, gérez les instances suspendues en les reprenant ou en les mettant fin. L’outil BHM peut également être utilisé.

  • <HostName>Q Tables

    Si les <HostName>Q tables ont de nombreux enregistrements, les types d’instances suivants peuvent exister :

    • Instances prêtes à l’exécution
    • Instances actives
    • Les instances déshydratées BizTalk Server ont besoin de temps pour « rattraper » et traiter les instances.

    Cette table peut augmenter lorsque le taux de traitement entrant dépasse le taux de traitement sortant. Ce scénario peut se produire lorsqu’un autre problème se produit, tel qu’une base de données volumineuse BizTalkDTADb ou des retards de disque SQL Server.

  • SpoolTables , Partset Fragments

    Si les Spooltables , Partset Fragments ont de nombreux enregistrements, de nombreux messages sont actuellement actifs, déshydratés ou suspendus. Selon la taille, le nombre de parties et les paramètres de fragmentation dans ces tables, un seul message peut générer toutes ces tables. Chaque message a exactement une ligne dans le Spool tableau et au moins une ligne dans la Parts table.

  • Instances Table

    L’administrateur BizTalk ne doit pas autoriser de nombreuses instances suspendues à rester dans la Instances table. Les instances déshydratées ne doivent rester que si la logique métier nécessite des orchestrations longues. N’oubliez pas qu’un service instance peut être associé à de nombreux messages sur la Spool table.

  • TrackingData_x_x Tables

    Si les TrackingData_x_x tables sont volumineuses, l’hôte de suivi (TDDS) ne s’exécute pas correctement. Si le instance hôte de suivi est en cours d’exécution, passez en revue les journaux des événements et la TDDS_FailedTrackingData table dans la BizTalkDTADb base de données pour obtenir des informations d’erreur. Si BizTalk est limité avec l’état 6 (base de données volumineuse), ces tables peuvent également être tronquées à l’aide de l’outil BizTalk Terminator si les données ne sont pas nécessaires.

    S’il existe un écart important entre les numéros de séquence dans les BizTalkMsgBoxDbTrackingData_x_x tables et les BAMPrimaryImport tables ou BizTalkDTADbTDDS_StreamStatus , TDDS peut ne pas déplacer les données de la BizTalkMsgBoxDb base de données. Pour corriger ce problème, utilisez l’outil BHM pour vider ces tables et réinitialiser le numéro de séquence.

  • dta_DebugTrace et dta_MessageInOutEvents tables

    Le dta_DebugTrace tableau est rempli lorsque le début et la fin de la forme sont activés sur une orchestration. Si la dta_DebugTrace table contient de nombreux enregistrements, ces événements de débogage d’orchestration sont utilisés ou ont été utilisés. Si le débogage d’orchestration n’est pas nécessaire pour les opérations régulières, désactivez la zone Début et fin de la forme case activée dans les propriétés Orchestration.

    La dta_MessageInOutEvents table est remplie lorsque l’envoi et la réception de messages sont activés sur les orchestrations et/ou les pipelines. Si ces événements de suivi ne sont pas nécessaires, désactivez la case case activée pour cette option dans les propriétés d’orchestration et/ou de pipeline.

    Si ces événements de trace sont désactivés ou s’il existe un backlog dans la BizTalkMsgBoxDb base de données, ces tables peuvent continuer à croître, car TDDS continue de déplacer ces données dans ces tables.

    Par défaut, le suivi global est activé. Si le suivi global n’est pas nécessaire, il peut être désactivé. Pour plus d’informations, consultez Comment désactiver le suivi global.

    Si la dta_DebugTrace table et/ou la dta_messageInOutEvents table de la BizTalkDTADb base de données sont trop volumineuses, vous pouvez tronquer les tables manuellement après avoir arrêté l’hôte de suivi. L’outil BHM fournit également cette fonctionnalité.

    Pour tronquer toutes les tables de suivi dans la BizTalkMsgBoxDb base de données, utilisez l’outil BHM. L’outil BHM est disponible en externe dans le Centre de téléchargement Microsoft.

    Pour plus d’informations sur les instructions de dimensionnement de base de données de suivi, visitez le site web MSDN suivant : Instructions de dimensionnement de base de données de suivi.

  • dta_ServiceInstanceExceptions Table

    La dta_ServiceInstanceExceptions table devient généralement volumineuse dans un environnement qui a régulièrement suspendu des instances.

Étape 3 : Examiner 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 2005 et versions ultérieures, exécutez l’instruction suivante :

DBCC TRACEON (1222,-1)

Dans SQL Server 2000, exécutez l’instruction suivante :

DBCC TRACEON (1204)

En outre, utilisez l’utilitaire PSSDiag pour collecter des données sur l’événement Lock:Deadlock et l’événement Lock:Deadlock Chain.

La BizTalkMsgBoxDB base de données est une base de données OLTP (Online Transaction Processing) à volume élevé et à transaction élevée. Certains interblocages sont attendus, 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 des erreurs. Lorsque vous examinez un scénario d’interblocage, l’interblocage que vous examinez dans la sortie doit être corrélé à une erreur d’interblocage dans les journaux des événements.

La commande de retrait de la file d’attente et certains travaux SQL Server Agent sont censés se bloquer. En règle générale, ces travaux sont sélectionnés comme victimes d’interblocage. Ces travaux apparaissent dans une trace d’interblocage. Toutefois, aucune erreur n’est répertoriée dans les journaux des événements. Par conséquent, cet interblocage est attendu et vous pouvez ignorer en toute sécurité l’interblocage avec ces travaux.

Si des interblocages fréquents apparaissent dans une trace d’interblocage et si une erreur de corrélation est répertoriée dans les journaux des événements, vous pouvez souhaiter l’interblocage.

Étape 4 : Rechercher les processus bloqués

Utilisez le Moniteur d’activité dans SQL Server pour obtenir l’identificateur de processus serveur (SPID) d’un processus système de verrouillage. Ensuite, exécutez SQL Profiler pour déterminer l’instruction SQL qui s’exécute dans le SPID de verrouillage.

Pour résoudre un problème de verrouillage et de blocage dans SQL Server, utilisez l’utilitaire PSSDiag pour SQL afin de capturer tous les événements Transact-SQL pour utilisant le script de blocage activé.

Dans SQL Server 2005 et versions ultérieures, 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 le paramètre de seuil de processus bloqué , consultez Option de configuration du serveur du seuil de processus bloqué.

Remarque

Lorsque vous rencontrez un problème de verrouillage ou de blocage dans SQL Server, il est recommandé de contacter les services de support technique Microsoft. Les services de support technique Microsoft peuvent vous aider à configurer les options appropriées de l’utilitaire PSSDiag.

Étape 5 : Installer la dernière BizTalk Server Service Pack et la mise à jour cumulative

BizTalk Server versions ultérieures ont été déplacées vers un modèle de mise à jour cumulative (CU). Les mises à jour cumulatives contiennent les derniers correctifs.

Supprimer toutes les données

Si les bases de données sont trop volumineuses ou si la méthode recommandée consiste à supprimer toutes les données, toutes les données peuvent être supprimé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.

Étapes de purge de base de données BizTalkMsgBoxDb

Pour supprimer toutes les données de la BizTalkMsgBoxDb base de données, utilisez l’outil BizTalk Health Monitor (BHM).

Options de purge de base de données BizTalkDTADb

Pour supprimer toutes les données de la BizTalkDTADb base de données, utilisez l’outil BizTalk Health Monitor (BHM). Sinon, utilisez l’une des méthodes suivantes.

Remarque

Bien que les deux méthodes suppriment tous les messages, la méthode 2 est plus rapide.

  • Méthode 1 :

    1. Sauvegardez toutes les bases de données BizTalk Server.

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

      Remarque

      Cette action supprime tous les messages terminés.

  • Méthode 2 :

    1. Sauvegardez toutes les bases de données BizTalk.

    2. Exécutez la dtasp_CleanHMData procédure stockée. Utilisez cette option uniquement si la BizTalkDTADb base de données contient de nombreuses instances incomplètes qui doivent être supprimées.

      Pour cela, procédez comme suit :

      1. 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.
      2. Exécutez la dtasp_CleanHMData procédure stockée sur la BizTalkDTADb base de données.
      3. Redémarrez tous les hôtes et services BizTalk Server.

BizTalk Server 2004 uniquement

Remarque

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

Si vous avez besoin d’aide pour analyser les données BHM ou la sortie PSSDiag, contactez les services de support technique Microsoft. Pour obtenir la liste complète des numéros de téléphone des services de support technique et des informations sur les coûts de support, consultez Contacter Support Microsoft.

Remarque

Avant de contacter les services de support technique, compressez les données du rapport BHM, la sortie PSSDiag et les journaux des événements mis à jour (fichiers .evt). Vous devrez peut-être envoyer ces fichiers à un ingénieur du support BizTalk Server.

S’applique à

  • BizTalk Server 2009
  • BizTalk Server 2010
  • BizTalk Server 2013
  • BizTalk Server 2013 R2
  • BizTalk Server 2016
  • BizTalk Server 2020