Ermitteln von Engpässe in der MessageBox-Datenbank

Um Engpässe der MessageBox-Datenbank zu ermitteln, muss zunächst sichergestellt werden, dass der SQL Server-Agent-Dienst gestartet wurde. Ändern Sie das manuelle Starten des Diensts in ein automatisches Starten. Dadurch wird der Dienst selbst bei einem Neustart des Servers automatisch neu gestartet.

In der Standardeinstellung wird der BizTalk-Dienst, in dem Maße eingeschränkt, in dem die Tabellen Spool, TrackingData oder ApplicationQ an Umfang zunehmen. Diese Tabellen werden von SQL Agent-Aufträgen gelöscht. Wenn diese nicht ausgeführt werden, steigt die Spoolgröße, sodass eine Einschränkung erfolgt, um die Datenbank vor dem zusätzlichen Druck zu schützen. Prüfen Sie den Status der folgenden Leistungsindikatoren:

• BizTalk:Nachrichtenagent (Hostname) Status der Nachrichtenübermittlungseinschränkung

• BizTalk:Nachrichtenagent (Hostname) Status der Nachrichtenveröffentlichungseinschränkung

  Bei einem Wert von 0 erfolgt keine Einschränkung. Der Wert 6 weist darauf hin, dass das System aufgrund der größer werdenden Datenbanken einer Einschränkung unterliegt. Weitere Informationen zu anderen Werten dieser Indikatoren finden Sie in der Dokumentation.

Zunehmender Umfang der Tabelle 'Spool'

Diese Tabelle kann aus verschiedenen Gründen an Umfang zunehmen. Einer der Gründe sind größer werdende Anwendungswarteschlangen. Diese können verschiedene Ursachen haben, beispielsweise Downstreamengpässe und/oder Ressourcenkonflikte.

Wenn bei kleinen Anwendungswarteschlangen ein noch großer Spool vorhanden ist, muss sichergestellt werden, dass die Löschaufträge ordnungsgemäß 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 Tabelle MessageZeroSum sehr umfangreich ist, weist dies darauf hin, dass die Meldungen verarbeitet (DeQueue wurde erfolgreich abgeschlossen und Daten aus den Tabellen vom Typ Anwendungswarteschlangen gelöscht), und dass die Spalten zum Löschen markiert wurden. Mithilfe der Löschaufträge können jedoch nicht ausreichend Daten gelöscht werden. Eine der Ursachen hierfür ist der SQL-Server-Computer, der einem schwerwiegenden CPU-Konflikt unterliegt, der sich auf die Durchführbarkeit der Löschaufträge auswirkt, da auf die CPU nicht zugegriffen werden kann.

Zunehmender Umfang der Tabelle 'Anwendungswarteschlange'

Anwendungswarteschlangen beinhalten In-Process-Übergangsdaten, die im Anschluss an die Verarbeitung mithilfe von DeQueue gelöscht werden.

Im Anschluss an die Verarbeitung der Nachrichten kann der Spool (der Verweise auf diese Spalten beinhaltet) gelöscht werden.

So veröffentlicht beispielsweise RxHostQ Daten an die Orchestrierung PxHostQ, die ihrerseits Daten an TxHostQ veröffentlicht, die jeweils auf eine Spalte der Tabelle Spool verweisen. Wenn die Nachrichten für eine bestimmte HostQ erfolgreich vom System verarbeitet wurden, werden die entsprechenden Spalten mithilfe 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.

Ein Anwachsen der Anwendungswarteschlange weist darauf hin, dass die für den Ausgleich der Warteschlange verantwortlichen Hostinstanzen mit der Eingangsrate (also der Rate, mit der die Nachrichten in der entsprechenden Anwendungswarteschlange veröffentlicht werden) nicht mehr 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 Empfangsserver jedoch schnell ist, wird möglicherweise schneller veröffentlicht als der Orchestrierungsserver verarbeiten kann, sodass die Anwendungswarteschlange wächst.

