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