Partager via

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

  • Article

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

Version du produit d’origine : bases de données BizTalk Server
Numéro de 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 traite des éléments importants à prendre en compte lorsque vous travaillez avec des bases de données BizTalk Server. Ces considérations sont les suivantes :

  • 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 quand vous pouvez reconstruire des index BizTalk Server.
  • Le verrouillage, l’interblocage ou le blocage peuvent 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 les bases de données BizTalk Server et comment résoudre les problèmes de base de données BizTalk Server.

Vous devez désactiver les options de création automatique de statistiques et de mise à jour automatique des statistiques

Vous devez conserver les options et auto update statistics les auto create statistics options 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 onsur , 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 exécutant SQL Server et hébergeant la BizTalkMsgBoxDb base de données, définissez le degré maximal de parallélisme run_value et config_value de 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 au lieu d’une 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 propriétés et config_value les run_value propriétés ne sont pas définies sur la valeur 1, exécutez la procédure stockée suivante dans SQL Server pour les définir sur 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 des index BizTalk Server

La plupart des index BizTalk Server sont 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 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 le temps d’arrêt.

De nombreuses tables BizTalk Server contiennent des colonnes qui utilisent DataType des 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 peuvent 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 restent pas pendant une période prolongée. Par conséquent, le blocage et le blocage indiquent un problème potentiel.

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

Nous avons constaté que lorsque la BizTalkMsgBoxDb base de données est plus grande, les 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.

Un environnement qui utilise un serveur SQL Server puissant au serveur principal et de nombreuses orchestrations longues peuvent avoir une BizTalkMsgBoxDb base de données supérieure à 5 Go. Un environnement à volume élevé qui n’utilise aucune orchestration longue ne doit avoir une BizTalkMsgBoxDb base de données beaucoup plus petite que 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 peuvent fonctionner correctement avec un serveur SQL très fort s’exécutant sur plusieurs processeurs, beaucoup de mémoire et un réseau et un stockage rapides. Lorsque vous avez de grandes bases de données BizTalk Server, 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 même 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 de l’Agent SQL Server BizTalk s’exécutent plus lentement que d’habitude.

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

Les bases de données peuvent devenir volumineuses pour différentes raisons. Ces raisons peuvent inclure les éléments suivants :

  • Les travaux de BizTalk SQL Server Agent ne sont pas en cours d’exécution
  • Grand nombre d’instances suspendues
  • Échecs de disque
  • Suivi
  • Limitation
  • Performances de Microsoft SQL Server
  • Latence du 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 exige 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 n’existe pas 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 de 1 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 BizTalk SQL Server Agent corrects

Les travaux de l’Agent SQL Server BizTalk sont importants pour gérer les bases de données BizTalk Server et pour maintenir des performances élevées.

Le travail de l’agent SQL Server de sauvegarde BizTalk Server est la seule méthode prise en charge pour sauvegarder les bases de données BizTalk Server lorsque SQL Server Agent et les instances hôtes BizTalkServer sont démarrées. Ce travail nécessite que toutes les bases de données BizTalk Server utilisent un modèle 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 hôtes BizTalk Server sont arrêtées.

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

Le MessageBox_Message_Cleanup_BizTalkMsgBoxDb travail DE 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 DTA Purge and Archive SQL Server Agent permet de gérer la BizTalkDTADb base de données en purgeant et en archiveant les messages suivis. Ce travail lit chaque ligne du tableau 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 reprise) ou suspendues (non pouvant être reprise). Ces instances de service peuvent être la messagerie, l’orchestration ou le 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 le script Terminate.vbs ou l’outil BHM (BizTalk Health Monitor) 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 aider à corriger ces situations.

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

La mise en cache des instances n’apparaît 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 croissance de table. Pour empêcher de nouveaux messages zombies pour les instances de service de cache dans BizTalk Server 2006, installez le correctif logiciel dans l’article de la Base de connaissances Microsoft 936536. Ce problème est résolu dans BizTalk Server 2006 R2 et versions ultérieures.

Note

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 vers SQL Server dans un délai d’une minute. Si 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 compteurs dans l’objet de performances 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.

Meilleures pratiques dans BizTalk Server

Démarrez SQL Server Agent sur SQL Server. Lorsque l’agent SQL Server est arrêté, les travaux BizTalk SQL Server Agent intégrés qui sont 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 LDF (Sql Server Log Database File) et Le fichier de base de données principal (MDF) sur des lecteurs distincts. Lorsque les fichiers LDF et MDF pour les BizTalkMsgBoxDb bases BizTalkDTADb de données se trouvent sur le même lecteur, la 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 résolvez les problèmes d’une solution. Si vous effectuez cette opération, veillez à désactiver le suivi du corps des messages lorsque vous avez terminé. Lorsque le suivi du corps du message 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 de l’agent SQL Server sont en cours d’exécution.

En règle générale, les journaux de transactions plus petits entraînent de meilleures performances. Pour réduire la taille des journaux des transactions, configurez le travail de l’Agent SQL Server BizTalk Server 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 données et des fichiers journaux. La procédure stockée met à jour la adm_ForceFullBackup table avec une valeur 1. La prochaine fois que le travail De sauvegarde BizTalk Server s’exécute, un jeu de sauvegarde de base de données complet est créé.

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

Dépannage

