While looking at the database sizes in the new Operations Manager 2007 Performance and Scalability Guide it struck me how large the reporting database could become. More so as I am working with a client on MOM 2005 at the moment to try and tame the reporting database which is up to 500 GB.
This database had the Summary Reporting MP installed so it was aggregating the data but also keeping the raw data. So it was a case of changing the grooming parameters and dropping them down slowly so as not to knock out temdb and impinge on other jobs. A good pace to start is Pete’s post which then links off to good stuff by Marcus Oh on the DTS task and grooming and summary reporting.
Marry that with Kevin Holman’s MOM 2005 SQL queries and you can sort it all out. But slowly.
With 2007 the aggregation happens automatically so you don’t have to worry about it (so much anyway). And the report on the DW is superb. When I first saw it I thought “why can’t more reports be like this” and secondly “how did they do it?”.
Of more concern to me was what value the reports will give the organisation given that they may have to have a database of a few terabytes (plus the capacity to back it up). Organisations have mixed feelings about reports. Some think they may be useful but are more concerned with alerting. Managers seem to be keener on having the reports but are sometimes not sure what they actually want. And some people think it is a magic bucket that you can pull out details of any server over ant time period and give exactly what you are looking for whatever that may be. If only.
If you are not running the reports or even if you are running them but not doing anything with them why do you need reporting especially as it takes up a lot of space?
I would like to see an easy way for OpsMgr (the product group won’t go back to 2005) to show what counters are associated with each report (not having to scan through docs!). A tool that shows the list of reports with the associated counters and you just highlight the report you are not interested in and it creates an override for all those counters. It also knows that if the counter is used in another report it won’t override it until it is the last instance. No point in collecting something you will never use. Even better would be after you switched the rules off a dialogue asking if you would like to delete all those counters from the reporting database so it cleans it up for you without having to mess around with SQL yourself. After all you may not be sure you wanted that report until it collected data but then decided it was not needed. This would help tame the reporting database size. Next version perhaps?