彩票走势图

SQL Monitor是一个SQL Server监控工具。它可以监控SQL Servers的健康状况和活动，并通过电子邮件为您发送监测结果和建议。

点击下载SQL Monitor免费版

SQL Monitor不仅自动收集您需要的所有磁盘和数据库增长跟踪数据，而且还分析这些数据的趋势以准确预测何时磁盘卷会耗尽可用空间，或数据库文件何时需要增长。本教程一共分为三个部分，这是最后一部分内容——监视数据库文件增长。（上篇查看点击这里，中篇查看点击这里）

监视数据库文件增长

如果正确完成了初始数据和日志大小调整，并且如上所述，您正在仔细监视文件的使用情况，那么使用文件自动增长功能，可以预期物理文件大小会增加，而不是临时增加。

但是，众所周知，为新数据库预测数据存储要求非常困难，甚至由于各种原因，即使是已建立的数据库有时也可能会意外地自动增长。意外的数据导入，导致事务无休止地打开（防止日志截断）的软件错误，维护操作等等，都可能导致意外的快速增长。当数据库爆炸性增长时，它将导致文件自动增长事件，这可能会消耗大量CPU资源。如果发生在繁忙时段，则可能导致应用程序进程阻塞和中断。

依靠自动增长不是一个好的文件大小管理策略。应该启用它，但仅将其用于提供“安全网”，以适应文件突然增长和意外增长的情况（假设它们还确保容纳数据和日志文件的磁盘卷具有足够的空间来容纳意外增长）。

换句话说，发生了自动增长，您需要了解它并调查原因。

临时跟踪数据库增长

跟踪数据库增长的一种经典方法是使用msdb.dbo.backupset，从每个数据库的夜间完整备份中捕获数据库增长，并在Excel中随时间跟踪它。另外，sp_databases系统存储过程将为您提供实例上所有数据库的总大小（以KB为单位），或者您可以使用各种系统表和视图。

目录视图的size列sys.database_files以8 KB页的形式提供每个数据库文件的大小，因此以GB为单位计算数据库的总大小很简单：

SELECT SUM(size) * 8.0 / 1024.0 / 1024.0 AS SizeInGB
FROM sys.database_files;

您可以通过查询默认跟踪收集的数据来找出哪个数据库最近经历了自动增长（或自动收缩）事件。但是，默认跟踪文件确实会滚动，因此历史数据将被覆盖，并且自上次滚动以来，您只会看到最近的自动增长事件。

在SQL Monitor中监视数据库增长

该总数据库文件大小在SQL监视器自订指标收集和分析数据sys.database_files（使用以前的查询），随着时间的推移。如果此度量标准检测到整个数据库大小发生了变化，则数据库可能正在以意外的速度增长，因此DBA需要了解原因。数据库增长是由数据增长还是日志文件增长引起的？

SQL Monitor提供了数据库自动增长自定义指标，该指标将按计划从默认跟踪中收集数据。如果指标数据的收集周期比跟踪文件滚动的周期短，那么您将不会错过任何增长事件，并且可以为此指标设置警报，因此您会立即意识到发生了异常的自动增长事件。

监控数据文件的增长

当数据文件增长时，它们可以使用即时文件初始化，从而允许SQL Server分配更多的磁盘空间，而无需在可以将任何数据写入到其中之前对所有这些空间进行零初始化。这使得每个增长事件都相对高效，但是如果文件需要频繁扩展，它仍然会导致阻塞问题，因为其他数据库处理必须暂停，直到增长事件完成为止。随着时间的流逝，它也可能导致物理文件碎片化。

前面描述的数据库文件使用率和警报为您提供了监视数据文件增长，以及文件内空间使用所需的诊断数据。但是，您也可以使用数据库文件大小自定义指标（该指标从sys.dm_os_performance_counters动态管理视图（DMV）收集值）来跟踪数据文件大小的变化。

监视日志文件增长

SQL Server写日志是为了添加、删除或修改数据的每个事务，以及响应数据库维护操作（例如索引重建或重组，统计信息更新等），将日志写入日志。即使是最勤奋的DBA有时也可能会因数据库日志文件意外地快速增长而陷入困境，因此我们将更详细地考虑日志增长。

与数据文件相比，事务日志文件无法利用即时文件初始化的优势，因此，每个日志增长事件在时间和资源上都相对昂贵。发生这种情况时，其他任何事务都将无法使用事务日志，并且数据库将是“只读的”，直到增长事件完成为止。

快速的日志增长可能是由于大规模数据或数据库修改（例如，由于索引重建，长时间运行的数据清除或归档过程）或未提交的事务（防止日志中的空间重用）而导致的。

