Por: Fabio Oliveira & Luis Ramirez

Nesta área, notamos um pouco de confusão sobre como o aplicar atualizações no SQL Server , e acredito que seria bom esclarecer este ponto com vocês.

Vamos começar dizendo que o pacote de serviço (Service Packs - SP) e as atualizações cumulativas (Cummulative updates - CU) para o SQL Server se comportam da mesma maneira.

Ao contrário de patches do sistema operacional, essas atualizações são, por exemplo, não por servidor. Ao executar o instalador este irá mostrar as instâncias em execução no servidor e o usuário vai se preocupar em escolher em qual instancia deseja instalar o patch de atualização.

Exemplificando, se o servidor SQL em execução possui três instâncias em níveis diferentes de patch (SQL 2005):

image

Se você deseja atualizar, apenas a instance2 para SP3 (9.00.4035), irá executar o instalador do Service Pack no servidor, levando em consideração o fato de executar o instalador não garante que as três Instâncias serão atualizados a este nível, mas o administrador do banco de dados que está efetuando a instalação deve selecionar apenas a instance2 , e está será a única instância que irá se atualizar para o no SP3 (9.00.4035), deixando as outras instâncias na mesma build que estavam antes de iniciar o processo de instalação do SP3 na Instance2. Veja abaixo como ficariam as instâncias após a aplicação do SP3.

image

Para o SQL Server cada instancia é como se fossem um servidor, mas por que isto funciona desta maneira? Porque para alguns clientes é importante manter níveis diferentes de build, pois é necessário manter a compatibilidade com as aplicações e ou segurança em ambientes específicos.

Em um cluster se aplica o mesmo conceito, mas notando que os patches são "cluster aware", isto é quer dizer que o patch que será aplicado irá reconhecer todo os nós envolvidos no ambiente de cluster e irá efetuar a atualização em todos os nós com somente uma única execução. A recomendação é que a instalação do patch deve ser iniciada no nó ativo, e então o instalador irá começar a atualizar os “binários” nos nós passivos para que em caso de sucesso na instalação no nó passivo o instalador possa então iniciar a atualização do nó ativo, atualizando seus “binários” e também os objetos dentro do banco de dados.

Seguindo o exemplo acima:

Temos um cluster de dois nós com três instâncias, instance1 e insntance2 ativas no Servidor_A e instance3 ativa no Servidor_B

image

Digamos que você precisa atualizar a instance3 com SP3 (9.00.4035).

Devemos executar o instalador no Servidor_A (onde instance3 está ativo), e neste momento é o mesmo que um servidor "stand alone" não quer dizer que se executarmos o instalador no Servidor_A significa que TODAS as instâncias neste servidor (ativo ou não) serão atualizadas e será os instalador será o responsável por atualizar e seguir o mesmo procedimento de instalação no Servidor_B.

O procedimento de instalação como explicado anteriormente é o seguinte, após você selecionar a instance3 .:
O instalador irá executar a instalação no nó que se encontra Passivo, ou seja, no Servidor_B, e após finalizar a instalação e atualização do “binários” no nó passivo do cluster o instalador irá iniciar o processo de instalação e atualização de “binários” e objetos do banco de dados no nó Ativo, ou seja, no Servidor_A e ao finalizar a instalação do service pack 3 somente a instancia3 que foi a qual escolhemos durante o inicio da instalação será a única instância com a build 9.00.4035 deixando as demais instâncias dos servidores envolvidos no cluster com as mesmas builds que estavam antes do inicio da instalação como mostra a figura abaixo.

image

Lembre-se:

  • As ferramentas clientes do SQL Server como Management Studio, Business Intelligence Server Development Studio, etc, devem ser atualizadas de acordo com a build em que irão gerênciar, devemos sempre levar em consideração que o SQL Server e suas ferramentas são “Backward Compatibility”, ou seja, ferramentas mais novas podem administrar bancos mais antigos, mas o contrário não é verdadeiro, portanto sempre mantenha as ferramentas com a ultima build disponível.
  • Nós sempre recomendamos que você deve efetuar suas atualizações em um ambiente de teste antes de ir para o ambiente de produção, para avaliar o impacto que esta modificação possa ter.
  • Sempre efetue uma cópias de segurança(Backup) antes de qualquer modificação em seu ambiente de banco de dados.
  • Execute os patches com uma conta que tenha privilégios de local admin e SysAadmin do SQL.
  • Algumas vezes é necessário reiniciar os serviços e / ou servidor do SQL Server.

 

Mais informações: