O que devemos ficar atentos em uma Migração (ONPREMISE) de um ambiente SQL Server?
![](https://gustavolarocca.com.br/wp-content/uploads/2021/05/splash3.png)
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
3 comentários
Que post TOP!! Você tá demais cara!! Fala sobre Log Shipping sim e outros posts com mais detalhes sobre cada solução ai, vai ficar show!
Abraço,
Luiz Vitor
Obrigado pelo feedback meu amigo!!
Com certeza vou trazer algo sobre Log Shipping mais a frente sim e mais detalhes sobre essas soluções.
Um grande abraço!
Excelente post Gustavo !
Abriu a mente para futuras migrações que cair aqui rs
Caso tenhas mais casos diferentes para compartilhar, agradecemos .