Les meilleures étapes de résolution des problèmes pour les bases de données SQL Server BizTalk 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, sauf que le MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail doit être activé et exécuté 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ésolvez l’échec en conséquence. N’oubliez pas que le MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail SQL Server Agent s’exécute infiniment. Par conséquent, vous ne devez être préoccupé 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 lors de la reproduction d’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 les tailles de table et le nombre de lignes. Le rapport peut également aider à déterminer si BizTalk Server est limité. En outre, l’outil fournit une vue d’instantané des bases de données BizTalk Server et de la configuration de 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 les tables les plus volumineuses et avoir le plus d’enregistrements. Le tableau suivant répertorie les tables BizTalk Server qui augmentent généralement le plus grand. Vous pouvez utiliser ces données pour déterminer où un problème potentiel peut exister.

Table 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 leur état actuel dans la BizTalkMsgBoxDb base de données.
TrackingData_0_x Ces quatre tables stockent les événements bam (Business Activity Monitoring) suivis dans la BizTalkMsgBoxDb base de données pour TDDS afin de déplacer 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 TDDS afin de déplacer les événements vers la BizTalkDTADB base de données.
Tracking_Fragmentsx
Tracking_Partsx
Tracking_Spoolx		 Deux de ces tables se situent dans les bases de données et BizTalkDTADb dans les BizTalkMsgBoxDb bases de données. L’un est en ligne, et l’autre est hors connexion.

Dans BizTalk Server 2004 SP2 et dans les versions ultérieures, le TrackedMessages_Copy_BizTalkMsgBoxDb travail de SQL Server Agent déplace les corps de messages suivis directement vers ces tables de 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 TrackedMessages_Copy_BizTalkMsgBoxDb travail sql Server Agent copie les corps de messages suivis dans ces tables de la BizTalkMsgBoxDb base de données. Le TrackingSpool_Cleanup_BizTalkMsgBoxDb travail DE SQL Server Agent vide les tables hors connexion et rend les tables en ligne tandis que le travail prend é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énements suivis incluent des informations de contexte de message.
dta_ServiceInstanceExceptions Cette table stocke les informations d’erreur pour toute instance de service suspendue dans la BizTalkDTADb base de données.

Examinez les scénarios 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 mises en cache ou les rapports d’échecs de routage orphelins. Lorsque des instances suspendues sont arrêtées, les éléments de cette table et leurs lignes associées dans les Spool tables sont Instances nettoyés.

    Dans ce scénario, gérez les instances suspendues en les reprise ou en les terminant. 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 croître lorsque le taux entrant de traitement dépasse le taux sortant de traitement. 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.

  • Spool, Partset Fragments tables

    Si les Spoolenregistrements , Partset Fragments les tables sont nombreux, de nombreux messages sont actuellement actifs, déshydratés ou suspendus. Selon la taille, le nombre de parties et les paramètres de fragmentation de ces tables, un message unique peut générer toutes ces tables. Chaque message a exactement une ligne dans la Spool table 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’une instance de service peut être associée à 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 l’instance hôte de suivi est en cours d’exécution, passez en revue les journaux des événements et la TDDS_FailedTrackingData table de la BizTalkDTADb base de données pour obtenir des informations d’erreur. Si BizTalk limite l’état 6 (base de données volumineuse), ces tables peuvent également être tronquées à l’aide de l’outil Terminator BizTalk si les données ne sont pas nécessaires.

    S’il existe un écart important entre les numéros de séquence dans les BizTalkMsgBoxDb TrackingData_x_x tables et les BizTalkDTADb BAMPrimaryImport TDDS_StreamStatus tables, 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

    La dta_DebugTrace table est remplie 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 utilisés. Si le débogage d’orchestration n’est pas nécessaire pour les opérations régulières, désactivez la case à cocher Début et fin de la forme dans les propriétés d’orchestration.

    La dta_MessageInOutEvents table est remplie lorsque l’envoi et la réception du message 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 à cocher de cette option dans les propriétés d’orchestration et/ou de pipeline.

    Si ces événements de trace sont désactivés ou si un backlog existe 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 le suivi des instructions de dimensionnement de base de données, consultez le site web MSDN suivant : Instructions de dimensionnement de base de données.

  • 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 de blocage, activez le suivi DBCC sur sql Server afin que les informations de blocage 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 (High-Volume and High-transaction Online Transaction Processing). Certains interblocages sont attendus et ce blocage est géré en interne par le moteur 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 de blocage, le blocage que vous examinez dans la sortie doit être corrélé avec une erreur d’interblocage dans les journaux des événements.

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

Si des interblocages fréquents apparaissent dans une trace de blocage et si une erreur de corrélation est répertoriée dans les journaux d’événements, vous souhaiterez peut-être le blocage.

É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 pour capturer tous les événements Transact-SQL sur utilisant le script bloquant 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 l’option de configuration du serveur de seuil de processus bloqué.

Note

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 correctes de l’utilitaire PSSDiag.

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

Les versions ultérieures de BizTalk Server 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 préféré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 BHM (BizTalk Health Monitor).

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 BHM (BizTalk Health Monitor). Sinon, utilisez l’une des méthodes suivantes.

Note

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 les données à partir de la base de données de suivi BizTalk.

      Note

      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 ce faire, procédez comme suit :

      1. Arrêtez tous les hôtes, services et adaptateurs isolés BizTalk personnalisés. 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 les services BizTalk Server.

Étapes BizTalk Server 2004 uniquement

Note

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 serveur SQL Server, puis videz la base de données d’origine BizTalkDTADb .

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 Contact Support Microsoft.

Note

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

S’applique à

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