Buscar
  • Ignez Mello

Executar scripts em vários servidores ao mesmo tempo

Quando você administra vários servidores, de um ou de vários clientes, a necessidade de rodar o mesmo script em vários deles é algo normal no nosso dia a dia.


Então, que tal conseguir executar esse script apenas uma vez, em todos os servidores, ao mesmo tempo?


Parece um sonho, não é? Mas é a nossa realidade neste artigo ;-)


O SQL Server, a partir da versão 2008, tem uma funcionalidade chamada Central Management Servers (CMS), que nos permite administrar várias instâncias ao mesmo tempo. Agora, se você acha que esta funcionalidade é exclusiva para os DBAs... Pense de novo! É possível configurar o CMS para usuários no modo somente leitura. Imagine um desenvolvedor que conseguiria executar uma consulta na instância de Desenvolvimento, Homologação e/ou Produção ao mesmo, e comparar seus resultados. Quer melhor maneira para se tornar seu melhor amigo?


A configuração do CMS é muito simples:

  1. No SQL Server Management Studio (SSMS), clique no menu View e selecione Registered Servers.

  2. No Registered Servers, expanda Database Engine, clique direito sobre Central Management Servers. Dependendo da versão do SSMS que você está usando, selecione New e clique em New Server Group, ou selecione Register Central Management Server

  3. Na janela de registro, selecione a instância do SQL Server que você deseja transformar em servidor central de gerenciamento central na lista suspensa de servidores. Você deve usar a Autenticação do Windows para o servidor central de gerenciamento. Eu escolhi minha instância CDBA\SQL2017.

  4. Clique direito sobre o grupo CMS que você criou (no meu caso CDBA\SQL2017), e selecione New Server Group. Digite o nome e a descrição e confirme. Vou usar WORK.

  5. Clique direito sobre o grupo WORK, e registre os servidores que você quer incluir nesse grupo. Eu vou cadastrar todas as instâncias de SQL utilizadas pelas equipes de desenvolvimento, homologação e QA.

  6. Depois de registrar todos os grupos e instâncias, o CMS estará pronto para executar consultas em todos os servidores do grupo ao mesmo tempo.

Após cadastrar meus grupos, o CMS ficou assim:


A organização dos servidores fica a gosto do DBA. Você pode criar um servidor para cada ambiente, para cada empresa (cliente) que atende, por ambiente, por versão de SQL. Ao criar o grupo, sempre leve em consideração que scripts você precisa rodar e quais servidores devem ser afetados. Essa ideia ajuda a organizar os grupos.


Ok! Agora vamos ver o CMA funcionar!


Primeiro, clique direito sobre a pasta WORK e selecione New query. Aqui já vemos que as coisas mudaram um pouco. Observe o canto inferior esquerdo da janela de query. Esta janela está conectada em 3 de 3 servidores.


Vamos tentar um comando simples: SELECT @@VERSION

O retorno da consulta sempre trará a coluna Server Name, para identificar de onde veio o resultado.


Vamos a outro exemplo. Nós sabemos que todas as instâncias SQL Server tem o BD MSDB, então vamos consultar as tabelas:


E se eu usar ORDER BY 2, que é a coluna com o nome das tabelas?


O erro aconteceu porque o SQL Server não considera a coluna Server Name como parte da sua consulta, até porque a lista de colunas do SELECT só tem uma, não é?



Configuração de grupos de acesso para o CMA


Como eu comentei anteriormente, o CMA pode ser usado por qualquer usuário do SQL Server. Vamos precisar configurar duas permissões diferentes, para dois usuários e/ou grupos diferentes, um com permissão de administrador e outro com permissão apenas para leitura. Vamos usar dois novos roles:

  • ServerGroupAdministratorRole - perfil de administrador

  • ServerGroupReaderRole - perfil de consulta


Para os usuários em geral, o login deve usar o role ServerGroupReaderRole:


Para usuários administradores, é só substituir o role ServerGroupReaderRole por ServerGroupAdministratorRole no script acima.


E agora?


Agora, você pode rodar qualquer script que precisa nos servidores do grupo:

  1. Scripts para verificar tamanho de objetos, locks, logins.

  2. Scripts de auditoria.

  3. Scripts de validação de execução de jobs.


Lembre-se que o script que você rodar deve funcionar em todos os servidores. Caso contrário, o SQL retorna o resultado dos servidores que ele conseguiu executar, e erro naqueles que não conseguiu.


0 visualização