Operations Manager Database - Autogrow

Hi Brian,

 

To answer your questions:

 

1. Yes, OM2007 R2 is most definitely supported by the F5 Networks Management Pack.

 

2. Our service is not directly editing the SCOM database. It actually uses the SCOM SDK to record all data.

 

3. This one is a bit stickier, but hopefully I can give you a satisfactory answer. By default Microsoft says to leave autogrow off. This is the best practice, and I stand behind that; however, the amount of data typically collected by Operations Manager that is stored in the database before being sent to the data warehouse is pretty minimal compared to the size of the database. Our problem is that our service has the potential to collect hundreds of metrics per second, whereas Operations Manager normally collects a few dozen metrics per minute. So the volume of data coming in could potentially tip over the Data Warehouse if autogrow was not enabled. That is why we enable autogrow by default, seeing as best practices had a completely different picture in mind. This was a design decision on our end to give you the most complete picture of your network health at any given time, and this doesn't mean you can't follow Microsoft's best practices, but by doing so, you will have to be a lot more conscious of your dw db size, as well as the amount of data coming in from the F5 devices. If you can balance this, you should be able to still follow the Microsoft best practices.

 

If any of this doesn't make sense, or you have more questions, feel free to ask.

 

-Dave

Thanks Dave for your reply. Only a couple points where I could use some additional clarification.

 

 

1. So you're not inserting/updating the SCOM database directly, so then why does the installer need the SCOM DB Server info? Is this just to change auto-grow flag?

 

 

2. You referred to the SCOM Data Warehouse whereas the documentation refers to the SCOM database. Do you recommend auto-grow for one, the other, or both?

 

Hey Brian,

 

So just to clarify, we aren't collecting data specifically on the SCOM DB, that is just the sql server we know to exist because of the SCOM DB. In reality, the SQL configuration page was designed to collect information for where to put our own F5 database, which stores f5 device information and some other static data. The only time we come close to touching the SCOM DB is if the autogrow checkbox is marked. Other than that, we never touch either of the Operations Manager DBs.

 

 

As far as 2 is concerned, you are correct, I referred to the data warehouse when I should have said the SCOM db. The data warehouse is actually set to auto grow by default by Microsoft on a typical deployment. So my real recommendation is to leave them as configured by Microsoft, but increase the size of the SCOM DB to prevent any issues with too much data coming in before being archived in the data warehouse. We have a lot of data coming in from the F5 devices, so as a preventative measure, we enable autogrow to prevent data loss. The most performant solution is to manually increase the DB size initially and watch to see how big it grows when the f5 devices are pumping in the statistics you want to collect and balance from there. That way you still can follow MS best practices.

Hi,

 

 

First of all, this topics is really interesting.

 

Your answers are accurate as well.

 

 

If I have understood your explanation.

 

F5 devices status are collected in the SCOM DB. Because by default the information is accurate, we might tip over the SCOM DB. Can't we anticipate the impact of the F5 device monitoring with an abacus such as Microsoft have for Servers.

 

 

Thanks.