How SQL database free space monitoring works in the SQL management pack




This is based on version of the SQL MP


First – understand the SQL MP discovers the following items:

  • SQL Database
  • SQL DB File Group
  • SQL DB File
  • SQL DB Log File

The Database > hosts > DB File Group > hosts DB File.

Also - the Database > hosts > DB Log File.


Let's start with free space monitoring in the DB file, this is the lowest level of monitoring.

There are unit monitors that directly target the "SQL Server 2012 DB File" class.

The monitor for space is called: "DB File Space"   (Microsoft.SQLServer.2012.Monitoring.DBFileSpaceMonitor)




This runs every 15 minutes, and accepts a default threshold of 10% (critical) and 20% (warning). This monitor does not generate alerts - it simply rolls up state. The reason for this is because you can have multiple files in a file group for a DB, and just having a single file being full is not an issue.


Microsoft.SQLServer.2012.Monitoring.DBFileSpaceMonitor uses the Microsoft.SQLServer.2012.DBFileSizeMonitorType

Microsoft.SQLServer.2012.DBFileSizeMonitorType  uses the Microsoft.SQLServer.2012.DBFileSizeRawPerfProvider datasource.

Microsoft.SQLServer.2012.DBFileSizeRawPerfProvider datasource runs GetSQL2012DBFilesFreeSpace.vbs with the following parameters from the Monitor configuration:

"$Config/ConnectionString$" "$Config/ServerName$" "$Config/SqlInstanceName$" "$Target/Host/Host/Host/Property[Type="SQL!Microsoft.SQLServer.DBEngine"]/TcpPort$"


This script checks many configuration settings about the individual DB file - then rolls up a health state after complete.


Scenario: Autogrow is enabled

  • If autogrow is enabled for the DB file, the script checks the DB setting for FileMaxSize to be set.
  • If FileMaxSize is set - this is considered the upper limit to threshold against. (unless logical disk size is smaller than FileMaxSize)
  • If FileMaxSize is NOT set (Unlimited) then the logical disk size is considered the upper limit.

Scenario: Autogrow is NOT enabled:

  • If autogrow is not enabled, then the file size is considered the max file size and this value is used for threshold comparison.


The DB files will be healthy or unhealthy based on this calculation. Again - no alerts yet.

Next - all the discovered DB file monitors roll their health state up one level to the monitor "DB File Space (rollup)"



This is a rollup dependency monitor targeting the filegroup object, and has a "best state" rollup policy. Which means if ANY child DB file has free space, then the rollup is healthy.  That makes sense.



This monitor DOES generate alerts named "File Group is Running out of space"



This monitor rolls up health to "DB File Group Space" monitor.



which is an Aggregate monitor, which has a "Worst state of any member" policy. This is used for rollup only.



This monitor rolls up health to the "DB File Group Space (rollup)" monitor



This is a rollup dependency monitor targeting the database object, and has a "worst state" rollup policy. Which means if ANY FILE GROUP is unhealthy, we consider the DB unhealthy.


This rolls up to the "DB Space" monitor, which is an Aggregate rollup monitor to roll health to the DB object.




SUMMARY of DB file monitoring:

  • The ACTUAL space monitoring in the SQL MP is done at the individual DB file level.
  • Alerting is done at the DB File GROUP level based on a "best of" rollup.
  • Everything else is designed to roll the health up correctly from DB file to File Group, and from File Group to Database object.


Log file free space monitoring:

This works EXACTLY like DB file space monitoring, except it is less complicated because there is no concept of a "filegroup" so the log file monitor rolls up to the DB object with a single dependency monitor (rollup), which is also where the alerts generate from.




Now, if you DO use autogrow, and you place multiple DB files or log files on the SAME logical disk - the management pack does NOT take that into account, so your individual DB and log file monitors might not trigger because they individually are not above the threshold, but cumulatively they could fill the disk. This is why the Base OS disk free space monitoring is still critical for SQL volumes.  This is documented in the MP guide.




IF - for some reason - a customer did not want to discover DB files and file groups, and ONLY wanted the total database space calculated, there is a disabled monitor targeting the DB object for the DB and one for the log file. You could optionally disable the discovery of DB files and filegroups, and have a MUCH simpler design (although not quite as actionable potentially)


A customer might take this approach if they have a VERY large SQL environment, and wants to reduce scale impact by not discovering DB file groups and DB files. Additionally, this reduces all the performance collection impact which would otherwise be collecting data for all those individual objects. 

Another reason to take this approach is if you have a HUGE SQL server with a LOT of databases and DB files.  The amount of scripts running on that server could be VERY large and very impactful to the server.  You could selectively disable the discoveries for that server, run the Remove-SCOMDisabledClassInstance to clean them out of SCOM, and then enable just the smaller monitors.

If you don’t NEED monitoring of individual files and file groups, this approach makes some sense.

Comments (6)

  1. Cody says:

    I’ve seen this trigger a critical alert where a filegroup is being dropped. I’m not sure if it’s meant to auto-close but it seemed that it didn’t because the filegroup didn’t exist anymore.

  2. Martijn says:

    I keep getting alerts from this monitor where all possible ‘free space’ in db file, on disk, within reserved space are >10%. Something still is/feels wrong about this monitor.

  3. M.Mathew says:

    Had to disable these monitors, as they were generating Alerts for Db files that were set to auto grow.This was also causing lots of state changes.

  4. Very helpful!
    They changed the “DB Total Space” to an”DB Space Percentage Space”. It monitors the DB Space Change in 5 Samples x 15 minutes.
    I think a better approach.

  5. Azhar iqbal says:

    I have written a query from SCOM dbs to collect free space for All drives. I want to select only drives that has MDF or LDF files. How Can I identify those Drives into My Query.
    My query is
    select me.path as ServerName,case when c.IsVirtualMachine=1 then ‘Virtual’ Else ‘Physical’ END as ServerType,
    pd.datetime, me.DisplayName as DriveName,id.VolumeName_65571163_F69F_CFDB_49A1_2730285FD2A2 AS Label,
    [SizeInMBs_E70DED5C_3AE4_BDCD_1635_F40D15E608B7] AS TotalSize,
    [SizeInMBs_E70DED5C_3AE4_BDCD_1635_F40D15E608B7]-pd.averageValue as UsedSpace,pd.averageValue as FreeSpace,
    [SizeInMBs_E70DED5C_3AE4_BDCD_1635_F40D15E608B7]-pd.MaxValue as MaxUsed,
    [SizeInMBs_E70DED5C_3AE4_BDCD_1635_F40D15E608B7]-pd.MinValue as MinUsed,
    [SizeInMBs_E70DED5C_3AE4_BDCD_1635_F40D15E608B7]-pd.averageValue as AvgUsed ,
    pr.Countername, pr.ObjectName,id.DriveType_67A23C3E_F435_A1B1_DE3E_D8C412E6D9D5
    from perf.vPerfDaily pd
    inner join vManagedEntity me
    on me.ManagedEntityRowId=pd.ManagedEntityRowId
    inner join vPerformanceRuleInstance pri
    on pri.PerformanceRuleInstanceRowId=pd.PerformanceRuleInstanceRowId
    inner join vPerformanceRule pr on pr.RuleRowId=pri.RuleRowId
    inner join operationsmanager.dbo.MTV_Microsoft$Windows$Server$10$0$LogicalDisk id
    on id.BaseManagedEntityid=me.ManagedEntityGUID
    inner join [OperationsManager].[dbo].[MTV_Computer] C on c.DisplayName=me.Path
    where pr.ObjectName=’Logicaldisk’
    and pr.CounterName=’Free Megabytes’

Skip to main content