Freigeben über


Vermeiden von DBNETLIB-Ausnahmen

DBNetLib-Fehler (Database Network Library) treten auf, wenn das BizTalk Server-Laufzeitmodul nicht mit den MessageBox- oder Verwaltungsdatenbanken kommunizieren kann. In diesem Fall wird die BizTalk Server-Laufzeitinstanz, durch die die Ausnahme abgefangen wird, heruntergefahren. Sie prüft dann in Abständen von einer Minute, ob die Datenbank wieder verfügbar ist.

Die häufigste Ursache für einen DBNetLib-Fehler besteht darin, dass auf einem der (möglicherweise vielen) MessageBox-Datenbankserver sehr viel Datenverkehr auftritt, wobei ein weiterer Kommunikationsversuch zu einem Timeout führt, was wiederum eine DBNetLib-Ausnahme verursacht.

Neben Fällen, in denen die MessageBox-Datenbank einfach stark ausgelastet ist, können DBNetLib-Fehler auch in einer Produktionsumgebung auftreten, wenn BizTalk-Datenbankserver E/A-gebunden werden, die eine von mehreren MessageBox-Datenbanken hosten.

In diesem Thema werden Bedingungen beschrieben, die DBNetLib-Fehler auslösen können, sowie Empfehlungen dazu, wie diese Fehler vermieden werden können.

Ursache und Behebung des DBNetLib-Fehlers

Symptome eines DBNetLib-Fehlers

Eine Microsoft BizTalk Server-Hostinstanz wird beendet und startet sich selbst neu, wobei folgende und ähnliche Fehler in das BizTalk Server-Anwendungsprotokoll geschrieben werden:

