Freigeben über

Verwalten und Beheben von BizTalk Server-Datenbanken

  • Artikel

Dieser Artikel enthält ausführliche Informationen zum Verwalten und Beheben von BizTalk Server-Datenbanken.

Originalproduktversion: BizTalk Server-Datenbanken
Ursprüngliche KB-Nummer: 952555

Übersicht

Die Integrität der Microsoft BizTalk Server-Datenbanken ist für eine erfolgreiche BizTalk Server-Messagingumgebung wichtig. In diesem Artikel werden wichtige Punkte erläutert, die Sie beim Arbeiten mit BizTalk Server-Datenbanken berücksichtigen sollten. Diese Überlegungen umfassen Folgendes:

  • Sie müssen die Optionen und auto create statistics DIE auto update statistics SQL Server-Optionen deaktivieren.
  • Sie müssen die max degree of parallelism Option (MAXDOP) richtig festlegen.
  • Bestimmen Sie, wann Sie BizTalk Server-Indizes neu erstellen können.
  • Sperren, Deadlocking oder Blockierung können auftreten.
  • Möglicherweise treten Probleme mit großen Datenbanken oder Tabellen auf.
  • BizTalk SQL Server-Agent Aufträge.
  • Dienstinstanzen können angehalten werden.
  • Möglicherweise treten SQL Server- und BizTalk Server-Leistungsprobleme auf.
  • Sie sollten bewährte Methoden in BizTalk Server befolgen.

Einführung

In diesem Artikel wird beschrieben, wie BizTalk Server-Datenbanken verwaltet werden und wie Sie BizTalk Server-Datenbankprobleme beheben.

Sie müssen die Optionen für automatisches Erstellen von Statistiken und automatische Aktualisierungsstatistiken deaktivieren.

Sie müssen die auto create statistics in der BizTalkMsgBoxDb Datenbank deaktivierten Optionen auto update statistics beibehalten. Führen Sie die folgenden gespeicherten Prozeduren in SQL Server aus, um zu ermitteln, ob diese Einstellungen deaktiviert sind:

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

Sie sollten die aktuelle Einstellung auf off. Wenn diese Einstellung auf " on, deaktivieren Sie sie, indem Sie die folgenden gespeicherten Prozeduren in SQL Server ausführen:

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

Sie müssen die Max Degree of Parallelism-Eigenschaft richtig festlegen.

Legen Sie auf dem Computer, auf dem SQL Server ausgeführt wird und die BizTalkMsgBoxDb Datenbank hostet, den maximalen Grad an Parallelität run_value und config_value Eigenschaften auf den Wert 1 fest. In späteren SQL-Versionen ist es auch möglich, diese Einstellung pro Datenbank anstelle pro SQL-Instanz anzugeben. Weitere Informationen finden Sie unter "MAXDOP festlegen". Führen Sie zum Ermitteln der max degree of parallelism Einstellung die folgende gespeicherte Prozedur für die Masterdatenbank in SQL Server aus:

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

Wenn die run_value Eigenschaften config_value nicht auf einen Wert von 1 festgelegt sind, führen Sie die folgende gespeicherte Prozedur in SQL Server aus, um sie auf 1 festzulegen:

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

Ermitteln, wann BizTalk Server-Indizes neu erstellt werden können

Die meisten BizTalk Server-Indizes sind gruppiert (Index-ID: 1). Mit der DBCC SHOWCONTIG SQL Server-Anweisung können Sie Fragmentierungsinformationen für die BizTalk Server-Tabellen anzeigen.

Die BizTalk Server-Indizes sind GUID-basiert. Daher tritt die Fragmentierung in der Regel auf. Wenn der scan density-Wert, der von der DBCC SHOWCONTIG Anweisung zurückgegeben wird, kleiner als 30 Prozent ist, können die BizTalk Server-Indizes während der Ausfallzeit neu erstellt werden.

Viele BizTalk Server-Tabellen enthalten Spalten, die Definitionen verwenden DataType . Die Onlineindizierung kann in diesen Spalten nicht ausgeführt werden. Daher sollten Sie die BizTalk Server-Indizes niemals neu erstellen, während BizTalk Server Daten verarbeitet.

Sperren, Deadlocking oder Blockierung können auftreten

In der Regel treten Sperren und Blöcke in einer BizTalk Server-Umgebung auf. Diese Sperren oder Blöcke bleiben jedoch nicht länger. Aus diesem Grund deuten Blockierung und Deadlocking auf ein potenzielles Problem hin.

