How much growth on the database

Kind of an odd question and this could get wordy so bear with me please.

The company I started with in January already had npm in house and the orion database is at 175 GB. They have since started an initiative to move the server monitoring from SCOM to SAM. That being said there are concerns about the size of the database getting out of hand from the architecture committee. Since that database is part of a cluster at some point if it grows massive enough it could impact them. So one of the recommendations is to move it to it's own server.

Without knowing exactly what I am going to be monitoring per se aside from the usual up/down drive space/cpu is there anyway to extrapolate how much would be added to the database by adding approximately 378 physical servers and

2298 virtual servers to the database other than going to random.org and arbitrarily generating a number.

Your help is appreciated as usual.

Find more posts tagged with

database storage

sam.

Accepted answers

All comments

mprobus

I am monitoring about 13K devices, mostly virtual, but some physicals. I have SAM and VMAN tied in. With that, my database is currently sitting at about 80GB after almost a year of data collection.

mesverrum

A ball park way to figure this out is to go to SQL and run the built in report on space used per table. Subtract out any space in your db being used by traps and sys logs tables since those tend to be big and are unrelated to the number of polled objects. Divide what you have left by the number of elements being monitored right now and that should give you a rough average of bytes/element. We might assume that each server would add 1 node, 1-2 interfaces, 2-10 disk volumes and an average of maybe a dozen Sam monitors, so call it around 15-20 polled elements per server.

This is a really rough estimate but will probably get you in the right ball park for the DBA to plan around.

I would also discourage you from pulling solarwinds out of the SQL cluster. Giving up the reliability and dba administrative benefits of clustering to avoid buying an extra 100 GB of disk seems counter productive in this age. If solarwinds is using enough data that they are worried then you might want to take a look at your retention settings and polling intervals and make sure they make sense. If you are polling at a higher than default frequency then cutting back the intervals by 30 seconds might make enough of a difference to calm them down with minimal operational impact.

trilobite_rex

I will give this a shot today. Thanks!

trilobite_rex

So I did this and I have my number per node. Is that keeping a years worth of data or do I need to expand that number out?

mesverrum

If your system has already been running for at least a year and your retention is already set how you want it then you are all set. The longer term tables tend not to be very large because they only have one data point per element per day, where the detail stats page would have 144 data points per day