避免 DBNETLIB 异常

2025-06-05

当 BizTalk Server 运行时无法与 MessageBox 或管理数据库通信时，会发生 DBNetLib（数据库网络库）错误。发生这种情况时，捕获异常的 BizTalk Server 运行时实例将关闭，然后每隔一分钟循环检查数据库是否可用。

DBNetLib 错误的最常见原因是，其中一个（可能很多）MessageBox 数据库服务器变得非常繁忙，并且进一步尝试与其通信会导致超时，这会导致 DBNetLib 异常。

除了 MessageBox 数据库非常繁忙的情况外，当托管一个或多个 MessageBox 数据库的 BizTalk 数据库服务器因输入/输出（I/O）繁忙而导致生产环境中出现瓶颈时，可能会发生 DBNetLib 错误。

本主题介绍可能导致 DBNetLib 错误和避免这些错误的建议的条件。

DBNetLib 错误的原因和解决方法

DBNetLib 错误的症状

Microsoft BizTalk Server 主机实例将终止，然后重启自身，并将类似于以下内容的错误写入 BizTalk Server 应用程序日志：

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."

托管 MessageBox 数据库的 BizTalk 数据库服务器成为 I/O 绑定

BizTalk 服务器直接与托管 MessageBox 数据库的数据库服务器通信和作。如果托管 MessageBox 数据库的任何数据库服务器资源消耗过多，并进入 I/O（输入/输出）瓶颈状态，则可能会导致无响应。 BizTalk 服务器之一反过来可能会失去与其中一个数据库服务器的连接，并且会发生 DBNetLib 错误。

我们的测试表明，当其物理磁盘的“%Idle 时间”持续下降并降至低于 10%时，使用频繁的数据库服务器将面临 I/O 限制。如果“%Idle 时间”继续下降到较低水平，则表明数据库服务器可能变得不可响应。

原因

有多种原因可能导致托管 MessageBox 数据库的数据库服务器成为 I/O 绑定，其中一些原因如下：

如果托管 MessageBox 数据库的数据库计算机受低硬件规格的约束，例如：内存不足、处理器数量和速度等。
如果托管 MessageBox 数据库的数据库计算机上的物理磁盘正在被其他占用资源较多的数据库共享。在多个数据库（包括 MessageBox）被同时大量访问的情况下，物理磁盘可能会进入 I/O 受限状态。

这种情况的示例如下：

我们的测试表明，托管 BizTalkDTADb 和/或 BAM 数据库的数据库服务器有时会消耗物理磁盘 %Disk 读取和写入时间的高百分比。当承载 MessageBox 数据库的数据库服务器磁盘正由另一个高度消耗的数据库（如 BizTalkDTADb 或 BAM）共享时，如果两个数据库同时消耗得很高，则可能会导致数据库服务器物理磁盘成为 I/O 绑定，然后无响应。
如果 BizTalkDTADb 和一个或多个 MessageBox 数据库在数据库服务器上共享同一物理磁盘，如果存档和清除不频繁运行，则磁盘可能会成为 I/O 绑定。

决议

确保托管 BizTalk MessageBox 的数据库服务器不会进入高度消耗且可能无响应的情况。

下面列出了服务器磁盘消耗量高的主要原因以及有关如何缓解此问题的建议。

低硬件规格

我们的测试表明，当服务器的硬件规格无法跟上它尝试处理的负载量时，服务器开始消耗更多。由于硬件规格较低，系统会因数据库上发生的活动量而快速不知所措。这可能会导致服务器的 %Disk 读取和写入时间继续增加而不稳定，磁盘的 %Idle 时间继续减少并降低 10%，这可能会导致数据库服务器无响应。

如果发现在高负载期间遇到无响应数据库服务器，则应考虑在数据库服务器中升级以下部分：CPU 数、内存和连接到 SAN，具体取决于 BizTalk 部署中的活动和负载量。当然，你应该进行适当的诊断，以确定哪些部分（内存、CPU 数量等）是需要在硬件中升级的瓶颈。

如前所述，除了 MessageBoxes 以外，BizTalk 跟踪（BizTalkDTADb）数据库和 BAM 数据库等其他数据库可能会在服务器的物理磁盘上高耗资源。因此，如果这些数据库碰巧与 MessageBox 数据库共享相同的物理磁盘，则它们可能会扼杀磁盘并使其无响应，这再次可能导致 BizTalk 服务器与 MessageBox 数据库松散连接，从而命中 DBNetLib。

强烈建议将服务器物理磁盘消耗量较高的数据库与 BizTalk MessageBox（s）分开，以便它们共享不同的物理磁盘（或在不同的服务器上分隔它们）。建议将 BizTalkDTADb 和 BAM 数据库与 MessageBox（s）分开，建议将每个 MessageBox 数据库（在这种情况下，有多个）存储在自己的磁盘上。

存档和清除

如果 BizTalkDTADb 和 MessageBox 数据库在同一服务器上共享同一磁盘，则必须定期存档和清除 BizTalkDTADb 数据库，否则它们将无限期增长。

测试表明，定期存档和清除是一种好的做法，但如果在负载高于正常的情况下运行，则可能需要考虑存档并更频繁地清除。如果不定期维护 BizTalkDTADb 数据库的增长，那么当这些操作最终被执行时，它们可能需要相当长的时间，并在运行时消耗大部分可用的数据库服务器资源。

通过