BizTalk Server数据库优化的后期配置
除了遵循预配置数据库优化中的建议外,在安装BizTalk Server并配置BizTalk Server数据库后,还应遵循几个步骤来优化SQL Server上的BizTalk Server数据库性能。 本主题提供这些优化的列表。
为BizTalk Server数据库预先分配空间,并将BizTalk Server数据库的自动增长设置定义为固定值而不是百分比值
SQL Server数据库自动增长是阻碍BizTalk Server数据库性能的阻塞操作。 因此,请务必提前为BizTalk Server数据库分配足够的空间,以最大程度地减少数据库自动增长的发生。
数据库自动增长应设置为固定的兆字节数而不是百分比, (指定文件增长 以兆字节 为单位) 。 如果发生自动增长,则应这样做,它以测量的方式执行此操作,从而降低数据库过度增长的可能性。 对于大型文件) ,增长增量通常不应大于 100 MB (;对于中型文件) 为 10 MB (;对于小型文件) ,增长增量不应大于 1 MB (。
当SQL Server增加文件大小时,必须先初始化新空间,然后才能使用它。 这是一个阻塞操作,涉及用空页填充新空间。 在 Windows Server 2003 或更高版本上运行的 SQL Server 2005 支持“即时文件初始化”。 这可以大大降低文件增长操作对性能的影响。 有关详细信息,请参阅 SQL Server 2008 - 数据库文件初始化。 本主题提供启用即时文件初始化的步骤。
将备份BizTalk Server输出目录移动到专用 LUN
将备份BizTalk Server (完整备份和日志备份) 输出目录移动到专用 LUN,编辑步骤 1 和 2 (在备份BizTalk Server [BizTalkMgmtDb] 作业) 插入新的输出路径。 通过将备份BizTalk Server输出目录移动到专用 LUN,当作业运行时,通过将写入到与作业读取数据不同的磁盘来减少磁盘 I/O 争用。
验证BizTalk Server SQL 代理作业是否正在运行
BizTalk Server包括多个SQL Server 代理作业,这些作业执行重要功能,使服务器保持正常运行。 应监视这些作业的运行状况,并确保它们在运行时没有错误。 BizTalk Server中性能问题的最常见原因之一是 SQL 代理作业BizTalk Server未运行,这反过来又可能导致 MessageBox 和跟踪数据库未选中增长。 请按照以下步骤操作,确保 BizTalk Server SQL 代理作业正常运行:
BizTalk Server中性能问题的最常见原因之一是 SQL 代理作业BizTalk Server未运行,这反过来又可能导致 MessageBox 和跟踪数据库未选中增长。 请按照以下步骤操作,确保 BizTalk Server SQL 代理作业正常运行:
验证SQL Server 代理服务是否正在运行。
验证BizTalk Server安装的SQL Server 代理作业是否已启用并成功运行。
BizTalk Server SQL Server 代理作业至关重要,如果作业未运行,系统性能会随着时间的推移而下降。
验证BizTalk Server SQL Server 代理作业是否及时完成。
设置 Microsoft Operations Manager (MOM) 2005 或 Microsoft System Center Operations Manager 2007 以监视作业。
应注意某些作业特有的计划:
默认情况下,MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb作业持续运行。 监视软件应将此计划考虑在内,而不是生成警告。
MessageBox_Message_Cleanup_BizTalkMsgBoxDb作业未启用或计划,但MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb作业每 10 秒启动一次。 因此,不应启用、计划或手动启动此作业。
验证是否正确配置了SQL Server 代理服务的启动类型。
验证SQL Server 代理服务是否配置为“自动”启动类型,除非SQL Server 代理服务配置为 Windows Server 群集上的群集资源。 如果SQL Server 代理服务配置为群集资源,则应将启动类型配置为“手动”,因为该服务将由群集服务管理。
配置跟踪数据的清除和存档
按照以下步骤确保正确配置了跟踪数据的清除和存档:
确保名为 DTA 清除和存档 的 SQL 代理作业已正确配置、启用并成功完成。 有关详细信息,请参阅 配置 DTA 清除和存档作业。
确保作业可以像生成传入跟踪数据一样快地清除跟踪数据。 有关详细信息,请参阅 测量最大可持续跟踪吞吐量。
查看软清除和硬清除参数,以确保将数据保留到最佳时间长度。 有关详细信息,请参阅 存档和清除 BizTalk 跟踪数据库。
如果只需要清除旧数据,并且不需要先存档,请更改 SQL 代理作业以调用名为 dtasp_PurgeTrackingDatabase 的存储过程。 有关详细信息,请参阅 从 BizTalk 跟踪数据库中清除数据。
监视和减少 DTC 日志文件磁盘 I/O 争用
Microsoft 分布式事务处理协调器 (MS DTC) 日志文件可能会成为事务密集型环境中的磁盘 I/O 瓶颈。 在使用支持事务的适配器(如 SQL Server、MSMQ 或 MQSeries)或在多 MessageBox 环境中时尤其如此。 事务适配器使用 DTC 事务,多 MessageBox 环境广泛使用 DTC 事务。 若要确保 DTC 日志文件不会成为磁盘 I/O 瓶颈,应监视 DTC 日志文件驻留在 SQL Server 数据库服务器上的磁盘的磁盘 I/O 使用情况, () 。 如果 DTC 日志文件所在的磁盘的磁盘 I/O 使用率过高,请考虑将 DTC 日志文件移动到更快的磁盘。 在SQL Server群集化的环境中,这不是一个问题,因为日志文件已位于共享驱动器上,该驱动器可能是具有多个轴的快速 SAN 驱动器。 不过,仍应监视磁盘 I/O 使用情况,因为它可能会成为非群集环境中的瓶颈,或者当 DTC 日志文件与其他磁盘密集型文件位于共享磁盘上时。
若要确保 DTC 日志文件不会成为磁盘 I/O 瓶颈,应监视 DTC 日志文件驻留在 SQL Server 数据库服务器上的磁盘的磁盘 I/O 使用情况, () 。 如果 DTC 日志文件所在的磁盘的磁盘 I/O 使用率过高,请考虑将 DTC 日志文件移动到更快的磁盘。
在SQL Server群集化的环境中,这不是一个问题,因为日志文件已位于共享驱动器上,该驱动器可能是具有多个轴的快速 SAN 驱动器。 不过,仍应监视磁盘 I/O 使用情况,因为它可能会成为非群集环境中的瓶颈,或者当 DTC 日志文件与其他磁盘密集型文件位于共享磁盘上时。
分隔 MessageBox 和跟踪数据库
由于 BizTalk MessageBox 和 BizTalk 跟踪数据库最活跃,因此建议将其中每个数据库的数据文件和事务日志文件放在专用驱动器上,以减少出现磁盘 I/O 争用问题的可能性。 例如,需要四个驱动器用于 MessageBox 和 BizTalk 跟踪数据库文件,每个驱动器用于以下各项:
messageBox 数据文件 ()
messageBox 事务日志文件 ()
BizTalk 跟踪 (DTA) 数据文件 ()
BizTalk 跟踪 (DTA) 事务日志文件 ()
分离 BizTalk MessageBox 和 BizTalk 跟踪数据库以及分离不同物理磁盘上的数据库文件和事务日志文件被认为是减少磁盘 I/O 争用的最佳做法。 尝试将磁盘 I/O 分散到尽可能多的物理轴上。 还可以通过将 BizTalk 跟踪数据库放置在专用SQL Server上来减少磁盘 I/O 争用,但是,在分离数据文件和事务日志文件时,仍应遵循上述做法。
优化BizTalk Server数据库的文件组
按照优化 Databases1 的文件组和“BizTalk Server数据库优化”白皮书中的步骤为BizTalk Server数据库创建其他文件组和文件。 这将极大地提高单磁盘配置中BizTalk Server数据库的性能。