Event Type:Warning  
Event Source:BizTalk Server <version>  
Event Category:BizTalk Server <version>   
Event ID:5410  
Computer:BIZTALKSERVER  
Description:  
An error occurred that requires the BizTalk service to terminate. The most common causes are the following:  
 1) An unexpected out of memory error.  
 OR  
 2) An inability to connect or a loss of connectivity to one of the BizTalk databases.   
 The service will shutdown and auto-restart in 1 minute. If the problematic database remains unavailable, this cycle will repeat.  
  
 Error message: [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation.  
 Error source:    
  
 BizTalk host name: BizTalkHost  
 Windows service name: BTSSvc$BizTalkHost   
  
---------------------------------------------------------  
Event Type:Error  
Event Source:BizTalk Server <version>  
Event Category:BizTalk Server <version>   
Event ID:6913  
Computer:BIZTALKSERVER  
Description:  
An attempt to connect to "BizTalkMsgBoxDb" SQL Server database on server "SQLSERVER " failed.  
 Error: "[DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation."  

BizTalk-Datenbankserver, die MessageBox-Datenbanken hosten, werden E/A-gebunden

BizTalk-Server kommunizieren und arbeiten direkt mit den Datenbankservern, die die MessageBox-Datenbanken hosten. Tritt auf einem der Datenbankserver, die MessageBox-Datenbanken hosten, zu viel Datenverkehr auf, und der Server gerät in eine gebundene E/A-Situation, reagiert er möglicherweise nicht mehr. Einer der BizTalk-Server kann hierdurch seine Verbindung mit einem der Datenbankserver verlieren, sodass ein DBNetLib-Fehler auftritt.

Unsere Tests haben gezeigt, dass ein Datenbankserver mit hohem Datenaufkommen E/A-gebunden wird, wenn die Leerlaufzeit (%) stetig fällt und schließlich 10 % unterschreitet. Wenn dieses Verhalten auftritt, ist das ein Anzeichen dafür, dass Ihr Datenbankserver gefährdet ist, nicht mehr zu reagieren.

Ursache

Es gibt viele Ursachen dafür, dass ein Datenbankserver, der MessageBox-Datenbanken hostet, E/A-gebunden wird. Einige werden im Folgenden beschrieben:

  • Der Datenbankcomputer, von dem die MessageBox-Datenbank gehostet wird, ist durch geringe Hardwarespezifikation beschränkt, z. B. niedriger Arbeitsspeicher, kleine Anzahl und geringe Geschwindigkeit von Prozessoren usw.

  • Die physikalische Festplatte des Datenbankservers, der die MessageBox-Datenbank hostet, wird gemeinsam mit anderen Datenbanken mit hohem Datenaufkommen verwendet. Wenn mehrere Datenbanken (einschließlich der MessageBox) gleichzeitig ein hohes Datenaufkommen verarbeiten müssen, kann auf der physikalischen Festplatte eine gebundene E/A-Situation auftreten.

    Ein Beispiel einer solchen Situation:

    Unsere Tests haben gezeigt, dass die Datenbankserver, die BizTalkDTADb- und/oder BAM-Datenbanken hosten, manchmal einen hohen Prozentsatz der Lese- und Schreibzeiten verbrauchen. Wird die Festplatte des Datenbankservers, der eine MessageBox-Datenbank hostet, gemeinsam von stark beanspruchten Datenbanken wie BizTalkDTADb oder BAM verwendet, und auf beiden Datenbanken tritt gleichzeitig ein hoher Datenverkehr auf, wird die physikalische Festplatte möglicherweise E/A-gebunden und reagiert dann nicht mehr.

  • Wenn die BizTalkDTADb- und eine oder mehrere MessageBox-Datenbanken gemeinsam dieselbe physikalische Festplatte auf dem Datenbankserver verwenden, und die Daten werden nicht regelmäßig archiviert und gelöscht, kann die Festplatte E/A-gebunden werden.

Lösung

Stellen Sie sicher, dass auf den Datenbankservern, die BizTalk MessageBoxes hosten, kein extrem hohes Datenaufkommen entsteht. Andernfalls reagieren die Server möglicherweise nicht mehr.

Nachfolgend wird beschrieben, wie und warum auf Festplatten von Servern zu viel Datenverkehr entsteht. Außerdem finden Sie Empfehlungen dazu, wie Sie dieses Problem beheben können.

Unzureichende Hardwareleistung

Unsere Tests haben gezeigt, dass die Ressourcen eines Servers schneller verbraucht werden, wenn seine Hardwareanforderungen den anfallenden Datenmengen nicht gewachsen sind. In solchen Fällen wird das System schnell durch die Menge an Aktivitäten, die es in den Datenbanken verarbeiten muss, überlastet. Hierbei steigen die Lese- und Schreibzeiten des Servers stetig an ohne sich zu stabilisieren. Dadurch fällt die Leerlaufzeit auf unter 10 %. Dies kann dazu führen, dass Ihr Datenbankserver nicht mehr reagiert.

Je nachdem, wie viele Aktivitäten und wie hoch das Datenaufkommen in Ihrer BizTalk-Bereitstellung ist, sollten Sie bei Auftreten des hier beschriebenen Problems in Erwägung ziehen, die folgenden Komponenten Ihrer Datenbankserver aufzurüsten: die Anzahl an CPUs, den Arbeitsspeicher und die Verbindung an ein SAN (Storage Area Network). Natürlich sollten Sie eine ordnungsgemäße Diagnose durchführen, um festzustellen, welche Komponente (Arbeitsspeicher, Anzahl an CPUs usw.) der Auslöser für den Engpass ist und aufgerüstet werden muss.

Gemeinsame Nutzung eines Servers oder einer Festplatte für mehr als eine BizTalk-Datenbankgruppe

Wie bereits erwähnt, können andere Datenbanken als die MessageBox, wie die BizTalk-Überwachungsdatenbank (BizTalkDTADb) und die BAM-Datenbanken, auf der physikalischen Festplatte eines Servers eine große Menge an Lese- und Schreibzugriffen beanspruchen. Wenn diese Datenbanken und die MessageBox-Datenbanken auf dieselbe Festplatte zugreifen, kann die Festplatte überlastet werden und reagiert nicht mehr. Auf diese Weise verlieren BizTalk-Server die Verbindung zu den MessageBox-Datenbanken, und ein DBNetLib-Fehler tritt auf.

Es wird dringend empfohlen, alle Datenbanken, die erwartungsgemäß einen hohen Anteil der Ressourcen einer physikalischen Festplatte verbrauchen, die auch von den BizTalk MessageBox-Datenbanken verwendet wird, auf andere physikalische Festplatten zu verlegen (oder sie auf andere Server zu verlegen). Des Weiteren wird empfohlen, die BizTalkDTADb- und BAM-Datenbanken getrennt von den MessageBox-Datenbanken auf eigene Laufwerke/Server zu verlegen, sowie jede MessageBox-Datenbank (sofern mehrere vorhanden sind) auf einer eigenen Festplatte zu betreiben.

Archivieren und Löschen

Wenn BizTalkDTADb- und MessageBox-Datenbanken gemeinsam dieselbe Festplatte auf demselben Server verwenden, müssen Sie die BizTalkDTADb-Datenbanken regelmäßig archivieren und leeren, da sie andernfalls unbegrenzt wachsen.

Unsere Tests haben ergeben, dass regelmäßiges Archivieren und Leeren die beste Methode ist. Bei hohen Lasten sollte dieser Vorgang jedoch häufiger durchgeführt werden. Wenn Sie das Archivieren und Leeren nur unregelmäßig durchführen und die BizTalkDTADb-Datenbank bereits stark gewachsen ist, können diese Vorgänge beim Ausführen viel Zeit und einen Großteil der verfügbaren Ressourcen des Datenbankservers in Anspruch nehmen.