清单：维护 BizTalk Server 数据库并进行故障排除
BizTalk Server数据库及其运行状况对于成功BizTalk Server数据库消息传送环境非常重要。 本主题列出了维护或排查BizTalk Server数据库问题时必须遵循的步骤。
维护 BizTalk Server 数据库
禁用“自动更新统计信息”和“自动创建统计信息”选项 (仅适用于BizTalk Server MessageBox 数据库) 。 默认情况下，这些设置配置为BizTalk Server配置的一部分。 不应更改这些设置。
若要查看这些设置是否已禁用，请在 SQL Server 中执行以下存储过程：
SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoCreateStatistics') AS IsAutoCreateStatistics SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoUpdateStatistics') AS IsAutoUpdateStatistics返回的值应为 0 ，以指示设置已禁用。 如果未返回 0，则通过在 SQL Server 中执行以下操作来禁用设置：
ALTER DATABASE BizTalkMsgBoxDB SET AUTO_CREATE_STATISTICS OFF ALTER DATABASE BizTalkMsgBoxDB SET AUTO_UPDATE_STATISTICS OFF有关这些设置的详细信息，请转到尝试连接到 BizTalk Server 中的 BizTalkMsgBoxDb 数据库时遇到阻塞、死锁情况或其他SQL Server问题。
设置 Max Degree of Parallelism 属性。 默认情况下，此设置配置为BizTalk Server配置的一部分。 不应更改这些设置。
在承载BizTalk Server MessageBox 数据库的SQL Server实例上，将“最大并行度run_value和config_value属性设置为一 (1) 。 若要检查 Max Degree of Parallelism 设置，请对 SQL Server 中的 Master 数据库执行以下存储过程：
exec sp_configure 'max degree of parallelism'如果run_value和config_value的值未设置为 1 (1) ，请在 SQL Server 中执行以下存储过程：
exec sp_configure 'max degree of parallelism', '1' reconfigure with override有关“最大并行度”设置如何影响BizTalk Server的详细信息，请转到尝试连接到 BizTalk Server 中的 BizTalkMsgBoxDb 数据库时遇到阻塞、死锁情况或其他SQL Server问题。
确定何时可以重新生成BizTalk Server索引。
BizTalk Server数据库中的大多数索引都 (索引 ID 聚集：1) 。 DBCC SHOWCONTIG 命令可用于显示BizTalk Server数据库中表的碎片信息。 这些索引基于 GUID，因此发生碎片是正常的。 如果 DBCC SHOWCONTIG 的扫描密度值小于 30%，则可以在停机期间重新生成索引。 BizTalk Server 数据库中的许多表都包含使用 DataType 定义的列，这些列无法进行联机索引编制。 因此，在 BizTalk 处理数据时，绝不应重新生成BizTalk Server数据库中表的索引。
有关如何重新生成 BizTalk 索引的详细信息，请转到在 BizTalk Server 中尝试连接到 BizTalkMsgBoxDb 数据库时遇到阻塞、死锁情况或其他SQL Server问题。
还可以使用 sys.dm_db_index_physical_stats 函数在SQL Server中查找碎片信息。 有关详细信息，请参阅 sys.dm_db_index_physical_stats (Transact-SQL) 。
监视数据库中的锁、块或死锁。
锁和块在BizTalk Server使用的SQL Server数据库上发生预期行为。 但是，预计这些锁或块不会长时间持续。 BizTalk Server使用的SQL Server数据库上的扩展阻塞和死锁表明存在潜在问题。
有关BizTalk Server使用的SQL Server数据库死锁和阻塞的当前已知原因，请转到尝试连接到 BizTalk Server 中的 BizTalkMsgBoxDb 数据库时遇到阻塞、死锁情况或其他SQL Server问题。
监视数据库和表的大小。
BizTalk Server MessageBox 数据库的大小通常不应超过大约 5GB。 BizTalkMsgBoxDb 数据库不应包含任何数据，在处理数据或将数据移动到 BizTalkDTADb 数据库之前，应将其视为缓冲区。 具有强大SQL Server后端和大量长时间运行的业务流程的环境可能具有大于 5GB 的 BizTalkMsgBoxDb 数据库。 没有长时间运行的业务流程的高容量环境应具有远小于 5GB 的BizTalk Server MessageBox 数据库。
BizTalk Server跟踪数据库的大小可能有很大差异，但如果查询性能大幅下降，则跟踪数据库可能太大。 从经验来看，大于 15-20 GB 的BizTalk Server跟踪数据库被视为太大，可能会对性能产生负面影响。
以下问题可能是由于BizTalk Server数据库太大造成的：
- BizTalk Server MessageBox 数据库继续增长，而数据大小 (不仅日志文件) 仍然很大。 BizTalk Server处理即使是简单的消息流方案也需要比平常更长的时间。
- 组中心查询花费的时间比平时更长，甚至可能超时。
- 数据库日志文件永远不会被截断。
- BizTalk SQL 代理作业的运行速度比平常慢。
- 与正常表相比，某些表非常大或包含过多的行。
BizTalk Server数据库可能会变得很大，原因有多种，包括：
- BizTalk SQL 代理作业未运行
- 过多挂起的消息或服务实例
- 磁盘故障
- 高级别的跟踪
- BizTalk Server限制
- SQL Server性能不佳
- 网络延迟问题
同样，表中的行数可能过多。 没有设置的行数过多。 此外，此行数因表中存储的数据类型而异。 例如，包含 100 万行以上的 dta_DebugTrace 表的行数可能过多。 包含 200,000 行以上的 HostNameQ_Suspended 表的行数可能过多。
确保了解环境中的预期内容，以确定数据问题是否发生。
在BizTalk Server主机上启用跟踪。
默认情况下，在默认主机上启用跟踪。 BizTalk 要求在单个主机上选中 “允许主机跟踪 ”选项。 启用跟踪后，跟踪数据解码服务 (TDDS) 将跟踪事件数据从 BizTalk Server MessageBox 数据库移动到BizTalk Server跟踪数据库。 如果没有为BizTalk Server主机配置“允许主机跟踪”选项，或者如果跟踪主机已停止，则 TDDS 将不会运行，并且未选中BizTalk Server MessageBox 数据库中的TrackingData_x_x表。
因此，应为专用BizTalk Server主机配置“允许主机跟踪”选项。 有关配置专用跟踪主机的详细信息，请参阅 配置专用跟踪主机。
若要允许 TDDS 在大容量方案中维护新的跟踪事件，可以创建单个跟踪主机的多个实例，但不应为跟踪配置多个主机。
使用正确的 BizTalk SQL Server 代理作业。
执行BizTalk Server SQL 代理作业对于管理BizTalk Server数据库和维护最佳性能至关重要。
备份BizTalk Server SQL Server 代理作业是唯一受支持的备份BizTalk Server数据库的方法。 此作业要求将所有BizTalk Server数据库设置为使用完全恢复模式。 应为正常的BizTalk Server环境配置此作业。 仅当SQL Server服务停止且所有BizTalk Server进程都停止时，才能使用 SQL Server 方法备份BizTalk Server数据库。
有关在配置 SQL 代理备份BizTalk Server作业时使用SQL Server完整恢复模式的详细信息，请参阅日志传送或完整恢复模式下的备份。
MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server 代理作业设计为无限期运行。 因此，SQL 代理作业历史记录可能不会指示此 SQL 代理作业已成功完成;此行为是设计使然。 如果失败，作业将在 1 分钟内重启，并继续有增无减地运行。 因此，通常可以忽略此作业的失败通知。
如果MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server 代理作业的作业历史记录指示此作业不断失败并正在重启，则可能需要进一步调查失败/重启周期的原因。
MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server 代理作业是唯一不应手动启用的作业，因为它由MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb作业启动。
DTA 清除和存档SQL Server 代理作业通过清除和存档跟踪的消息来维护BizTalk Server跟踪数据库。 此作业读取表中的每一行，并比较每行的时间戳以确定是否应删除记录。
对BizTalk Server SQL Server 代理作业进行故障排除时，请验证除MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb之外的所有 SQL 代理作业是否均未出错。
有关 SQL Server 中使用的 BizTalk Server SQL 代理作业的详细信息：
监视和终止挂起的实例。
服务实例可以暂停 (可恢复) ，也可以暂停 (不可恢复) 。 这些服务实例可以是消息传送、业务流程或端口。 BizTalk Server通过使用 BizTalk Server 管理控制台中的“组中心”页或使用 Terminate.vbs 脚本来终止和删除这些实例。 有关 Terminate.vbs 脚本的详细信息，请参阅 删除挂起的服务实例。
还可以使用终止符工具删除挂起的实例。 终止符工具包含在BizTalk 运行状况监视器中。
术语“孤立”和“僵尸”通常可互换使用。 孤立消息或僵尸消息是没有关联的服务实例的消息，通常是因为服务实例在收到消息之前已终止。 孤立或僵尸服务是没有任何关联消息的服务。 有关僵尸消息和服务实例的详细信息，BizTalk Server请参阅 BizTalk Server 中的僵尸。
监视 PhysicalDisk 性能对象的性能计数器。
BizTalk Server在一分钟内SQL Server大量简短、非常快速的事务。 如果SQL Server无法维持此活动，则可能会遇到BizTalk Server性能问题。 监视 PhysicalDisk 性能对象中的 Avg.Disk sec/Read、Avg. Disk sec/Transfer 和 Avg.Disk sec/Write 性能监视器计数器。 最佳值小于 10 ms (毫秒) 。 如果值为 20 毫秒或更大，则被视为性能不佳。
有关BizTalk Server数据库高可用性的详细信息，请参阅为BizTalk Server数据库提供高可用性。
遵循BizTalk Server数据库的最佳做法。 请参阅维护BizTalk Server数据库的最佳做法。
BizTalk Server数据库疑难解答
执行以下任务以排查BizTalk Server数据库的任何问题。
确保所有必需的 BizTalk SQL Server 代理作业都已启用并正在运行。
所有 BizTalk SQL Server 代理作业（MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb作业除外）都应启用并成功运行。 请勿禁用任何其他作业。
如果发生故障，请使用 SQL Server 中的“查看历史记录”选项查看错误信息，然后相应地排查故障。 请记住，MessageBox _Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server 代理作业无限运行。 因此，仅当作业历史记录报告作业不断失败并重启时，才应该担心。使用 MsgBoxViewer 工具分析 BizTalk MessageBox 和其他数据库。
msgBoxViewer 工具包含在BizTalk 运行状况监视器中。 MsgBoxViewer 工具可用于故障排除，因为它提供了一个 HTML 报表，其中包含有关表大小和行计数的详细信息。 报告还有助于确定BizTalk Server是否在限制。 此外，该工具还提供BizTalk Server数据库和BizTalk Server配置的快照。
当BizTalk Server运行速度比平时慢时，运行 MsgBoxViewer 工具，单击以在“可选查询”选项卡上选择所有查询，然后查看生成的 HTML 报告是否存在任何问题。 “ 摘要报告 ”部分以黄色显示警告，并用红色列出潜在问题。
此外，还可以使用 MsgBoxViewer 工具确定哪些表最大且记录最多。 有关通常增大大型表的列表以及有关如何管理这些表的说明，请参阅大型BizTalk Server数据库表。
使用终止符工具解决 MsgBoxViewer 工具标识的问题（如果有）。
终止符工具包含在BizTalk 运行状况监视器中。 此工具使用户能够轻松解决 BizTalk MsgBoxViewer 工具发现的任何问题。
调查死锁方案。
在死锁方案中，对SQL Server启用 DBCC 跟踪，以便将死锁信息写入 SQLERROR 日志。 在 SQL Server 中，执行以下语句，为死锁方案启用 DBCC 跟踪：
DBCC TRACEON (1222,-1)还可以使用 PSSDIAG 实用工具收集有关 Lock：Deadlock 事件和 Lock：Deadlock Chain 事件的数据。 有关详细信息，请参阅 PSSDIAG 数据收集实用工具。
BizTalkMsgBoxDB 数据库是 OLTP) 数据库 (大容量、高事务联机事务处理。 对于此类数据库，预期会出现一些死锁，这种死锁由BizTalk Server引擎在内部处理。 发生此行为时，错误日志中不会列出任何错误。 调查死锁方案时，在输出中调查的死锁必须与事件日志中的死锁错误相关联。
查找阻止的进程。
可以使用 SQL Server 中的活动监视器来获取锁定系统进程的 SPID) 的服务器进程标识符 (。 然后，可以运行 SQL 探查器来确定在锁定 SPID 中执行的 SQL 语句。 可以使用 PSSDIAG 实用工具对SQL Server中的锁定和阻塞问题进行故障排除。 该实用工具捕获启用了阻止脚本的所有 Transact-SQL 事件。 有关详细信息，请参阅 PSSDIAG 数据收集实用工具
在SQL Server中，可以指定阻止的进程阈值设置，以确定哪些 SPID 或 SPID 阻塞的时间长于指定的阈值。 有关阻止进程阈值选项的详细信息，请参阅 阻止的进程阈值选项。
如果在SQL Server遇到锁定或阻止问题，可以联系 Microsoft 客户支持服务。
删除所有不需要的数据。
如果数据库已变得太大，并且不再需要数据库中包含的数据，则首选方法是删除数据。 谨慎： 请勿在数据是业务关键或需要数据的任何环境中使用此方法。
清除 BizTalkMsgBox 数据库：
下载并安装BizTalk 运行状况监视器中包含的终止符工具。
按照主题 如何手动清除测试环境中的 MessageBox 数据库中的数据 中的步骤，在 BizTalk MessageBox 数据库中创建bts_CleanupMsgbox存储过程。
使用终止符工具执行bts_CleanupMsgbox存储过程并清除 BizTalk MessageBox 数据库。
bts_CleanupMsgbox存储过程会删除数据。 在生产环境中运行此存储过程时要小心。
重启所有主机和BizTalk Server服务。
清除 BizTalkDTADb 数据库：
方法 1
- 备份所有BizTalk Server数据库。
- 执行 dtasp_PurgeAllCompletedTrackingData 存储过程。 有关存储过程的详细信息，请参阅 如何从 BizTalk 跟踪数据库中手动清除数据。
方法 2：仅当 BizTalkDTADb 数据库包含许多必须删除的不完整实例时，才使用此选项。
- 备份所有BizTalk Server数据库。
- 停止所有 BizTalk 主机、服务和自定义独立适配器。 如果使用 HTTP 或 SOAP 适配器，请重启 IIS 服务。
- 在 BizTalkDTADb 数据库上执行 dtasp_CleanHMData 存储过程。
- 重启所有主机和BizTalk Server服务。
如果必须具有跟踪数据，请备份 BizTalkDTADb 数据库，将数据库还原到另一个SQL Server，然后清除原始 BizTalkDTADb 数据库。
如果需要帮助分析 MsgBoxViewer 数据或 PSSDIAG 输出，请联系 Microsoft 客户支持服务。 在联系客户支持服务之前，请将 MsgBoxViewer 数据、PSSDIAG 输出和更新的事件日志压缩) (.evt 文件。 可能需要将这些文件发送给BizTalk Server支持工程师。
下一步
另请参阅
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