SQL Server 2005, Upgrade ou Migração?

Esta é a primeira coluna de uma série que vou apresentar sobre o SQL Server 2005. Irei intercalar com outros assuntos para que a leitura seja mais “leve”. O tema inicial “Upgrade ou Migração” foi inspirado em uma excelente palestra que assisti no Microsoft TechED Brasil realizado no começo de dezembro em São Paulo, apresentada por José Ricardo Ribeiro, “Regional Program Manager” do SQL no Brasil.

Este é para mim um assunto “quente”, pois como servidor de banco de dados é aplicação “missão crítica”, fazer a mudança de versão exige um grande cuidado e atenção. Em colunas futuras irei abordar outros aspectos do SQL Server.

[singlepic id=8161 w=320 h=240 float=]

A Microsoft afirma que a versão 2005 tem vantagens nas áreas de gerenciamento, disponibilidade, performance, escalabilidade e segurança. Perfeito, então por onde começo?? Conceitualmente existem dois caminhos distintos, o Upgrade e a Migração.

: é o caminho mais “natural” e intuitivo. Excuta-se o SETUP.exe do aplicativo e depois de algum tempo tudo está “novo”. A “instância” do SQL existente é atualizada, bem como todos seus dados. Dessa forma a própria instância não tem seu nome modificado. Como a atualização se dá no próprio servidor original, todos os aplicativos que acessam aquele banco de dados jamais perceberão que este foi alterado e tudo funcionará de forma transparente.

Migração : é o caminho mais “longo”, mas não necessariamente o pior. Tudo se inicia com a instalação de uma nova instância de SQL Server no mesmo servidor ou em outro servidor. Para este exemplo imagine no mesmo servidor. Assim as duas instâncias convivem lado a lado. Todos os objetos (escolhidos) são copiados para a nova instância. Aplicativos devem ser alterados para se conectarem à nova instância (ou novo servidor)-exige manutenção dos aplicativos.

Sem analisar muito parece que o UPGRADE é muito melhor. Mas não é sempre assim. Como tudo na vida há vantagens e desvantagens. O Upgrade é mais fácil e dá menos dor de cabeça, bem como não é preciso mudar as aplicações. Por outro lado a MIGRAÇÃO objeto por objeto (cada database) proporciona muito mais controle sobre o processo, permite a convivência das duas estâncias lado a lado para verificações e o sistema não terá “downtime” durante o processo, mas as aplicações deverão ser modificadas para usarem o novo banco de dados.

Qualquer que seja o processo existe um passo inicial que SEMPRE deverá ser seguido : planejamento e utilização do Upgrade Advisor Tool . Esta ferramenta (disponível no site da Microsoft clique aqui ) executa uma intensiva investigação no servidor e bases de dados selecionadas visando antecipar problemas e apresentando links para documentações que ajude a resolver os pontos de incompatibilidade. Para se ter idéia de como é rigoroso o Upgrade Advisor, até as triviais tabelas de exemplo do SQL como PUBS apresentam algum tipo de alerta. Os problemas e avisos reportados dizem respeito ao uso de recursos que não são recomendados no SQL 2005, que serão descontinuados em versões futuras ou mesmo um pequeno grupo de recursos não suportados. Há sugestões que são impeditivas para a instalação (têm que ser tratadas antes) e outras que podem ser atendidas a qualquer momento (antes ou depois) como por exemplo, uso de databases em pastas compactadas (eu tinha um caso assim no meu servidor de testes). Há outros tipos de casos interessantes. Eu tentei fazer a migração de uma base de dados usando o novo recurso “Reporting Services” e fui recomendado a não seguir em frente até que instalasse o IIS (servidor Web) naquela máquina pois sem ele o recurso não funcionaria.

[singlepic id=8162 w=320 h=240 float=]

[singlepic id=8163 w=320 h=240 float=]

Eu concordo com a recomendação da Microsoft de utilizar SEMPRE o Upgrade Advisor, seja para Migração ou Atualização. Isso evitará surpresas, melhora a eficiência do processo, analisa as instâncias anteriores (somente SQL 7.0 ou SQL 2000), fornece um relatório completo com os problemas detectados e fornece o caminho para resolver todas as pendências. Isso se torna muito importante, pois, por exemplo, alguns tipos de pacotes DTS (Data Transformation Services) podem requerer ajustes antes da operação ou mesmo serem reescritos. Fica fácil perceber como é importante saber disso tudo

Uma outra forma mais manual, e bem controlada de executar o processo é usar o Upgrade Advisor, verificar pendências e depois usar o novo recurso “COPY DATABASE” que transfere de uma outra instância ou de outro servidor um database completo, incluindo permissões e logins (isso não era possível na versão anterior).

Há um conjunto de ações recomendadas para serem efetuadas antes do processo:

– Backup dos dados

– Notificar os usuários do processo

– Instalar o último Service Pack do SQL Server

– Ler a documentação do produto

– Executar o Upgrade Advisor

Outra dica que parece óbvia é LEIA O ASSISTENTE COM MUITA ATENÇÃO. Muita gente tem o hábito de ativar o programa SETUP.exe e somente clicar a famosa seqüência NEXT, NEXT, NEXT, NEXT… Numa dessas uma informação ou pergunta CAPITAL para o processo pode ser feita (como por exemplo avisar que o Reporting Services não vai funcionar por causa da falta do IIS) e ao passar “batido” só bem depois isso será percebido.

Uma visão interessante do processo de UPGRADE e a disponibilidade do SQL que pode ser vista na figura abaixo :

[singlepic id=8164 w=320 h=240 float=]

Em meus testes e efetuei os dois processos, atualização em um servidor e migração em outro. Embora menos automático eu me senti mais à vontade com o processo de Migração pois este me permitiu analisar caso a caso cada banco de dados. Além disso, o maior controle (por permitir fazer um a um) foi um diferencial. Como eu quis testar algumas aplicações, seus comportamentos em cada instância com cada versão do SQL (performance e compatibilidade) a migração foi melhor para mim. Mas reconheço que em ambientes controlados que já foram intensamente analisados e que precisem ser distribuídos em larga escala (rede de lojas de varejo que use SQL por exemplo), uma vez aparadas as arestas, o processo de UPGRADE é muito melhor. Outro cenário muito interessante é a possibilidade de troca de servidor, pois assim se utiliza o processo de migração para o novo servidor, todos os testes podem ser feitos e no final o servidor assume o lugar do primeiro (IP, nome de máquina etc.) e tudo está pronto.

[singlepic id=8166 w=320 h=240 float=]

Veja na figura abaixo o exemplo do uso da mesma base de dados nas duas versões do SQL na mesma máquina. O “velho” Enterprise Manager e o novo SQL Server Management Studio.

[singlepic id=8165 w=320 h=240 float=]

Seja um banco ou uma empresa comercial o banco de dados é vital para a organização. Por isso planeje a ação. Tenha um roteiro muito bem definido, passo a passo para executar o processo. O ideal é testar o processo completo antes de executar o plano, se possível com um ambiente paralelo, bases de dados reais, servidores com os mesmos nomes (outra rede) etc.

Futuramente mais colunas sobre o SQL 2005.

Outras referências para consulta:

WebCasts

www.microsoft.com/events/series/technetsqlserver2005.mspx www.microsoft.com/sql/community/webcasts.asp

Laboratório Virtual

SQL Server 2005 Home Page

SQL Server 2005-White Papers em