Instalação de Service Packs e Atualizações Cumulativas em MS-SQL Server 2005
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):
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.
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
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.
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.