If you manage a server where you are not in complete control of the creation of databases, or you’re unfamiliar with what settings to change, you may miss things out or set them incorrectly. This metric could pick up on issues that affect performance in obscure ways, and saves you having to search for them when a system suddenly stops performing as you would expect.
The settings here are not a complete list and the values attributed to them are not necessarily how you may choose to have them. They are provided as examples of how to test for settings and how to attribute a severity to the setting. A higher value indicates a setting that you are more interested in, ensuring it meets your own best practice.
Performance-related database settings
Checking database settings that are often performance related.
The T-SQL query that will collect data
Instances to collect from
Choose the instances where this is important. Possibly this could be your development instances. Catching the issues early in development will prevent a lot of issues reaching your live systems. If you are concerned about your production databases getting settings altered then include them too.
Databases to collect from
Use collected or calculated values
Leave the Use a calculated rate of change between collections check box unchecked
Database settings alert
Raise an alert when the metric value goes
Above the defined threshholds
Default threshold values
Note: These thresholds are intended as guideline values. If they seem too high or too low for your environment, replace them with values more suited to your server performance. The alert thresholds depend on how strict you want to be and how you set the values in the TSQL. High, medium and low variables should relate to your database settings. For example, if you have the @Low value set at 10, then 5 of these features will trigger this alert. If you set this too high then you may miss the more important settings.
Raise an alert when the threshold is passed for