Möglicherweise treten Probleme mit großen Datenbanken oder Tabellen auf

Wir haben gesehen, dass leistungsprobleme auftreten können, wenn die BizTalkMsgBoxDb Datenbank größer ist. Im Idealfall sollte die BizTalkMsgBoxDb Datenbank keine Daten enthalten. Die BizTalkMsgBoxDb Datenbank sollte als Puffer betrachtet werden, bis die Daten verarbeitet oder in die BizTalkDTADb Datenbank oder die BAM-Datenbank verschoben werden.

Eine Umgebung, die einen leistungsfähigen SQL Server im Back-End verwendet, und viele lange Ausgeführte Orchestrierungen verfügen möglicherweise über eine BizTalkMsgBoxDb Datenbank, die größer als 5 GB ist. Eine Umgebung mit hohem Volumen, die keine langen Orchestrierungen verwendet, sollte über eine BizTalkMsgBoxDb Datenbank verfügen, die viel kleiner als 5 GB ist.

Die BizTalkDTADb Datenbank verfügt nicht über eine festgelegte Größe. Wenn die Leistung jedoch verringert wird, ist die Datenbank wahrscheinlich zu groß. Für einige Kunden kann 20 GB als zu groß betrachtet werden, während für andere mit 200 GB möglicherweise mit einem stark starken SQL-Server, der auf mehreren CPUs ausgeführt wird, viel Arbeitsspeicher und einem schnellen Netzwerk und Speicher funktioniert. Wenn Sie über große BizTalk Server-Datenbanken verfügen, treten möglicherweise die folgenden Probleme auf:

  • Die BizTalkMsgBoxDb Datenbank nimmt weiter zu. Die Protokolldatei und die Datengröße bleiben jedoch groß.

  • BizTalk Server dauert länger als üblich, um sogar ein einfaches Nachrichtenflussszenario zu verarbeiten.

  • BizTalk-Administratorkonsole oder HAT-Abfragen (Health and Activity Tracking) dauern länger als üblich und können zeitüberschreitungen.

  • Die Datenbankprotokolldatei wird nie abgeschnitten.

  • Die BizTalk-SQL Server-Agent Aufträge werden langsamer ausgeführt als üblich.

  • Einige Tabellen sind größer oder weisen im Vergleich zur üblichen Tabellengröße zu viele Zeilen auf.

Datenbanken können aus verschiedenen Gründen groß werden. Diese Gründe können Folgendes umfassen:

  • BizTalk SQL Server-Agent Aufträge werden nicht ausgeführt
  • Große Anzahl an angehaltenen Instanzen
  • Datenträgerfehler
  • Nachverfolgung
  • Drosselung
  • SQL Server-Leistung
  • Netzwerklatenz

Stellen Sie sicher, dass Sie wissen, was in Ihrer Umgebung erwartet wird, um festzustellen, ob ein Datenproblem auftritt.

Standardmäßig ist die Nachverfolgung auf dem Standardhost aktiviert. BizTalk erfordert, dass die Option "Hostverfolgung zulassen" auf einem einzelnen Host überprüft wird. Wenn die Nachverfolgung aktiviert ist, verschiebt der Tracking Data Decode Service (TDDS) die Tracking-Ereignisdaten aus der BizTalkMsgBoxDb Datenbank in die BizTalkDTADb Datenbank. Wenn der Nachverfolgungshost beendet wird, werden die Daten nicht von TDDS in die BizTalkDTADb Datenbank verschoben, und die TrackingData_x_x Tabellen in der BizTalkMsgBoxDb Datenbank werden vergrößert.

Es wird empfohlen, einen Host für die Nachverfolgung zu verwenden. Damit TDDS neue Nachverfolgungsereignisse in Szenarien mit hohem Volumen verwalten kann, erstellen Sie mehrere Instanzen eines einzelnen Trackinghosts. Es sollte nicht mehr als ein Tracking-Host vorhanden sein.

Es kann zu viele Zeilen in einer Tabelle geben. Es gibt keine festgelegte Anzahl von Zeilen, die zu viele sind. Darüber hinaus variiert diese Anzahl von Zeilen je nach Art von Daten, die in der Tabelle gespeichert sind. Beispielsweise hat eine dta_DebugTrace Tabelle mit mehr als 1 Millionen Zeilen wahrscheinlich zu viele Zeilen. Eine <HostName>Q_Suspended Tabelle mit mehr als 200.000 Zeilen weist wahrscheinlich zu viele Zeilen auf.

