I’ll start part 1 of the Microsoft System Center series, focused on what a SQL Server DBA should know about System Center, with System Center Operations Manager, or SCOM, with the SQL Server Management Pack. When you have licensed the System Center suite of products, you can use these different pieces or put them together in your data centers for what we are now calling a SQL Server “private cloud” that has elastic scale, maximum server consolidation capabilities, charge back capabilities, self-service provisioning, the greatest data center economies of scale and (my favorite) load-balanced SQL Server with zero downtime configurations. The SQL Server Monitoring Pack for SCOM is downloadable here and adds a very distinctive monitoring capability to your SQL Server infrastructure. Out of the box, the SCOM SQL monitoring pack can monitor all areas of your SQL Server instances and databases by using the SCOM agent on that server. This also then allows you to create SLAs and root-cause analysis that can drill down from an application or server alert that you’ve configured down to the database level all from the System Center GUI. As you can see from this health monitor roll-up diagram from SCOM below, you will be able to monitor all aspects of SQL Server including database performance and health areas including database files, long-running jobs, blocking sessions, compliance and many others:
This is similar to what you will find from 3rd party monitoring tools on the market today. I just want you to become familiar with what you can use to monitor SQL Server from System Center. As I take you through the rest of the System Center suite and its applicability to SQL Server management, you may find that the combination of monitoring, management, auditing, virtualization, etc. that the System Center Suite brings to the table may be a more compelling value proposition. I’ve also put a few screen shots below that show how SCOM can bring together your SQL Server health with the rest of the environment that System Center is monitoring from server agents (including Unix, Linux, Oracle and more) and gives you a much wider lens from which to view your overall system health. Now, having said all of that, and since I pretty much live exclusively in DBA land these days, as a SQL Server DBA, you may not want to have to look into ANY tools that are outside of your daily bread-and-butter tools like SSMS. In that case, you can set-up SQL Server with a central management and monitoring server instance using SQL Server Enterprise Edition to get visibility into just your SQL Server investments using MDW for data collection and trending, UCP for dashboards, PBM for management and SQL Audit for auditing.
5 thoughts on “System Center for the SQL Server DBA Part I: SCOM”
Reblogged this on Coffee and SQL Server and commented:
this is a great post for SCOM newbies like me. thank you!
Hi MSSQLDude, I have a lot of POS devices (windows 10 with SCOM client and SQL Server 2016 St. Ed. installed) and i can’t discover them as SQL 2016 Computers or DB Engine. Is there any way to detect them? Does SCOM support that scenario?