Freigeben über

Ermitteln von Engpässe in der MessageBox-Datenbank

  • Artikel

Um Engpässe der MessageBox-Datenbank zu ermitteln, muss zunächst sichergestellt werden, dass der SQL Server-Agent-Dienst gestartet wurde. Ändern Sie den Startstatus des Diensts von Manuell in Auto, sodass der Dienst automatisch neu gestartet wird, wenn der Server neu gestartet wird.

Standardmäßig drosselt der BizTalk-Dienst, wenn die Spool-, TrackingData- oder ApplicationQ-Tabellen wachsen. Diese Tabellen werden von SQL-Agent-Aufträgen gekürzt, die bei nicht ausgeführter Ausführung dazu führen, dass der Spool anwächst, wodurch die Drosselung gestartet und die Datenbank vor zusätzlichem Druck geschützt wird. Prüfen Sie den Status der folgenden Leistungsindikatoren:

Wachstum der Spooltabelle

Diese Tabelle kann aus verschiedenen Gründen an Umfang zunehmen. Ein Grund für das Spool-Wachstum ist, wenn die Anwendungswarteschlangen wachsen. Sie könnten aufgrund von Gründen wie nachgelagerten Engpässen und/oder Ressourcenkonflikten wachsen.

Wenn die Anwendungswarteschlangen klein sind und der Spool weiterhin groß ist, überprüfen Sie, ob die Löschaufträge weiterhin ausgeführt werden. Stellen Sie sicher, dass der SQL Agent-Dienst ausgeführt wird, und dass folgende Aufträge erfolgreich abgeschlossen werden:

  • MessageBox_Message_Cleanup_BizTalkMessageBoxDb

  • MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

    Wenn die MessageZeroSum-Tabelle groß ist, gibt dies an, dass die Nachrichten verarbeitet wurden. Dies bedeutet, dass DeQueue erfolgreich Daten aus den Tabellen der Anwendungswarteschlange abgeschlossen und gelöscht hat und die Zeilen zum Löschen gekennzeichnet wurden. Mithilfe der Löschaufträge können jedoch nicht ausreichend Daten gelöscht werden. Dies kann passieren, wenn auf dem Computer, auf dem SQL Server ausgeführt wird, schwerwiegende CPU-Konflikte auftreten, die sich auf die Fähigkeit der Löschaufträge auswirken, aufgrund von CPU-Aushungern mitzuhalten.

Wachstum der Anwendungswarteschlangentabelle

Anwendungswarteschlangen hosten Übergangsdaten in Flight, die nach der Verarbeitung von DeQueue bereinigt werden.

Nachdem diese Nachrichten verarbeitet wurden, kann die Spool-Tabelle (mit Verweisen auf diese Zeilen) bereinigt werden.

Beispielsweise veröffentlicht RxHostQ Daten in der Orchestrierung PxHostQ. Diese Warteschlange veröffentlicht Daten im sendenden TxHostQ, die jeweils auf eine Zeile in der Spool-Tabelle verweisen. Nachdem die Nachrichten für einen bestimmten HostQ erfolgreich durch das System verarbeitet wurden, werden diese Zeilen von DeQueue gelöscht. Im Anschluss an die Löschung der Spalten kann der Spool (der keine Verweise auf diese Spalten mehr beinhaltet) mithilfe der Löschaufträge gelöscht werden.

Das Wachstum der Anwendungswarteschlange gibt an, dass die Hostinstanzen, die für die Entleerung der Anwendungswarteschlange verantwortlich sind, nicht mit der eingehenden Rate Schritt halten können.

So kann beispielsweise die Orchestrierungs-Anwendungswarteschlange (PxHostQ) anwachsen, da der für die Verarbeitung der Orchestrierungen verantwortliche Server CPU-gebunden und zu keiner schnelleren Verarbeitung in der Lage ist. Wenn der empfangende Server jedoch schnell ist, veröffentlicht er möglicherweise schneller als das, was der Orchestrierungsserver verarbeiten kann, was zu einer Zunahme der Anwendungswarteschlange führt.