Verwenden der richtigen BizTalk-SQL Server-Agent Aufträge

Die BizTalk-SQL Server-Agent-Aufträge sind wichtig für die Verwaltung der BizTalk Server-Datenbanken und für die Aufrechterhaltung hoher Leistung.

Der Sicherungs-BizTalk Server-SQL Server-Agent Auftrag ist die einzige unterstützte Methode, um die BizTalk Server-Datenbanken zu sichern, wenn SQL Server-Agent und die BizTalkServer-Hostinstanzen gestartet werden. Für diesen Auftrag müssen alle BizTalk Server-Datenbanken ein vollständiges Wiederherstellungsmodell verwenden. Sie sollten diesen Auftrag für eine fehlerfreie BizTalk Server-Umgebung konfigurieren. Die SQL Server-Methoden können verwendet werden, um die BizTalk Server-Datenbanken nur dann zu sichern, wenn SQL Server-Agent beendet wird und alle BizTalk Server-Hostinstanzen beendet werden.

Der MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server-Agent Auftrag wird unendlich ausgeführt. Daher zeigt der SQL Server-Agent Auftragsverlauf niemals einen erfolgreichen Abschluss an. Wenn ein Fehler auftritt, wird der Auftrag innerhalb einer Minute neu gestartet und wird unbegrenzt ausgeführt. Daher können Sie den Fehler sicher ignorieren. Darüber hinaus kann der Auftragsverlauf gelöscht werden. Sie sollten nur besorgt sein, wenn die Auftragshistorie meldet, dass dieser Auftrag ständig fehlschlägt und neu gestartet wird.

Der MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server-Agent Auftrag ist der einzige BizTalk Server-Auftrag, der nicht aktiviert werden sollte, da er vom MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server-Agent Auftrag gestartet wird.

Der DTA-Lösch- und Archiv-SQL Server-Agent Auftrag trägt dazu bei, die BizTalkDTADb Datenbank zu verwalten, indem nachverfolgte Nachrichten gelöscht und archiviert werden. Dieser Auftrag liest jede Zeile in der Tabelle und vergleicht den Zeitstempel, um zu bestimmen, ob der Datensatz entfernt werden soll.

Alle BizTalk-SQL Server-Agent Aufträge mit Ausnahme des MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server-Agent Auftrags sollten erfolgreich ausgeführt werden.

Dienstinstanzen können angehalten werden.

Dienstinstanzen können angehalten (resumierbar) oder angehalten werden (nicht resumierbar). Diese Dienstinstanzen können Messaging, Orchestration oder Port sein.

Diese Dienstinstanzen können dazu führen, dass die BizTalkMsgBoxDb Datenbank unnötig vergrößert und beendet werden kann. Sie können den Gruppenhub verwenden, um Nachrichten abzufragen, fortzusetzen oder zu beenden. Sie können auch das Skript Terminate.vbs oder BizTalk-Systemüberwachung (BHM) verwenden, um BizTalk-Datenbanken abzufragen, zu löschen und zu verwalten. In manchen Situationen kann es verwaiste oder Zombie-Nachrichten geben, die im System verbleiben. Das BHM-Tool kann dazu beitragen, diese Situationen zu korrigieren.

Weitere Informationen zum Skript "Terminate.vbs " finden Sie unter Entfernen von Angehaltenen Dienstinstanzen.

Zwischenspeicherungsinstanzen werden nicht auf der Seite " Gruppenhub " angezeigt, und Sie können sie nicht anhalten oder beenden. Diese Einschränkung ist eine häufige Ursache für das Tabellenwachstum. Um neue Zombie-Nachrichten für die Cachedienstinstanzen in BizTalk Server 2006 zu verhindern, installieren Sie den Hotfix im Microsoft Knowledge Base-Artikel 936536. Dieses Problem wurde in BizTalk Server 2006 R2 und höheren Versionen behoben.

Notiz

Eine Zombie-Nachricht ist eine Nachricht, die weitergeleitet, aber nicht verbraucht wurde.

Eine Beschreibung der Zombie-Nachrichten finden Sie auf der folgenden MSDN-Website: BizTalk Core Engines WebLog

Möglicherweise treten SQL Server- und BizTalk Server-Leistungsprobleme auf

