O que devemos ficar atentos em uma Migração (ONPREMISE) de um ambiente SQL Server?

Tempo de leitura: 6 minutos

Fala Galera,

Espero que estejam todos bem.

No post de hoje vou falar sobre um assunto muito importante no dia a dia de um DBA no meu ponto de vista:

“O que devemos ficar atentos em uma Migração (ONPREMISE) de um ambiente SQL Server?”

Bom, primeiramente é importante saber ponderar algumas questões e os motivos que te levaram a migração.

• Você deseja atualizar a versão do seu SQL Server?
• Está migrando para um Hardware mais potente? Os dois? Sim? Não?

Tendo essas questões esclarecidas, seguem algumas considerações que poderão te guiar.

• Downtime

Para seguir com o seu planejamento você deve ter as respostas para as seguintes perguntas :

• Temos janela para migrar?
• Quanto tempo podemos ficar parados durante a migração?

Dependendo da sua resposta existem estratégias que podem ser feitas na camada do banco para minimizar o tempo de “downtime” da virada, abaixo vou falar sobre algumas opções bastante utilizadas.

Backup/Restore – Essa é a forma que eu vejo sendo mais utilizada por aí e a mais simples de se fazer também. Nesse formato, normalmente opta-se por fazer um Backup Full no momento da virada e/ ou Full + Diff dependendo do tamanho do banco e política de Backup do ambiente. No ato da migração, geralmente coloca-se as bases no servidor de origem em modo somente leitura (read-only) ou offline e restauram essas bases no novo servidor.

Esse cenário também pode ser feito seguindo uma estratégia de Backup/Restore point in time, por exemplo, considerando restaurar uma cadeia hierárquica de Backup, Full + Diff + Logs , enfim, cabe a você escolher a melhor estratégia.

Log Shipping – Conhece essa funcionalidade?  Ela é uma Feature bem antiga do SQL Server que funciona como uma estratégia básica de Disaster Recovery, além de servir para outras coisas, como validar se o seu Backup de LOG está integro, por exemplo.

Esse processo ocorre basicamente por meio de Jobs automatizados que fazem o backup (na sua instância de origem) e posteriormente o restore das peças de log no seu servidor de destino em um intervalo de tempo ajustável (O Default é cada 15 minutos). Já utilizei em alguns lugares o Log Shipping para o planejamento de algumas migrações e funcionou muito bem!!!

Resumidamente, o que você vai fazer aqui é configurar a sua replicação Log Shipping, e no ato da sua virada, você vai “quebrá-la” , definindo a sua base de destino para o modo “Recovery” no novo servidor.

Imagine a situação, você deixa tudo previamente preparado e suas bases replicando com o Log Shipping, na data da virada, só vira a “chave” para o novo servidor, muito show né? ?

Obs.: Existem diversos artigos ensinando a configurar essa funcionalidade, caso queiram que eu traga esse assunto aqui, deixe nos comentários ?

Há situações que essa solução se aplica muito bem e outras nem tanto. Aqui também cabe a você mensurar se vale o esforço. Por exemplo, se seu ambiente tiver poucas bases e elas forem muito pequenas, talvez não seja viável adotar esta solução.

AlwaysON Availability Groups – Essa é a feature mais robusta em termos de Disaster Recovery e Alta Disponibilidade presente no SQL Server que também pode ser utilizada como estratégia de migração. A replicação ocorre praticamente em tempo real e você pode fazer um “Failover” no ato da virada, direcionando seus grupos de disponibilidade para o servidor de destino. Porém, só recomendo utilizar com essa finalidade a partir da versão do SQL Server 2017 para frente no qual é possível você configurar os grupos de disponibilidade sem a obrigatoriedade de um CLUSTER vinculado.

Essa parte da configuração do Cluster, validações etc., só deixaria o seu processo de migração mais trabalhoso a menos que isso já estivesse mapeado no seu planejamento.

Database Mirroring – É uma feature antecessora ao AlwaysON Availability Groups que está em “deprecated” mas que ainda funciona até os dias atuais e basicamente fornece um espelhamento do seu banco de dados (praticamente) em tempo real que também pode ser utilizada como estratégia de migração.

• Estratégias de Migração

Inplace – Sua migração será feita InPlace?

– Mas o que é isso Homem?

É fazer a atualização do seu SQL Server ou efetuar a instalação de uma nova instância a partir do seu próprio servidor.

Existem certos riscos nesse formato, pois iremos trabalhar diretamente com a atualização dos binários do SQL Server. Eu já vivenciei certa vez um cenário em um cliente no qual ao aplicarmos o assistente de instalação, ocorreram erros durante a atualização e precisamos fazer rollback de tudo e planejarmos a virada de outra forma.

Ahh Gustavo, mas então quer dizer que isso não funciona?

