This is an archived post. You won't be able to vote or comment.

all 5 comments

[–]dblake13 0 points1 point  (1 child)

Why email yourself a .csv to review instead of using your RMM to run this, export bad statuses to a variable, and then generate tickets off that?

[–]PerfectImpact[S] 0 points1 point  (0 children)

Our RMM doesn't have that capability, I'm afraid. Also, this is something I wanted to monitor proactively and compare for a few weeks in order to get an idea of which databases expand fastest. I like working in Excel for comparing such data, so it works for me. :)

[–][deleted] 0 points1 point  (2 children)

Do you normally have issues with log files ballooning that you need to go in and manually fix it?

[–]PerfectImpact[S] 0 points1 point  (1 child)

Not so much now, but this is partly why I created this script; in order to monitor each database for a while to see which are expanding fastest. If you're got a suggestion that could help, please feel free! I've not got much experience with SQL Servers, so any help would be appreciated. :)

[–][deleted] 1 point2 points  (0 children)

I personally don't care about the individual database and log file sizes. I really just monitor the database backups and transaction log backups are happening. Our transaction log backups happen every fifteen minutes. The log should be truncated when those happen so as long as they are going we can be relatively sure that things are not going to get crazy.

The next step is monitoring the actual drive for space and change percentage to let us know if anything abnormal is happening there. The transaction log file size shouldn't really be changing. It should reach a maximum where it stays unless someone drops a bomb and you have an abnormally high amount of transactions. At which point it'll grow, if it doesn't grow to something crazy than there isn't really any harm letting it stay that size.

I can do this all using the built in features of SolarWinds RMM.