彩票走势图

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

点击下载SQL Monitor免费版

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

如果您的SQL Server磁盘空间不足，并且正在为企业的贸易应用程序运行数据库，那么在DBA解决该问题之前，该公司是无法赚钱的。即使担心这种情况的发生，也足以使DBA夜不能寐。因此，磁盘空间管理仍然是DBA面临的一大管理挑战。

当然，很少有数据库突然用完空间的。如果您知道数据库的增长速度以及存储的可用空间的变化，通常这是可预见的事件。因此，监视这些指标并设置警报，在以下情况提醒：

• 可用磁盘空间下降到阈值以下

• 数据库文件中未分配的空间低于阈值

• 数据库文件的大小实际增长

通过监视每个指标，您将首先减少由于“意外”用完磁盘空间而导致的所有计划外停机；可能对DBA的职业产生不利影响的事件。其次，您将增加可用的反应时间。如果您可以预测何时需要增长数据库，则可以安排维护时间，以增加容量，从而对数据库的业务影响降到最小。它还可以帮助您避免在可能阻止和破坏重要业务流程的不可预测的时间发生文件自动增长。最后，您还可以调查并解决可能导致数据库过度增长的任何问题。所有这些将减少对业务流程的干扰，并大大减少在临时磁盘空间管理上花费的时间。

监视磁盘上的可用空间

如果数据库的数据文件填满了分配的磁盘空间，并且无法增长，则会看到声名狼藉的1105错误，并且该数据库将是只读的，直到有更多可用空间为止。如果事务日志文件已满，并且无法增长，则会看到同样臭名昭著的9002错误。如果它在数据库恢复期间发生，这又将SQL Server置于只读模式或“资源挂起”模式。

这些对于组织来说，可能是灾难性的事件，因此DBA需要完全避免它们。因此，如果需要，他们必须监视保存数据库数据和日志文件的磁盘卷上的可用空间，并确保有足够的可用空间来增长文件。

他们还需要监视存储数据库备份和日志备份的磁盘卷上的可用空间，以避免发生备份失败的可能性，因为备份失败会在需要时损害其恢复数据库的能力。

临时磁盘空间跟踪

有多种方法可以使用TSQL来获取有关剩余可用空间量的数据。您仍然可以使用古老的xp_fixeddrives存储过程，该过程只会告诉您每个驱动器上有多少可用空间。但是，sys.dm_os_volume_stats动态管理功能提供了有关实例中每个数据库中容纳每个文件的各个磁盘卷中可用空间的更多信息。另外，有许多已发布的脚本显示了如何使用PowerShell跟踪磁盘空间。

DBA可以编写一些脚本来跟踪磁盘空间使用情况，并将警报设置为在磁盘接近满容量时触发。每次脚本运行时，他们甚至可以使用Excel将收集的数据保存到中央存储库中的表中，以进行趋势分析。但是，这种“手动”数据收集和分析虽然对于小型操作而言可能很简单，但随着SQL Server数量的增加，维护变得越来越困难。这是诸如SQL Monitor之类的工具不可估量的地方。

活动磁盘空间监控

当然，SQL Monitor提供了一个内置的磁盘空间量度和警报，当使用的磁盘空间超过阈值百分比值或可用磁盘空间低于阈值量（以MB或GB为单位）时，将向团队发出警告。

这应该给DBA一些“喘息的空间”，以安装更多的磁盘容量，或在当前磁盘卷中提供更多的可用空间。但是，当将其应用于监视较大的数据库和许多SQL Server的需求时，这仍然感觉像是一种被动且耗时的方法。

在SQL Monitor 9和更高版本中，可以使用“资源”菜单中的“磁盘使用情况”页面来监视所有服务器上的磁盘空间使用情况并计划容量要求。摘要图显示了受监视区域中当前的总磁盘容量，以及磁盘空间使用的最近增长。它还预测了未来几个月的增长趋势。您可以按服务器组（例如“生产”或“测试”）或磁盘卷来过滤此图中以及该页面其余部分中的数据。您也可以简单地通过输入服务器名称来过滤数据。

图1

在该图的右侧，您将看到一个Estate摘要（未显示），该摘要为您提供了相关数据，并在增长预测范围内警告所有超出其容量的磁盘卷。在该图的下方，您将找到一个列表，该列表可以细分每个受监视的SQL Server实例上的磁盘空间使用情况。图2显示了我们有一个群集SQL Server实例，该实例正在迅速用尽其可用磁盘空间。

图2

在此，管理团队迫切需要解决的问题是可能需要分配更多的磁盘空间，以避免计划外的停机时间。但是，他们还需要调查哪些文件（与数据库有关的文件或其他相关文件）正在占用磁盘空间。

最大的数据库是什么？它们生长异常迅速吗？如果是这样，为什么？通过单击任何磁盘，团队可以查看该磁盘上空间分配的详细信息。图3显示了F：驱动器的故障，图2告诉我们在2个月内可能就满了。

图3

在这种情况下，对数据库文件的空间分配发生了几次大的跳跃，结果是现在已分配了1.9 TB磁盘上超过1 TB的空间。但是，使用的空间只有400 GB。在图表下方，我们获得了每个数据库当前大小的详细信息以及卷上的日志文件以及每个数据库中使用的空间。

图4

我们可以看到，两个数据库（BIDataCache和ODS_LOB）占用了400 GB的大部分使用空间。ODS_LOB的主要数据文件已接近满，需要尽快重新增长。已使用空间和已分配空间之间的巨大差异主要由BIDataCache文件大小和使用情况来解释。看起来数据和日志文件的大小都大大增加了，日志文件随后被截断了，这解释了为什么分配了250GB但只使用了1.1GB的原因。这些数据是深入研究这些数据库的增长和活动的有用的起点，并且我将在本文后面解释如何监视数据库的增长。

有时，数据库文件根本没有占用空间。可能具有服务器访问权限的“流氓”开发人员正在将临时备份存储在同一磁盘卷上，或者ETL进程无法执行其内务处理。

无论哪种方式，团队越早意识到即将出现的磁盘空间问题，他们就有更多的时间来调查原因并计划响应。

本文内容就是这样了，想要了解该教程后续内容，请继续关注我们哦~您也可以下载SQL Monitor试用版免费评估~

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