Veja, não foi isso que eu disse. Isso pode variar de ambiente para ambiente, o que ocorreu no seu servidor e uma série de outros fatores. No meu ponto de vista é um pouco arriscado trabalhar com a atualização Inplace, pois você estará atualizando os binários do SQL Server e se algum arquivo de instalação estiver danificado ou corrompido o processo de rollback pode ser irreversível.

Dica: Se optar por esse formato e estiver trabalhando em ambientes virtualizados, faça um snapshot e/ou Backup da sua máquina virtual, ou se o seu servidor não for virtualizado, tenha sempre em mente um plano B.

Seguem dois artigos de problemas que vivenciamos na Power Tuning aplicando atualizações InPlace :

https://gustavolarocca.com.br/como-corrigir-erro-no-pacote-vs-shell-em-atualizacao-in-place/

https://luizlima.net/casos-do-dia-a-dia-erro-com-iso-de-instalacao-do-sql-server-2019/

Side-by-Side – Na minha opinião é o formato mais seguro, pois neste cenário você já tem um novo Hardware provisionado e pronto para ser o seu novo ambiente. A principal vantagem desta abordagem é que você pode fazer as instalações e preparativos com antecedência para depois seguir com a sua migração e demais planejamentos.

• Considerações Importantes

• Avalie sempre as especificações de hardware caso seja um novo servidor. O seu novo servidor possui a mesma característica de Hardware do atual ou superior?
• Faça testes, verifique a latência dos discos, velocidade de CPU, e o máximo de validações que puder fazer afim de garantir que o novo ambiente seja capaz de suportar as operações do seu ambiente relacional.
• Valide as configurações do seu SO, opções de energia (Normalmente para ambientes SQL Server é recomendado manter o plano em Alto Desempenho para manter a performance do seu processador quando houver variações no clock).
• Os discos do seu novo servidor estão provisionados em conformidade com as boas práticas? As unidades estão formatadas em blocos de 64k, são SSD, elas estão segmentadas em partições físicas distintas?
• A nova instância será instalada em uma versão mais recente do SQL Server? Caso positivo, não se esqueça de realizar a validação com o assistente de migração DMA (Data Migration Assistant) a fim de identificar objetos que possam estar depreciados e evitar surpresas indesejadas na sua migração.

Segue o link para baixar o Assistente DMA:

https://www.microsoft.com/en-us/download/details.aspx?id=53595

• Avalie as features instaladas na sua instância atual, tais como: SSRS,SSAS,SSIS,etc afim de não esquecer de leva-las e configura-las em seu novo ambiente.
• Avalie a Collation da sua instância atual e garanta que ela seja instalada na sua nova instância/servidor;
• Lembre-se de pensar em todos os objetos e artefatos da sua instância SQL Server. Não se esqueça de considerar migrar os Jobs, Linked servers, Operadores, Logins,Database mail, Credentials , etc e de testar tudo também. Normalmente utilizo muito para esse tipo de trabalho o dbatools que é uma library em powershell que facilita muito a sua vida nesse tipo de trabalho.

Alinhe a melhor estratégia de migração das bases, será feito um simples Backup e Restore? Será feito por algum tipo de replicação? Avalie e planeje o melhor contexto de acordo com a sua necessidade e tempo.

Caso seja uma mudança de servidor, é bem provável que você ou sua equipe poderão precisar direcionar as conexões da sua aplicação para o novo servidor, deixando a base no servidor de origem em modo (read-only) ou (offline) você impede que alguém faça alterações no banco de dados antes do redirecionamento das aplicações e garante que não haja perca de dados durante a migração.

Lembre-se também de revisar as configurações da sua nova instância (Paralelismo / Configurações de Max Server Memory / Optimize for Ad hoc Workloads), etc.

• Fase de Acompanhamento

As primeiras 24 horas após uma migração são cruciais em praticamente toda migração de ambientes de missão crítica, lembre-se de planejar-se para acompanhar o ambiente a fim de validar que tudo esteja em conformidade nos primeiros dias após a migração.

Se houver mudança na versão do seu SQL Server, considere realizar a alteração do modo de compatibilidade de suas bases para nova versão para extrair os benefícios da nova Engine. Vale ressaltar que isso deve ser feito mediante a um acompanhamento, pois algumas consultas podem melhorar e outras podem piorar. Se possível, faça essa mudança alguns dias após a sua migração, pois assim você consegue controlar melhor a origem de possíveis problemas no seu processo pós migração.

Perceba que são muitos detalhes que precisam ser avaliados, a ideia desse post é trazer uma visão geral e possíveis pontos de atenção que devem ser levados em consideração em uma Migração SQL Server (OnPremise) para que você tenha sucesso na sua migração.

É isso pessoal, espero que tenham gostado.

Qualquer dúvida deixe nos comentários.

Gustavo Larocca

Consultor SQL Server