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正版授權，或了解更多產品信息請點擊