Image may be NSFW.
Clik here to view.
This is based on 6.6.4.0 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)
Image may be NSFW.
Clik here to view.
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)”
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
This monitor DOES generate alerts named “File Group is Running out of space”
Image may be NSFW.
Clik here to view.
This monitor rolls up health to “DB File Group Space” monitor.
Image may be NSFW.
Clik here to view.
which is an Aggregate monitor, which has a “Worst state of any member” policy. This is used for rollup only.
Image may be NSFW.
Clik here to view.
This monitor rolls up health to the “DB File Group Space (rollup)” monitor
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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.
Alternatives:
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)
Image may be NSFW.
Clik here to view.
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.