BizTalk Server macht Hunderte von kurzen, schnellen Transaktionen innerhalb einer Minute an SQL Server. Wenn diese Aktivität vom SQL Server nicht unterstützt werden kann, treten möglicherweise Leistungsprobleme auf. Überwachen Sie in Leistungsmonitor die Durchschn. Datenträger sec/Read, Avg. Disk sec/Transfer und Avg. Disk sec/Write Leistungsmonitor counters in the PhysicalDisk performance object. Der optimale Wert ist kleiner als 10 ms (Millisekunden). Ein Wert von 20 ms oder größer gilt als schlechte Leistung.

Bewährte Methoden in BizTalk Server

Starten Sie SQL Server-Agent auf dem SQL Server. Wenn der SQL Server-Agent beendet wird, können die integrierten BizTalk-SQL Server-Agent Aufträge, die für die Datenbankwartung verantwortlich sind, nicht ausgeführt werden. Dieses Verhalten verursacht datenbankwachstum, und dieses Wachstum kann Leistungsprobleme verursachen.

Platzieren Sie die SQL Server-Protokolldateidateien (LDF) und die MDF-Dateien (Main Database File) auf separaten Laufwerken. Wenn sich die LDF- und MDF-Dateien für die BizTalkMsgBoxDb und BizTalkDTADb Datenbanken auf demselben Laufwerk befinden, kann die Datenträgerkonfliktion auftreten.

Wenn Sie nicht von der Nachrichtentextverfolgung profitieren, aktivieren Sie dieses Feature nicht. Es ist jedoch ratsam, die Nachrichtentextverfolgung zu aktivieren, während Sie eine Lösung entwickeln und beheben. Wenn Sie dies tun, stellen Sie sicher, dass Sie die Nachrichtentextverfolgung deaktivieren, wenn Sie fertig sind. Wenn die Nachrichtentextverfolgung aktiviert ist, werden die BizTalk Server-Datenbanken vergrößert. Wenn ein Geschäftlicher Bedarf besteht, der das Aktivieren der Nachrichtentextverfolgung erfordert, vergewissern Sie sich, dass die TrackedMessages_Copy_BizTalkMsgBoxDb Aufträge "Löschen" und "Archivieren" und SQL Server-Agent "Archivieren" erfolgreich ausgeführt werden.

In der Regel führen kleinere Transaktionsprotokolle zu einer besseren Leistung. Um die Transaktionsprotokolle kleiner zu halten, konfigurieren Sie den Sicherungs-BizTalk Server-SQL Server-Agent Auftrag so, dass er häufiger ausgeführt wird.

Die sp_ForceFullBackup gespeicherte Prozedur in der BizTalkMgmtDb Datenbank kann auch verwendet werden, um eine ad-hoc vollständige Sicherung der Daten und Protokolldateien durchzuführen. Die gespeicherte Prozedur aktualisiert die adm_ForceFullBackup Tabelle mit dem Wert 1. Wenn der Sicherungs-BizTalk Server-Auftrag das nächste Mal ausgeführt wird, wird ein vollständiger Datenbanksicherungssatz erstellt.

BizTalk-Systemüberwachung (BHM)-Tool kann verwendet werden, um eine vorhandene BizTalk Server-Bereitstellung auszuwerten. BHM führt zahlreiche datenbankbezogene Prüfungen durch.

Problembehandlung

Die besten Schritte zur Problembehandlung für die SQL Server-Datenbanken von BizTalk Server hängen von der Art des Datenbankproblems ab, z. B. Blockieren oder Deadlocking. Führen Sie die folgenden Schritte aus, um ein BizTalk Server-Datenbankproblem zu beheben.

Schritt 1: Aktivieren und Ausführen aller erforderlichen BizTalk-SQL Server-Agent Aufträge

Alle BizTalk-SQL Server-Agent Aufträge mit Ausnahme des MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb Auftrags sollten aktiviert und erfolgreich ausgeführt werden. Deaktivieren Sie keinen anderen Auftrag.

Wenn ein Fehler auftritt, verwenden Sie die Option "Verlauf anzeigen" in SQL Server, um die Fehlerinformationen anzuzeigen, und beheben Sie dann den Fehler entsprechend. Denken Sie daran, dass der MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server-Agent Auftrag unendlich ausgeführt wird. Daher sollten Sie nur besorgt sein, wenn die Auftragshistorie meldet, dass der Auftrag ständig fehlschlägt und neu gestartet wird.

Schritt 2: Verwenden des Tools BizTalk-Systemüberwachung (BHM)/MsgBoxViewer

Sammeln Sie den BHM-Bericht, während Sie ein Problem reproduzieren.

