若要为 BizTalk Server 数据库提供高可用性，请配置在 Windows 群集中运行 SQL Server 的两台计算机。 这些计算机可以以主动/主动、主动/被动或主动/主动/被动（需要三台计算机）配置以冗余方式运行，并且可以将数据存储在共享驱动器上（例如 RAID 1+0 SCSI 磁盘阵列）或存储区域网络（SAN）。
如果 SQL Server 服务因任何原因不可用，数据库群集会将资源从主动计算机传输到被动计算机。 在此故障转移过程中，BizTalk Server 服务实例遇到数据库连接失败，并自动重启以重新连接到数据库。 在完成故障转移并接管资源后，运作中的数据库计算机（之前为被动计算机）开始处理数据库连接。
关于 BizTalk Server 数据库集群的内容在 Clustering the BizTalk Server Databases2 中进行了讨论。 本部分重点介绍如何横向扩展 BizTalk Server 数据库以提供高可用性。
为 BizTalk MessageBox 数据库提供高可用性
本部分提供有关配置 BizTalk MessageBox 数据库以实现高可用性的信息。
运行多个 MessageBox 数据库
若要增强 BizTalk Server 数据库的可伸缩性，并解决 MessageBox 数据库 SQL Server 计算机上的 CPU 使用率高问题，可以将 BizTalk Server 配置为跨多个 MessageBox 数据库存储数据。 运行配置向导时，将创建第一个 MessageBox 数据库。 此 MessageBox 数据库是主 MessageBox 数据库。 BizTalk Server 部署中有一个主 MessageBox 数据库。 master MessageBox 数据库包含主订阅信息，并将消息路由到相应的 MessageBox 数据库。 通常，你想要将主 MessageBox 数据库专用于执行路由，并让其他 MessageBox 数据库执行处理。 若要使 MessageBox 数据库仅执行路由，请从 BizTalk 管理控制台中的 MessageBox 属性中选择 “禁用新邮件发布 ”。
MessageBox 数据库处理流的示例如下所示：
当主 MessageBox 数据库收到新的激活消息（业务流程或订阅消息的全新实例）时，主 MessageBox 数据库会将激活消息分发到下一个可用的 MessageBox 数据库。 例如，如果你有一个主 MessageBox 数据库和两个 MessageBox 数据库，则主 MessageBox 数据库会将第一个激活消息路由到 MessageBox 数据库 1、第二个激活消息路由到 MessageBox 数据库 2、第三个激活消息到 MessageBox 数据库 1，以轮循模式进行路由。 master MessageBox 数据库使用内置逻辑进行负载均衡，不需要额外的负载均衡机制。
主 MessageBox 数据库将激活消息路由到特定的 MessageBox 数据库（例如 MessageBox 数据库 1）之后，业务流程将进入内存并运行。
如果业务流程必须等待消息，并且等待时间超过几秒钟，则业务流程将保留回 MessageBox 数据库 1。 业务流程正在等待相关消息。
当相关消息到达主 MessageBox 数据库时，消息引擎在包含相关消息状态的 MessageBox 数据库的数据库中执行查找作（在此示例中为 MessageBox 1）。 master MessageBox 数据库将消息传递到包含业务流程的 MessageBox 数据库。
业务流程会返回到内存中，以继续处理，直到它完成或必须等待另一个关联消息。
BizTalk Server 将所有状态存储在 MessageBox 数据库中，每个 MessageBox 数据库都包含不同业务流程的状态信息。 为了可靠性，必须将所有 MessageBox 数据库（包括 master 和 secondary MessageBox 数据库）群集。
若要配置多个 MessageBox 数据库，请使用 BizTalk Server 管理控制台添加运行 SQL Server 的计算机。 从管理的角度来看，只需添加新的 MessageBox 数据库。 BizTalk Server 会自动处理激活消息的轮流分发，并将关联消息发送到正确的 MessageBox 数据库。
如果在环境中配置多个 MessageBox 数据库，则应至少为 BizTalk Server 组创建三个 MessageBox 数据库，并且应在主 MessageBox 数据库上禁用消息发布。 之所以提出此建议，是因为添加额外的 MessageBox 数据库会导致主 MessageBox 数据库在多个 MessageBox 数据库之间路由消息时产生资源开销。 如果仅配置两个 MessageBox 数据库，则其他 MessageBox 数据库获得的大多数好处都会抵消主 MessageBox 数据库用于消息路由的开销。
重要
BizTalk Server 将所有状态存储在 MessageBox 数据库中，每个 MessageBox 数据库都包含不同业务流程的状态信息。 为了可靠性，必须将所有 MessageBox 数据库（包括 master 和 secondary MessageBox 数据库）群集。
为多个 MessageBox 数据库提供高可用性
虽然将 MessageBox 数据库添加到 BizTalk Server 部署可以提高可伸缩性，但它不提供高可用性，因为每个 MessageBox 数据库都是唯一的且独立的，并且可能是 BizTalk Server 环境的单一故障点。 若要添加冗余，需要为每个 MessageBox 数据库配置服务器群集。 BizTalk Server 将数据分布在多个 MessageBox 数据库中，因此在没有服务器群集的情况下，数据库不会共享数据或提供冗余。
为 BizTalk 跟踪数据库提供高可用性
根据特定部署的要求，你可能希望通过将 BizTalk 跟踪数据库隔离到单独的 SQL Server 计算机以及创建专用于主机跟踪的单独 BizTalk 主机来提高跟踪性能。 下图显示了具有两个主机实例和群集数据库的专用跟踪主机。
如果您的部署具有高吞吐量且涉及跟踪这些消息流的大量数据，那么跟踪开销可能会消耗运行 SQL Server 的计算机上的许多资源。 如果出现这种情况并且传入消息速率较高，BizTalk Server 将达到无法处理新消息的位置，因为跟踪消息所需的资源大于运行其他 BizTalk Server 组件所需的资源（例如接收消息并将其保存到 MessageBox 数据库）。
为了提高性能和安全性，建议将主机专用于跟踪，该主机不包含任何其他项（例如接收位置、业务流程或管道），并且禁用从接收、处理和发送主机进行跟踪。 若要为跟踪主机提供高可用性，请创建跟踪主机的多个主机实例。 请参阅 “创建新主机”。
对于每个 MessageBox 数据库，BizTalk Server 仅使用一个跟踪主机实例将消息从 MessageBox 数据库移动到 BizTalk 跟踪数据库（BizTalkDTADb）。 如果其他计算机运行跟踪主机的实例，BizTalk Server 会自动将每个 MessageBox 数据库的处理扩展到跟踪主机的单独实例。 如果 MessageBox 数据库数大于跟踪主机实例的数量，则一个或多个跟踪主机实例将服务多个 MessageBox 数据库。
若要为 BizTalk 跟踪数据库提供高可用性，请使用 Windows 群集配置在主动/被动配置中运行 SQL Server 的两台数据库计算机。
为 BAM 数据库提供高可用性
业务活动监视（BAM）提供对业务流程的可见性，不受限于 IT 实施方式，并支持跨不同类型的 IT 实施。 BAM SQL Server 数据库（BAM 星形架构数据库、BAM 主导入数据库和 BAM 存档数据库）以及 BAM 分析数据库存储不同于业务活动数据的操作监视数据。 下图显示了 BAM 数据库基础结构。
若要确保 BAM 基础结构高度可用，请执行以下作：
对 BAM 主导入数据库与 BAM 分析数据库进行群集。 BAM 主要导入数据库是业务活动监控系统的中心。 因此，请务必使用 Windows 群集使此数据库高度可用，并遵循以下两项建议来防止此数据库填满。 BAM Analysis 数据库是一个 Analysis Services 数据库，用于存储业务分析师用于生成活动聚合和 OLAP 多维数据集的数据，因此，此数据库的任何停机时间都会影响其工作效率。 虽然不必对 BAM 存档数据库进行群集，但我们建议在 SQL Server Integration Services （SSIS） 包运行时监视事件日志中是否有错误，以确保数据已成功传输，并监视数据库的大小，以便可以在数据库填充之前替换它。
定义联机窗口。 为了提高性能并避免停机，BAM 根据活动完成时的时间戳将 BAM 主导入数据库中的数据分割成表。 BAM 通过定期用另一个格式相同的空表替换已完成的表来实现这一目标。 BAM 执行此操作后，额外完成的活动将进入新分区（表），而 BAM 将旧分区保留在联机窗口中定义的时间内。 必须定义联机窗口，以确保 BAM 主导入数据库中的分区数不会太大。 有关在线窗口调度的详细信息，请参阅归档主导入数据库数据。
计划 SSIS 包定期运行。 定义联机窗口可确保 BAM 主导入数据库不会填满旧活动分区。 还必须计划 SSIS 包定期运行，以便为活动数据创建新分区，并将数据从 BAM 主导入数据库中的旧分区移动到 BAM 存档数据库中。 有关调度 SSIS 包的详细信息，请参阅 调度 SQL Server Integration Services 包。
仔细选择少量的数据项（检查点），并避免在定义活动时包括不必要的数据项。
在设计聚合时，了解计划聚合和实时聚合之间的权衡。 实时聚合由 SQL Server 触发器自动维护，延迟为零。 它们非常适合某些需要低延迟的关键任务场景，但每当事件写入 BAM 主要导入数据库时，它们都会产生性能成本。 计划聚合依赖于计划的立方 SSIS 包来更新其聚合数据。 它们的延迟等于或大于 SSIS 计划间隔，但总体而言，它们对 BAM 主导入数据库的性能影响较小。
如果选择计划的聚合，请确保安排数据立方 SSIS 比存档 SSIS 更频繁地运行。 这是因为存档 SSIS 不会将已为计划聚合处理的活动数据移动到 BAM 存档数据库。
在多台计算机中启用 BAM 事件总线服务以获取故障转移功能。
为其他 BizTalk Server 数据库提供高可用性
若要为其他 BizTalk Server 数据库提供高可用性，请配置在 Windows 群集中运行 SQL Server 的两台计算机。 这些计算机可以在主动/主动或主动/被动配置中运行，以便实现冗余，并且可以在共享驱动器（例如 RAID 1+0 SCSI 磁盘阵列）或存储区域网络（SAN）上存储数据。