Os desafios do fim do ciclo de vida do SQL Server 2008/2008 R2

No caso da Microsoft, o final de mais um ciclo não apanha ninguém desprevenido, dado que a tecnológica respeita um ciclo composto por anos previamente definidos para prestar suporte aos seus produtos. Findo esse período, o suporte termina, cabendo ao cliente duas opções:

Opção 1: Assumir o risco e manter a tecnologia sem suporte

Nesta opção é necessário que a organização detenha know-how para gerir versões de bases de dados mais antigas, não sendo, no entanto, algo atípico. É ainda bastante comum encontrar organizações em que se verifica a convivência de bases de dados de versões mais antigas, como por exemplo SQL Server 2000 ou 2005, com bases de dados mais atuais. O problema, neste tipo de cenário, passa pela necessidade de know-how de um Administrador de Base de Dados experiente, o que por vezes, com os desafios da escassez de profissionais de Tecnologias de Informação (TI) no mercado nem sempre é possível, tornando o desafio ainda maior pelo facto de este perfil afunilar para profissionais mais experientes, por se tratar de tecnologia com, em alguns casos, vinte anos. A alternativa a esta situação passa pelas empresas recorrerem a consultoras, onde estes profissionais se encontrem.

Ainda em relação à primeira opção, é comum que estas bases de dados de versões não suportadas, ao permanecerem na organização tenham um nível mínimo de intervenção, dado o potencial risco de erro.

Opção 2: migrar para versões mais recentes e que se encontrem em outras fases do ciclo de vida do produto, garantindo as condições de suporte por parte do fabricante

Na segunda opção encontramos o cenário mais comum. Este, no entanto, não deixa de estar envolto em processos de elevada complexidade e de algum risco também, dependendo da forma como a empresa gere o seu processo de migração. Uma migração é um processo planeado com pelo menos três meses de antecedência, podendo ir até aos seis meses, dependendo da complexidade, criticidade e mediatismo desta migração.

Desafios na migração de bases de dados

Alguns dos desafios que uma empresa deve ter em conta aquando de uma migração são a garantia de que se a base de dados de destino, por alguma razão, falhar, a base de dados de origem irá manter, em total segurança, os dados que estavam a ser migrados. Por outro lado, deve ter a garantia de que todas as equipas envolvidas, ou seja, que tenham aplicações nas bases de dados que estão a ser migradas estejam alinhadas com o que deverão fazer antes, durante e após a migração.

Em resumo, algumas boas práticas para uma migração são:

• Apurar de antemão o impacto da migração dentro de cada equipa/projeto;
• Comunicar a todas as equipas, de forma assertiva, os passos necessários e respetivos prazos;
• Dar seguimento ao processo de migração apenas quando todos os passos previamente planeados estiverem cumpridos;
• Garantir as condições de segurança da migração.

Aquando da migração, a empresa não se depara com um novo ambiente tecnológico totalmente singelo. Não. É comum que as evoluções que acompanham as novas versões das bases de dados não sejam acolhidas da melhor forma pelas aplicações já existentes, sendo assim um trabalho que em fases posteriores implica ainda algumas horas de intervenção dos devidos profissionais e cooperação/coordenação entre as várias equipas. A boa notícia é que findo este processo, a tecnologia voltará a fluir com os respetivos ganhos da evolução efetuada.

Se me perguntarem qual a minha opinião, salvo raras exceções, esta, tendencialmente, será a de acompanhar a evolução da tecnologia para as versões mais recentes. Partilho aqui cinco razões que a justificam:

• Incremento significativo de performance, tirando partido funcionalidades como recursos in-memory, processamentos híbridos, etc.;
• Melhorias claras ao nível da segurança e proteção de dados, que permitem uma adequação efetiva ao Regulamento Geral de Proteção de Dados (RGPD), tirando partido de funcionalidades como always encrypted;
• Integração de dados relacionais e desnormalizados, tirando partido do PolyBase;
• Alta disponibilidade e cenários mais rápidos de recuperação de falhas;
• Otimização do TCO de software e da infraestrutura.

A atualização do seu Microsoft SQL Server não tem de ser uma dor de cabeça, mas com o rápido aproximar da data, é fundamental decidir para que versão do produto migrar, o modelo de licenciamento ou consumo e efetuar as validações necessárias para o planeamento desta migração.

por Paulo Gonçalves, Business Intelligence & Analytics Manager, Rumos Serviços