SQL Server中的自动增长和自动收缩配置注意事项

原文:https://support.microsoft.com/zh-cn/kb/315512 在许多 SQL Server 系统上,您可以直接使用默认的自动增长和自动收缩设置而无需进行任何调整。但是,在某些环境中,您不必打开这些设置;而在某些环境中,您可能必须调整自动增长和自动收缩参数。

如果您决定调整自动增长和自动收缩参数,需要考虑以下事项。

如何配置这些设置?

您可以使用下列方法配置自动增长和自动收缩设置:

  • ALTER DATABASE 语句(仅适用于 SQL Server 2000)。
  • sp_dboption 存储过程。
  • SQL 企业管理器。

切记,自动增长设置是以文件为单位设置的。因此,对于每个数据库,您必须至少在两个位置设置它们(一个是主数据文件,另一个是主日志文件)。如果您有多个数据文件和/或日志文件,则必须在每个文件上设置选项。根据您的具体环境,最终每个数据库文件可能有各自不同的设置。

对性能有何影响?

  • 如果您运行的事务需要的日志空间大于可用空间,并且您已经为该数据库的事务日志打开自动增长选项,则在完成事务所花费的时间中,有一部分是事务日志按配置量增长所花费的时间。如果该增长量很大,或者有其他因素导致时间延长,则您在其中打开事务的查询可能因超时错误而失败。数据库的数据部分的自动增长可能会造成此类问题。要更改自动增长配置,请参阅 SQL Server 联机丛书中的 “ALTER DATABASE”(更改数据库)主题。

  • 如果您运行的是要求日志增长的大型事务,则要求写入事务日志的其他事务也必须等到增长操作完成后才能执行。

  • 如果您同时使用自动增长和自动收缩选项,则可能会带来不必要的开销。请确保触发增长和收缩操作的阈值不会造成频繁的大小调整。例如,您可能会运行这样一个事务,它导致事务日志在提交时增长 100 MB。在自动收缩启动后的一段时间内,事务日志收缩 100 MB。然后,您又运行相同的事务,并导致事务日志再次增长 100 MB。在该示例中,您造成了不必要的开销,并且可能会产生日志文件碎片,两者都可能对性能造成负面影响。

  • 数据或日志文件大小更改所造成的物理碎片可能会严重影响性能。无论您使用自动设置还是频繁地以手动方式增长或收缩文件,都存在这一问题。

  • 如果您的数据库增长量很小,或者先增长再收缩它,可能会产生磁盘碎片。在某些情况下,磁盘碎片会导致性能问题。即使增长量较小,也可能降低系统的性能。

最佳做法

  • 对于受管理的生产系统,您必须将自动增长仅视为偶然的意外增长。请勿使用自动增长管理每天的数据和日志增长。

  • 您可以使用警报或监控程序来主动地监控文件大小和增长文件。这有助于您减少碎片,并允许您将这些维护活动移到非高峰时段进行。

  • 自动收缩和自动增长必须由训练有素的数据库管理员 (DBA) 仔细评估,而不能不对其进行管理。

  • 您的自动增长增量必须足够大,以避免上一节中列出的性能影响。要在您的配置设置中使用的精确值以及增量是以百分比还是以特定的 MB 值表示取决于环境中的许多因素。一种可供尝试的通用经验规则是:将您的自动增长设置设定为文件大小的八分之一左右。

  • 打开每个文件的 设置,以防某个文件增长到会用尽全部可用磁盘空间的大小。

  • 保持事务大小尽可能小,以防出现计划外的文件增长。

既然大小设置是自动控制的,为什么我还要操心磁盘空间的大小?

  • 在使用自动增长设置时,增长后的数据库大小不能超出为其定义文件的驱动器上的可用磁盘空间。因此,如果您依赖自动增长功能来决定您的数据库的大小,仍必须另外检查可用的硬盘空间。自动增长设置还受到您为每个文件选择的 MAXSIZE 参数的限制。若要降低空间不足的可能性,您可以监视性能监视计数器 SQL Server:Databases Object :Data File(s) Size (KB)(数据库对象:数据文件大小),令其在数据库达到特定大小时发出警报。

  • 数据或日志文件的计划外增长会占用其他应用程序原以为可用的空间,并可能导致这些其他应用程序出现问题。

  • 为了满足事务单元的需要,事务日志的增量必须足够大。即使自动增长已经打开,但如果它增长得不够快,无法满足查询的需要,您也会收到事务日志已满的消息。

  • SQL Server 不会持续测试达到为自动收缩配置的阈值的数据库。相反,它会寻找可用的数据库并找出第一个配置为自动收缩的数据库。它将检查该数据库,并在需要时收缩该数据库。然后,它会等待几分钟,再检查下一个配置为自动收缩的数据库。换句话说,SQL Server 不会同时检查所有数据库,也不会同时收缩所有数据库。它将以循环方式处理各个数据库,以使负载在时间上错开。因此,从数据库达到阈值到实际完成收缩可能需要几个小时,具体取决于特定 SQL Server 实例上配置为自动收缩的数据库数量。

也可以看看