Eine weitere Ursache für ein Anwachsen der Orchestrierungswarteschlange können Speicherkonflikte sein, bei denen zahlreiche Orchestrierungsinstanzen mit einer langen Laufzeit gleichzeitig im Arbeitsspeicher instanziiert werden. Dadurch entsteht eine Überlastung des Arbeitsspeichers, die indirekt dazu führt, dass der Threadpool durch Einschränkungen verkleinert wird, bis sich die Arbeitsspeicherbelastung verringert hat. Eine Ursache für das Anwachsen der Sende-Anwendungswarteschlange ist ein Downstreamsystem, das (von BizTalk gesendete) Nachrichten nicht schnell genug empfangen kann. Daher verbleiben die Nachrichten im BizTalk-System, sodass die Anwendungswarteschlange größer wird. Dies führt letztlich zu einer Einschränkung der Empfangsrate, die sich auf den Gesamtdurchsatz des Systems auswirkt.

Zunehmender Umfang der Tabelle "TrackingData"

Bei der Tabelle TrackingData der MessageBox-Datenbank handelt es sich um eine Übergangstabelle, in die die Interceptors Überwachungsdaten sowohl für die Nachrichten- und Dienstinstanzüberwachung als auch für die BAM-Überwachung schreiben. Wenn die Überwachung deaktiviert ist, sollte diese Tabelle leer sein. In der Standardeinstellung ist die Nachrichten- und Dienstinstanzüberwachung für die Ein/Aus-Ereignisse von Pipelines und Orchestrierungen aktiviert.

Wenn die Überwachung von Nachrichtentext aktiviert ist, muss sichergestellt werden, dass der MessageBox-Server (also der Host mit Hostüberwachung zulassen) ausgeführt wird. Dieser verhindert Engpässe, da die Daten aus der Tabelle TrackingData in der MessageBox-Datenbank in die Tabellen BizTalkDTADb verschoben werden.

Es ist möglich, benutzerdefinierte Ereignisse nachzuverfolgen, indem benutzerdefinierte Nachrichten- und Dienst-instance Nachverfolgung aktiviert werden, z. B. für höhergestufte Eigenschaften und die Nachrichtentextnachverfolgung. Zusätzlich zu den Überwachungsdaten werden auch BAM-Daten in diese Tabelle geschrieben. TDDS (der Host, auf dem die Überwachung aktiviert wurde) ist für das Verschieben der Daten von der MessageBox-Datenbank in die Tabellen BizTalkDTADb und BAMPrimaryImport und für das anschließende Löschen der Daten verantwortlich. Nachrichtentextüberwachungsdaten werden mithilfe des SQL Agent-Auftrags TrackedMessages_Copy_BizTalkMsgBoxDb separat verschoben.

Wenn TDDS mit der Schreibrate der Interceptors in der Tabelle TrackingData nicht mithalten kann, nimmt diese Tabelle an Umfang zu. Dadurch wird eine Einschränkung ausgelöst, die sich letztlich auf einen nachhaltigen Durchsatz auswirkt. Um dieses Problem zu verringern, muss sichergestellt werden, dass mindestens ein Host ausgeführt wird, auf dem die Überwachung aktiviert ist.

Wenn sich dennoch immer mehr Daten anhäufen, überprüfen Sie die BizTalkDTADb-Datenbank, um sicherzustellen, dass die Datenbank nicht unkontrollierbar weiter wächst. Stellen Sie sicher, dass die Archivierungs- und Löschaufträge ausgeführt werden und die Empfangsrate der Daten bewältigen können.

Hinweis

Mithilfe des Löschauftrags können Daten aus den BizTalkDTADb-Tabellen erst gelöscht werden, nachdem diese Daten archiviert wurden.

Stellen Sie sicher, dass die Tabelle TrackingData nicht an Umfang zunimmt. Stellen Sie sicher, dass auf mindestens einer ausgeführten Hostinstanz die Überwachung aktiviert ist (TDDS). Wenn die BizTalkDTADb-Datenbank zu groß geworden ist, kann sich dies negativ auf die Fähigkeit von TDDS auswirken, Daten von der MessageBox-Datenbank in die BizTalkDTADb-Datenbank zu verschieben.

Ein Anwachsen der Tabelle TrackingData kann zu einer Einschränkung führen, die sich auf einen nachhaltigen Laufzeitdurchsatz auswirkt.