Das BHM-Tool ist nützlich für die Problembehandlung, da es einen HTML-Bericht mit detaillierten Informationen zu Tabellengrößen und der Zeilenanzahl bereitstellt. Der Bericht kann auch helfen, zu bestimmen, ob BizTalk Server eingeschränkt ist. Darüber hinaus stellt das Tool eine Momentaufnahmeansicht der BizTalk Server-Datenbanken und der BizTalk Server-Konfiguration bereit.

Weitere Informationen zur Einschränkung in BizTalk Server finden Sie unter How BizTalk Server Implements Host Throttling.

Wenn BizTalk Server langsamer als üblich ausgeführt wird, führen Sie das BHM-Tool aus, und überprüfen Sie dann den generierten HTML-Bericht auf probleme. Im Abschnitt "Zusammenfassung " werden Warnungen in Gelb und potenziellen Problemen rot aufgelistet.

Darüber hinaus können Sie die BHM-Toolausgabe verwenden, um zu bestimmen, welche Tabellen am größten sind und über die meisten Datensätze verfügen. In der folgenden Tabelle sind die BizTalk Server-Tabellen aufgeführt, die in der Regel am größten wachsen. Sie können diese Daten verwenden, um zu bestimmen, wo ein potenzielles Problem auftreten kann.

Tabelle Beschreibung
<HostName>Q_Suspended Diese Tabelle enthält einen Verweis auf Nachrichten in der Spool Tabelle, die mit angehaltenen Instanzen für den jeweiligen Host verknüpft sind. Diese Tabelle befindet sich in der BizTalkMsgBoxDb Datenbank.
<HostName>Q Diese Tabelle enthält einen Verweis auf Nachrichten in der Spool Tabelle, die dem jeweiligen Host zugeordnet sind und nicht angehalten werden. Diese Tabelle befindet sich in der BizTalkMsgBoxDb Datenbank.
Spool

Parts

Fragments		 In diesen Tabellen werden tatsächliche Nachrichtendaten in der BizTalkMsgBoxDb Datenbank gespeichert.
Instances In dieser Tabelle werden alle Instanzen und deren aktueller Status in der BizTalkMsgBoxDb Datenbank gespeichert.
TrackingData_0_x In diesen vier Tabellen werden die nachverfolgten Ereignisse der Business Activity Monitoring (BAM) in der BizTalkMsgBoxDb Datenbank für TDDS gespeichert, um die Ereignisse in die BAMPrimaryImport Datenbank zu verschieben.
TrackingData_1_x Diese vier Tabellen speichern die nachverfolgten Ereignisse in der BizTalkMsgBoxDb Datenbank für TDDS, um die Ereignisse in die BizTalkDTADB Datenbank zu verschieben.
Tracking_Fragmentsx
Tracking_Partsx
Tracking_Spoolx		 Zwei dieser Tabellen sind in den BizTalkMsgBoxDb Datenbanken enthalten BizTalkDTADb . Eine ist online, und die andere ist offline.

In BizTalk Server 2004 SP2 und höheren Versionen verschiebt der TrackedMessages_Copy_BizTalkMsgBoxDb SQL Server-Agent Auftrag nachverfolgte Nachrichtentexte direkt in diese Tabellen in der BizTalkDTADb Datenbank.

In BizTalk Server 2004 Service Pack 1 (SP1) und in früheren Versionen von BizTalk Server 2004 kopiert der TrackedMessages_Copy_BizTalkMsgBoxDb SQL Server-Agent Auftrag nachverfolgte Nachrichtentexte in diese Tabellen in der BizTalkMsgBoxDb Datenbank. Der TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server-Agent Auftrag löscht die Offlinetabellen und macht die Tabellen online, während der Auftrag auch die Onlinetabellen offline nimmt.
dta_ServiceInstances In dieser Tabelle werden nachverfolgte Ereignisse für Dienstinstanzen in der BizTalkDTADb Datenbank gespeichert. Wenn diese Tabelle groß ist, ist die BizTalkDTADb Datenbank wahrscheinlich groß.
dta_DebugTrace In dieser Tabelle werden die Orchestration-Debuggerereignisse in der BizTalkDTADb-Datenbank gespeichert.
dta_MessageInOutEvents In dieser Tabelle werden nachverfolgte Ereignismeldungen in der BizTalkDTADb Datenbank gespeichert. Diese nachverfolgten Ereignismeldungen enthalten Nachrichtenkontextinformationen.
dta_ServiceInstanceExceptions In dieser Tabelle werden Fehlerinformationen für alle angehaltenen Dienstinstanzen in der BizTalkDTADb Datenbank gespeichert.

