do more with less: sql central management server and multi-server administration

Do More With Less:

Inside SQL Central Management Server and Multi-Server Administration

Mike Hillwig

SQL Server DBA Working with SQL Server since SQL 7 Resume includes Acme Packet Oracle, Shawmut Design and Construction,

Equitable Resources, Weirton Steel

Mike Hillwig

Owned by Two Pugs Avid Cook Lover of Blue Cheese And Bacon Geek at Heart

Obligatory Social Networking Slide

mikehillwig.com sqlserverpedia.com twitter.com/mikehillwig anysocialnetworkingsite/mikehillwig

Housekeeping

Don’t let me talk too fast. Blog post at mikehillwig.com/go/domore Please send feedback to mike@mikehillwig.com

April 18, 2015Microsoft, Cambridge, MA

Beware of the Blogs

There is some amazing advice out there. But…

Anybody can put bad advice on the internet

Trust people you know

Assume I’m an idiot I don’t trust people who say

“ALWAYS” or “NEVER” Test everything in your own test

environment first.

Before I start…

This crowd scares the crap out of me. Seriously. You’re one of the most technical user groups I’ve ever seen.

With that said…

This is a new topic for me. Your feedback is incredibly important mike@mikehillwig.com

Slides and Blog Post

mikehillwig.com/go/domore

Tonight’s Topics

Central Management Server SQL Agent Multi Server Administration

Central Management Server

Catalog of Servers Allows you to synchronously query multiple servers

SQL Agent Multi Server

Centralize your SQL Agent Jobs It’s a Master/Target relationship for the SQL Agent

LET’S DIG IN

About My Infrastructure

Using a single VM named SLATE with seven instances You wouldn’t do that. These tools require AD authentication. I’m too lazy to configure a domain controller

Seven Instances

Fred Wilma Barney Betty Pebbles BamBam Bedrock

Central Management Server

It’s a catalog of servers Allows you to break your servers into categories There is nothing fancy about this technology Yet it’s a great time saver The tool you won’t appreciate until you really need it Allows you to query multiple servers synchronously at once…

without PowerShell.

Why would I Use this?

Audits (Getting lists of things on multiple servers) Deployments Security functions

Creating logins Disabling logins

Anything that you need to run on multiple servers

Demo

Important Tables

sysmanagement_shared_server_groups Contains the groups/folders

sysmanagement_shared_registered_servers Contains the servers we’ve registered.

Important Procedures

sp_sysmanagement_add_shared_server_group Adds a new group/folder

sp_sysmanagement_add_shared_registered_server Adds a new server to a group

A Note on Connectivity

The Central Management Server is just the catalog. The machine where you’re running SSMS makes the

connections to each server. If your machine can’t see a server, your connection will fail.

A Note on Security

Unless you specifically configure it to use SQL authentication, AD authentication will use YOUR login and not the server’s service account.

One more thing…

Your statements and scripts will run synchronously Do NOT expect your results to come back in a specific order The order of results appears to be the order of completion

Multi-Server Administration

Incredibly cool Incredibly powerful The most unsexy technology to come out of Redmond since

Microsoft Bob Has a few quirks Does have a few serious caveats Caveats do have workarounds

Benefits

Allows you to keep consistency with SQL Agent jobs across multiple servers

It’s a huge time saver when you need to change a script that you regularly run in your environment, such as backup scripts or index/statistics maintenance

When a job is deployed from the master server to targets, they are locked on the target. This enforces consistency.

Pitfalls

It can be quirky Be careful with security It’s a complete culture shift When you push a job to target servers, it pushes all of the

properties, including the schedules. Be careful with IO-intensive jobs!

Turning That Around

You can still deploy the job without a schedule Then create a job that uses msdb.dbo.sp_start_job This allows you to leverage the benefits of a centrally

managed server while using the schedule of a local job

Demo

Notable Tables

sysjobs – All of the jobs you have defined, both local and Multi-Server Jobs

systargetservers – Shows all of your target servers sysjobservers – Shows what jobs are deployed to what

servers

Notable Procedures

sp_help_targetserver – Run from the master, shows all of your target servers Status of 5 means you have a process that is preventing you from

downloading instructions Shows much of the data in systargetservers

A Note on Connectivity

This uses the connectivity between servers, not your machine’s connectivity

The pushing of SQL Agent job updates is done on a regularly scheduled polling process

A Note on Security

Be very careful with security on this If you do this wrong, you could set yourself up for issues If users can manage SQL Agent jobs on your master servers,

they can deploy jobs to your target server, even if they don’t have access to that server

Jobs on the target run in the context of the target server’s service account

If you have segregation of duty issues, be very careful who you give access to your master server

Wrapping Up

CMS and MSX are very different technologies Different capabilities Different use cases Combining the two gives you a great set of tools

One more thing…

Neither CMS and MSX allow the main server to manage themselves

Put both of these tools on an independent box