Ein weiterer Grund für das Wachstum der Orchestrierungswarteschlange könnte auf Speicherkonflikte zurückzuführen sein. Wenn viele Orchestrierungsinstanzen mit langer Ausführungszeit gleichzeitig im Arbeitsspeicher instanziiert werden, führt die Speicheraufblähung indirekt dazu, dass die Drosselung des Threadpools verkleinert wird, bis der Arbeitsspeicherdruck gelindert wird.

Ein Grund, warum die Sendeanwendungswarteschlange vergrößert werden kann, ist, wenn das nachgeschaltete System nachrichten (ausgehend von BizTalk Server) nicht schnell genug empfangen kann. Daher befinden sich die Nachrichten weiterhin im BizTalk-System, was zu einer Zunahme der Anwendungswarteschlange führt. Dies kann dazu führen, dass die Drosselung gestartet wird und die Empfangsrate verringert wird, was sich auf den Gesamtdurchsatz des Systems auswirkt.

Wachstum der TrackingData-Tabelle

Die Tabelle TrackingData in der MessageBox-Datenbank ist eine Übergangstabelle, in die Interceptors Nachverfolgungsdaten sowohl für die Hat- (Health and Activity Monitoring) als auch für die Bam-Überwachung (Business Activity Monitoring) schreiben. Wenn die Überwachung deaktiviert ist, sollte diese Tabelle leer sein. Standardmäßig ist die HAT-Nachverfolgung für die In/Out-Ereignisse für Pipelines und Orchestrierungen aktiviert.

Wenn die Nachrichtenkörpernachverfolgung aktiviert ist, stellen Sie sicher, dass der MessageBox-Datenbankserver (d. h. der Host mit "Hostnachverfolgung zulassen") ausgeführt wird. Wenn Sie sicherstellen, dass der Host mit "Hostnachverfolgung zulassen" ausgeführt wird, verringert sich die Wahrscheinlichkeit eines Engpasses, wenn der Host Daten aus der TrackingData-Tabelle in der MessageBox-Datenbank in die BizTalk Tracking-Datenbanktabellen verschiebt.

Es ist möglich, benutzerdefinierte Ereignisse nachzuverfolgen, indem sie benutzerdefinierte HAT-Tracking aktivieren, z. B. für höhergestufte Eigenschaften und die Nachrichtentextnachverfolgung. Zusätzlich zu HAT-Tracking-Daten werden BAM-Daten auch in die Tabelle TrackingData geschrieben. Der Tracking Data Decode Service (TDDS, der auf dem Host instance ausgeführt wird, auf dem die Nachverfolgung aktiviert ist) ist für das Verschieben dieser Daten aus der MessageBox-Datenbank in die BizTalk-Nachverfolgungs- und BAM-Primärimportdatenbanken verantwortlich. Nachdem die Daten erfolgreich verschoben wurden, löscht TDDS diese Daten. Nachrichtentextüberwachungsdaten werden mithilfe des SQL Agent-Auftrags TrackedMessages_Copy_BizTalkMsgBoxDb separat verschoben.

Wenn TDDS nicht mit der Rate mithalten kann, mit der die Interceptors Daten in die TrackingData-Tabelle schreiben, wird diese Tabelle größer, sodass die Drosselung gestartet wird. Dies wirkt sich auf den nachhaltigen Durchsatz aus. Um dieses Problem zu beheben, stellen Sie sicher, dass mindestens ein Host mit aktivierter Nachverfolgung ausgeführt wird.

Wenn die Daten weiterhin aufgebaut werden, stellen Sie sicher, dass die BizTalk-Nachverfolgungsdatenbank nicht außer Kontrolle wächst. Stellen Sie außerdem sicher, dass der Archivierungs- und Löschauftrag ausgeführt wird und mit der Geschwindigkeit, mit der Daten eintreffen, Schritt halten kann.

Hinweis

Standardmäßig kann der Löschauftrag keine Daten aus den BizTalk Tracking-Datenbanktabellen löschen, bis diese Daten archiviert wurden. Wenn Sie die Nachverfolgungsdaten nicht archivieren müssen, können Sie den Auftrag ändern, um die BizTalk-Überwachungsdatenbank ohne Archivierung zu bereinigen, indem Sie die Schritte unter Löschen von Daten aus der BizTalk-Nachverfolgungsdatenbank (https://go.microsoft.com/fwlink/?LinkID=153817) ausführen.

Weitere Informationen

Engpässe auf der Datenbankebene