Betrachten Sie folgende Szenarien:

  • <HostName>Q_Suspended Tabellen

    Wenn die <HostName>Q_Suspended Tabellen viele Datensätze enthalten, können die Tabellen gültige angehaltene Instanzen sein, die im Group Hub oder in HAT angezeigt werden. Diese Instanzen können beendet werden. Wenn diese Instanzen nicht im Group Hub oder in HAT angezeigt werden, werden die Instanzen wahrscheinlich Instanzen zwischenspeichern oder verwaiste Routingfehlerberichte. Wenn angehaltene Instanzen beendet werden, werden die Elemente in dieser Tabelle und die zugehörigen Zeilen in den Spool und Instances Tabellen bereinigt.

    Behandeln Sie in diesem Szenario die angehaltenen Instanzen, indem Sie sie fortsetzen oder beenden. Das BHM-Tool kann auch verwendet werden.

  • <HostName>Q Tabellen

    Wenn die <HostName>Q Tabellen viele Datensätze enthalten, können die folgenden Arten von Instanzen vorhanden sein:

    • Ready-to-Run-Instanzen
    • Aktive Instanzen
    • Dehydratisierte Instanzen benötigt BizTalk Server Zeit, um die Instanzen zu "aufholen" und zu verarbeiten.

    Diese Tabelle kann wachsen, wenn die eingehende Verarbeitungsrate die Ausgehende Verarbeitungsrate übertrifft. Dieses Szenario kann auftreten, wenn ein anderes Problem auftritt, z. B. eine große BizTalkDTADb Datenbank oder SQL Server-Datenträgerverzögerungen.

  • Spool, Partsund Fragments Tabellen

    Wenn die Spool, Partsund Fragments Tabellen viele Datensätze aufweisen, sind viele Nachrichten derzeit aktiv, dehydratisiert oder angehalten. Abhängig von der Größe, der Anzahl der Teile und den Fragmentierungseinstellungen in diesen Tabellen kann eine einzelne Nachricht alle diese Tabellen enthalten. Jede Nachricht enthält genau eine Zeile in der Spool Tabelle und mindestens eine Zeile in der Parts Tabelle.

  • Instances Tabelle

    Der BizTalk-Administrator sollte nicht zulassen, dass viele angehaltene Instanzen in der Instances Tabelle verbleiben. Dehydratisierte Instanzen sollten nur beibehalten werden, wenn geschäftslogik langfristige Orchestrierungen erfordert. Denken Sie daran, dass eine Dienstinstanz vielen Nachrichten in der Spool Tabelle zugeordnet werden kann.

  • TrackingData_x_x Tabellen

    Wenn die TrackingData_x_x Tabellen groß sind, wird der Tracking-Host (TDDS) nicht erfolgreich ausgeführt. Wenn die Tracking-Hostinstanz ausgeführt wird, überprüfen Sie die Ereignisprotokolle und die TDDS_FailedTrackingData Tabelle in der BizTalkDTADb Datenbank auf Fehlerinformationen. Wenn BizTalk mit dem Status 6 (große Datenbank) eingeschränkt wird, können diese Tabellen auch mithilfe des BizTalk-Terminator-Tools abgeschnitten werden, wenn keine Daten erforderlich sind.

    Wenn zwischen den Sequenznummern in den Tabellen und den BizTalkMsgBoxDb TrackingData_x_x BizTalkDTADb BAMPrimaryImport TDDS_StreamStatus Tabellen eine große Lücke besteht, werden die Daten von TDDS möglicherweise nicht aus der BizTalkMsgBoxDb Datenbank verschoben. Um dies zu korrigieren, verwenden Sie das BHM-Tool, um diese Tabellen zu löschen und die Sequenznummer zurückzusetzen.

  • dta_DebugTrace und dta_MessageInOutEvents Tabellen

    Die dta_DebugTrace Tabelle wird aufgefüllt, wenn der Shape-Anfang und das Ende in einer Orchestrierung aktiviert sind. Wenn die dta_DebugTrace Tabelle viele Datensätze enthält, werden diese Orchestrierungsdebuggingereignisse verwendet oder verwendet. Wenn für reguläre Vorgänge kein Orchestrierungsdebugging erforderlich ist, deaktivieren Sie das Kontrollkästchen "Shape-Start" und "End " in den Eigenschaften "Orchestration" .

    Die dta_MessageInOutEvents Tabelle wird aufgefüllt, wenn das Senden und Empfangen von Nachrichten in Orchestrierungen und/oder Pipelines aktiviert ist. Wenn diese Nachverfolgungsereignisse nicht benötigt werden, deaktivieren Sie das Kontrollkästchen für diese Option in den Orchestrierungs- und/oder Pipelineeigenschaften.

    Wenn diese Ablaufverfolgungsereignisse deaktiviert sind oder ein Backlog in der BizTalkMsgBoxDb Datenbank vorhanden ist, werden diese Tabellen möglicherweise weiter vergrößert, da TDDS diese Daten weiterhin in diese Tabellen verschoben.

    Standardmäßig ist die globale Nachverfolgung aktiviert. Wenn die globale Nachverfolgung nicht erforderlich ist, kann sie deaktiviert werden. Weitere Informationen finden Sie unter "Deaktivieren der globalen Nachverfolgung".

    Wenn die dta_DebugTrace Tabelle und/oder die dta_messageInOutEvents Tabelle in der BizTalkDTADb Datenbank zu groß sind, können Sie die Tabellen manuell abschneiden, nachdem Sie den Nachverfolgungshost beendet haben. Das BHM-Tool bietet auch diese Funktionalität.

    Wenn Sie alle Nachverfolgungstabellen in der BizTalkMsgBoxDb Datenbank abschneiden möchten, verwenden Sie das BHM-Tool. Das BHM-Tool ist extern im Microsoft Download Center verfügbar.

    Weitere Informationen zum Nachverfolgen von Richtlinien für die Größenanpassung von Datenbanken finden Sie auf der folgenden MSDN-Website: Richtlinien für die Nachverfolgung von Datenbankanpassungen.

  • dta_ServiceInstanceExceptions Tabelle

    Die dta_ServiceInstanceExceptions Tabelle wird in der Regel in einer Umgebung groß, in der regelmäßig Angehaltene Instanzen vorhanden sind.

