Cross Post: SCOM & SQL – Which Came First?

The causality dilemma ‘The chicken or the egg’ is known to everyone. And even today it can lead to some good discussions. And after a few beers it can end up quite hilarious…

With SCOM & SQL one could almost ask the same question. However here one thing is clear: Without SQL there is simply NO SCOM. And without SCOM, many SQL instances happily exist. So this isn’t a really dilemma.

Maintenance please!
However, as it’s evident SCOM requires SQL in order to simply function, it goes without any question that the very same SCOM SQL databases need to be in top notch condition. When there something amiss, rather sooner than later you’re going to notice it in the overall performance of SCOM for instance.

Out of the box SCOM 2012x already runs a some maintenance jobs against it’s own databases. It’s important to know EXACTLY what these jobs do and what tables are touched. Because when you don’t and your DBA’s are doing the same, it will work counter productive, resulting in a various set of SCOM issues.

Some explanation is required…
Gladly Kevin Holman has rewritten a blog posting he published some years ago. In that blog posting he wrote about the maintenance jobs SCOM 2007x performs out of the box.

The new updated posting is all about these jobs executed by SCOM 2012x. So ANYONE running a SCOM 2012x environment this posting is a MUST read. And don’t hesitate to discuss it with your DBA’s.

Thanks Kevin for sharing it with us. Much appreciated.