Drew Salem (4/21/2009)
That completely passed me. I was asking Steve Jones of SQLServerCentral.com what I should call the artcles and he suggested using the acronym. I hope people haven't thought that was deliberate :w00t:
What's SCOM like to use generally?
Drew
SCOM has a painful learning curve, partly because of poor documentation. Its greatest strength is the ability to "detect" new SQL instances, databases, servers etc. and automatically add those to the monitoring process. For example, if one wants to check for failed jobs, all one has to do is write a script to configure all jobs to write to the Event Log on failure. The script is deployed ONCE and can be targetted to ALL sql instances in the environment, without having to reference them by name. Every computer on the domain, in which the SCOM agent is installed, will pick up and run that script on a pre-configured schedule and alerts will be sent out when jobs fail. The failures are also listed on the SCOM console.
The strength of your solution is primarily in the reporting aspect. SCOM is somewhat lacking there.
There are ways to also customize the type of information to gather using SCOM. I wrote an article some time ago on this subject:
http://www.sqlservercentral.com/articles/Blocking/64038/
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]