Antes de mais nada, vamos estabelecer algumas premissas. Premissa no. 1 - Estamos falando de um lugar em que a tecnologia Microsoft é a predominante. Premissa no. 2 - Existe na empresa um desejo generalizado de realizar a migração dos bancos de dados para MSSQL Server. Dito isto, podemos continuar.
Ao longo dos meus mais de dez anos de carreira de tempos em tempos sou questionado sobre a migração do banco Sybase para MSSQL Server. "É seguro?", "Quais são os riscos?", "Isso irá afetar a paz mundial?", "Causará mutação em fetos humanos?". Até que me provem o contrário, a migração não afetará a paz mundial (não diretamente), e definitivamente não causará mutação em fetos humanos. Então, quais são os reais problemas?
Primeiro aspecto a ser observado
Factibilidade da migração - Para quem trabalha com qualidade de desenvolvimento de software, sabe que padrão é uma coisa difícil de estabelecer e manter nas organizações brasileiras. Assim, a incidência de código não padronizado, ou seja, ANSI SQL, é quase sempre muito alta, quando começamos a analisar as procedures, triggers e views (os três objetos que repreentam o principal problema na migração).
Mas então se os objetos que mencionamos acima não estiverem escritos em imaculado ANSI SQL devemos abortar o projeto de migração? Nada disso. O SQL produzido no Sybase, mesmo não sendo ANSI SQL, não é algo completamente alienígena para o MSSQL Server. Isso porque, acho que todo mundo sabe disso, este último, teve o seu core originário do Sybase.
Se ainda está em dúvida, leia este paper
Segundo aspecto a ser observado
Estratégia - E quanto a estratégia de migração? São necessários cientistas da NASA para fazer a migração? Não, não são necessários cientistas da NASA. Isso porque este tipo de migração é uma técnica de domínio conhecido há pelo menos cinco anos.
Antigamente era necessário ler um paper , um pouco chato eu admito, de algumas centenas de páginas. Esse paper da microsoft era um manual com um passo-a-passo de todo o processo de migração.
Mas desde o ano passado o caminho foi encurtado devido ao aparecimento do SSMA, SQL Server Migration Assistant.
Para detalhes desse migrador, acesse:
Para baixar, acesse:
O SSMA resolverá pelo menos 80% do problema. Mas e depois?
Terceiro aspectoa ser observado.
Risco - "Ai mas como eu garanto que o código migrado para MSSQL Server não tem nenhum erro?!!!!!! Aaaahhhhh!!!!!" , você provavelmente ouvirá isso do seu gerente, superintendente ou diretor. Não se intimide. Responda, com muita calma e serenidade, o óbvio. Testando! Ou, responda de uma forma mais elaborada, PDCA, Plan, Do, Check, Act.
"Mas e quanto ao risco de dar errado?". OK, vamos lá. Existem duas formas de responder essa pergunta. A primeira é a ironia, "Se você não quer correr riscos seja dono de uma funerária. O risco é próximo do zero. É um setor que nunca está em crise". Vamos agora a forma mais polida, eu diria.
Escolha o processo mais crítico relacinado a sua migração. Faça um snapshot do seu banco (uma foto) antes de executar esse processo. Execute o tal processo. Faça outro snpashot. Guarde os dois.
Depois que fizer a migração das procedures, views e triggers. Migre os dados do primeiro snapshot(Sybase) para o banco já migrado(SQLServer). Execute o processo mais crítico. Compare os resultados do SQLServer com o segundo snapshot(Sybase).
O que eu descrevi acima foi apenas uma sugestão. Mas certamente o DBA da sua empresa terá uma ideia melhor.
Conclusão.
A verdadeira questão não é, "SE é possível migrar", e sim, "QUANDO migrar". Hoje em dia, a migração do Sybase para SQLServer é muito mais um desafio de planejamento do que um desafio tecnológico propriamente dito.
PS: HÁ!
Nenhum comentário:
Postar um comentário