How SQL database free space monitoring works in the SQL management pack
This is based on 188.8.131.52 version of the SQL MP
First – understand the SQL MP discovers the following items:
SQL DB File Group
SQL DB File
SQL DB Log File
The Database > hosts > DB File Group > hostsDB 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 runsGetSQL2012DBFilesFreeSpace.vbswith the following parameters from the Monitor configuration:
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 rollupdependency monitortargeting the filegroup object, and has a“best state”rollup policy. Which means ifANYchildDB filehas free space, then the rollup is healthy. That makes sense.
This monitor DOESgenerate alertsnamed“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 ifANY FILE GROUPis 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.