Schritt 3: Untersuchen von Deadlock-Szenarien

Aktivieren Sie in einem Deadlock-Szenario die DBCC-Ablaufverfolgung auf dem SQL Server, sodass die Deadlock-Informationen in das SQLERROR-Protokoll geschrieben werden.

Führen Sie in SQL Server 2005 und höheren Versionen die folgende Anweisung aus:

DBCC TRACEON (1222,-1)

Führen Sie in SQL Server 2000 die folgende Anweisung aus:

DBCC TRACEON (1204)

Verwenden Sie außerdem das PSSDiag-Hilfsprogramm, um Daten zu dem Lock:Deadlock Ereignis und dem Lock:Deadlock Chain-Ereignis zu sammeln.

Die BizTalkMsgBoxDB Datenbank ist eine Datenbank mit hohem Volumen und einer Oltp-Datenbank mit hoher Transaktion. Einige Deadlocking wird erwartet, und diese Deadlocking wird intern vom BizTalk Server-Modul behandelt. Wenn dieses Verhalten auftritt, werden in den Fehlerprotokollen keine Fehler aufgelistet. Wenn Sie ein Deadlock-Szenario untersuchen, muss das in der Ausgabe untersuchte Deadlock mit einem Deadlock-Fehler in den Ereignisprotokollen korreliert werden.

Der Befehl "Dequeue" und einige SQL Server-Agent Aufträge werden als Deadlock erwartet. In der Regel werden diese Aufträge als Deadlock-Opfer ausgewählt. Diese Aufträge werden in einer Deadlock-Ablaufverfolgung angezeigt. In den Ereignisprotokollen werden jedoch keine Fehler aufgeführt. Daher wird diese Deadlocking erwartet, und Sie können die Deadlocking mit diesen Aufträgen sicher ignorieren.

Wenn häufige Deadlocks in einer Deadlock-Ablaufverfolgung angezeigt werden und ein korrelierender Fehler in den Ereignisprotokollen aufgeführt ist, möchten Sie möglicherweise das Deadlock.

Schritt 4: Suchen nach blockierten Prozessen

Verwenden Sie den Aktivitätsmonitor in SQL Server, um den Serverprozessbezeichner (SPID) eines Sperrsystemprozesses abzurufen. Führen Sie dann SQL Profiler aus, um die SQL-Anweisung zu bestimmen, die in der sperrenden SPID ausgeführt wird.

