Typically when tuning SCOM we talk about saving time and reducing alert noise, but today I’m going to make a quick post on saving database space through tuning. If you’d like to get an idea of what your current database usage is, take a look at this tool from scom2k7.com. This will give you a breakdown of where space is used in the SCOM Data Warehouse.

What can I tune?

Out of the box SCOM gives you some controls to tune retention settings. Kevin Holman details these on his blog, he also provides us with an average distribution we can use for the following example. Three large consumers of database space should show up in your list (as they do in our example).

• * As implied by the name, this holds the performance metric data collected by SCOM. Reducing the frequency of collection will reduce the size of the raw data. Stopping collection on a set schedule will reduce both raw and aggregated data sets.
  
  • Reductions in this data will be visible in performance graphing.
• * The event data set contains all events collected and stored for later evaluation. These aren’t collected on a frequency, and as such have no aggregate options.
  
  • Reductions on this data will be visible in the SCOM Event View.
• * Historic monitoring state changes are stored in this data set. If you have frequently flapping monitors this set will grow larger.
  
  • I would not recommend making any modifications to this data collection.

Finding what to tune

Easy Tune provides a simple CSV interface to tune SCOM workflows, but blindly tuning them isn’t going to be of much help. In the below two sections I’ve detailed some steps on finding the largest offenders of usage.

Performance data

The below SQL query is designed to be run against your data warehouse and will provide you with the 50 highest generating performance Rules, as well as the Management Pack holding them. This will give you an idea of what’s generating the most entries.