图8显示了SQL Monitor中的分析图。我在图表上仅绘制了两个指标，一个测试数据库（MyTestDB）的日志文件总大小，以及该实例的机器处理器时间。它显示了一段爆炸性的事务日志增长时期。

图8

图9显示了爆炸性日志增长期间的服务器指标图，以及该期间运行的最昂贵的查询。

图9

在这种情况下，（人为）原因是对包含几百万行的Persons表的一系列更新。但是，在归档数据时，大规模数据清除可能会产生类似的影响。SQL Server必须将更改记录到数据的每一行，并且由于存在约束而加剧了这种情况，并且触发器加剧了问题。

例如，如果您要执行数据清除，并且表通过FOREIGN KEY设计为的约束来引用目标表CASCADE ON DELETE，则SQL Server还将记录通过级联约束删除的行的详细信息。如果表上有DELETE触发器，则为了审核数据更改，SQL Server还将记录触发器执行期间执行的操作。所有这些都会导致爆炸性的原木增长，有时甚至会破坏最辛勤的增长预测计算。

在大规模数据更改期间控制日志增长

良好的做法是小批量运行大规模数据操作，如果在下一个CHEKPOINT运行（如果数据库使用SIMPLE恢复模型），或者在下一个日志备份（如果运行），则可以在事务日志之间进行截断。 数据库使用FULL或BULK_LOGGED恢复模型。

在本示例中，MyTestDB数据库在FULL恢复模型下运行，因此仅在发生日志备份之后，才能截断事务日志并重用现有空间。在这种情况下，数据库的大小增长到超过20 GB（从最初的1 GB以下），完全是由于日志文件的增长（先前的数据文件使用情况警报未触发，因为数据文件中未使用空间）。

SQL Monitor提供了一个自定义的“大事务日志文件”度量标准，可在具有大日志（超过10 GB，但可配置）的数据库数量增加时发出警报。

如果由于某种原因阻止了日志空间的重用，则需要查询sys.databases中的log_reuse_wait_desc列，以找出原因。 这通常是由于事务运行时间长或缺少日志备份（SQL Monitor也应该提醒您！），但是还有其他可能的原因。

与不受控制的日志增长相关的问题（尤其是当日志文件配置为以小增量增长时）会导致日志碎片，其中日志在内部由大量的虚拟日志文件（VLF）组成。在上面的示例中，日志通过反复快速地增长，最终获得了超过2000个VLFS，如运行所示DBCC LOGINFO。“内部碎片化”日志可能会降低读取日志的操作的性能，例如日志备份、复制和镜像过程。它还可能减慢崩溃恢复的速度，因为SQL Server必须在开始恢复数据库之前打开日志并读取每个VLF。

设置FILEGROWTH日志的值时，您都希望避免因允许日志以小增量增长而导致的碎片化。但是不要过度使用它，因为如果将增量设置得太高，则可能会在正常的事务日志增长事件期间发生超时（由于需要对所有空间进行零初始化）。通常建议使用固定的512MB自动增长大小作为指导，但是最好了解您自己系统上的日志增长特征和行为并相应地设置自动增长大小。

总结

您可以手动设置警报，以在磁盘空间不足时发出警告，并希望及时提供更多空间以避免任何数据库“中断”。但是，这种反应性磁盘空间管理仅能带您到达目的地，因为它无法让您知道这种情况将在多久之前发生。

勤奋的DBA希望通过了解数据库文件中空间的使用速度来避免磁盘用尽的机会。诸如SQL Monitor之类的工具可以非常轻松地捕获这些数据，但是它还可以做很多事情。它分析收集到的数据以捕获数据增长趋势，并使用它们来准确预测何时您将用完空间。这使您有机会进行计划，而不仅仅是作出反应，并最大程度地减少由于文件填满或触发文件自动增长而造成的任何干扰。

监视磁盘和数据库增长数据时，随着时间的推移，您将更好地了解数据库的增长特性，并提高磁盘容量调整和计划的准确性。这样，文件自动增长事件将是一个例外，而不是正常情况，因此，您可以跟踪自动增长事件，并在事件发生时得到警告，并调查导致意外增长的原因。

本教程内容到这里就完结了，希望对您有所帮助~您可以点击下方链接查看该教程前面两部分内容，或者下载SQL Monitor试用版体验一下~

相关内容推荐：

使用SQL Monitor避免耗尽磁盘空间（上）：监视磁盘上的可用空间

使用SQL Monitor避免耗尽磁盘空间（中）：监视数据库文件中的可用空间

想要购买SQL Monitor正版授权，或了解更多产品信息请点击