Um ein Sperr- und Blockierungsproblem in SQL Server zu beheben, verwenden Sie das PSSDiag für SQL-Hilfsprogramm, um alle Transact-SQL-Ereignisse zu erfassen, die das blockierende Skript aktiviert haben.

In SQL Server 2005 und höheren Versionen können Sie die Einstellung für blockierte Prozessschwellenwerte angeben, um zu bestimmen, welche SPID- oder SPIDs länger als der von Ihnen angegebene Schwellenwert blockieren.

Weitere Informationen zur Einstellung des blockierten Prozessschwellenwerts finden Sie unter der Option für die Serverkonfiguration für blockierte Prozesse.

Notiz

Wenn ein Sperr- oder Blockierungsproblem in SQL Server aufgetreten ist, wird empfohlen, dass Sie sich an den Microsoft-Kundendienst wenden. Microsoft-Kundendienstdienste können Ihnen helfen, die richtigen PSSDiag-Hilfsprogramme zu konfigurieren.

Schritt 5: Installieren des neuesten BizTalk Server Service Pack und kumulatives Update

BizTalk Server neuere Versionen wurden in ein kumulatives Updatemodell (CU) verschoben. Die kumulativen Updates enthalten die neuesten Fixes.

Alle Daten löschen

Wenn die Datenbanken zu groß sind oder die bevorzugte Methode zum Löschen aller Daten dient, können alle Daten gelöscht werden.

Achtung

Verwenden Sie diese Methode nicht in einer Umgebung, in der die Daten geschäftskritisch sind oder wenn die Daten benötigt werden.

Schritte zum Löschen von BizTalkMsgBoxDb-Datenbanken

Verwenden Sie das Tool BizTalk-Systemüberwachung (BHM), um alle Daten in der BizTalkMsgBoxDb Datenbank zu löschen.

BizTalkDTADb-Datenbanklöschoptionen

Verwenden Sie das Tool BizTalk-Systemüberwachung (BHM), um alle Daten aus der BizTalkDTADb Datenbank zu löschen. Verwenden Sie andernfalls eine der folgenden Methoden.

Notiz

Während beide Methoden alle Nachrichten löschen, ist Methode 2 schneller.

  • Methode 1:

    1. Sichern Sie alle BizTalk Server-Datenbanken.

    2. Führen Sie die gespeicherte dtasp_PurgeAllCompletedTrackingData Prozedur aus. Weitere Informationen zur dtasp_PurgeAllCompletedTrackingData gespeicherten Prozedur finden Sie unter Manuelles Löschen von Daten aus der BizTalk Tracking-Datenbank.

      Notiz

      Diese Aktion löscht alle abgeschlossenen Nachrichten.

  • Methode 2:

    1. Sichern Sie alle BizTalk-Datenbanken.

    2. Führen Sie die gespeicherte dtasp_CleanHMData Prozedur aus. Verwenden Sie diese Option nur, wenn die BizTalkDTADb Datenbank viele unvollständige Instanzen enthält, die entfernt werden müssen.

      Gehen Sie dazu wie folgt vor:

      1. Beenden Sie alle BizTalk-Hosts, -Dienste und benutzerdefinierten isolierten Adapter. Wenn Sie HTTP oder den SOAP-Adapter verwenden, starten Sie die IIS-Dienste neu.
      2. Führen Sie die dtasp_CleanHMData gespeicherte Prozedur in der BizTalkDTADb Datenbank aus.
      3. Starten Sie alle Hosts und BizTalk Server-Dienste neu.

Nur BizTalk Server 2004-Schritte

Notiz

Wenn Sie über die Nachverfolgungsdaten verfügen müssen, sichern Sie die BizTalkDTADb Datenbank, stellen Sie die Datenbank auf einem anderen SQL Server wieder her, und löschen Sie dann die ursprüngliche BizTalkDTADb Datenbank.

Wenn Sie Hilfe zum Analysieren der BHM-Daten oder der PSSDiag-Ausgabe benötigen, wenden Sie sich an den Microsoft-Kundendienst. Eine vollständige Liste der Telefonnummern und Informationen zu Supportkosten finden Sie unter Kontakt Microsoft-Support.

Notiz

Bevor Sie sich an den Kundendienst wenden, komprimieren Sie die BHM-Berichtsdaten, die PSSDiag-Ausgabe und die aktualisierten Ereignisprotokolle (EVT-Dateien). Möglicherweise müssen Sie diese Dateien an einen Supporttechniker von BizTalk Server senden.

Gilt für:

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