Introdução

Você pode dizer “migrações e atualizações” para um administrador de banco de dados (DBA) ou administrador de sistemas. Mas o que eles normalmente ouvem é “risco e downtime”.

O processo de migração e atualização de hardware, sistemas operacionais, bancos de dados e aplicações de software se tornou inseparavelmente ligado a risco, downtime e fins de semana no escritório para a maioria dos administradores que realizam essas atividades. Os administradores de sistemas e os usuários que dependem deles prendem a respiração até que o processo esteja concluído e, depois, voltam às operações normais com o pé atrás com as coisas que não funcionam bem da maneira como funcionavam.

Para o DBA. o processo é um item estressante. Além de precisar planejar perder um evento em casa ou um feriado, tudo isso pode dar errado e você pode acabar passando dias tentando descobrir o porquê. Enquanto isso, você tem usuários furiosos que não conseguem fazer o trabalho e um negócio que está perdendo receita. E todo mundo está responsabilizando você.
Esse artigo mostra como simplificar o processo de migração e atualização para que você possa evitar o risco, o downtime e as longas horas normalmente associadas a ele, principalmente em relação à atualização dos bancos de dados. Ele descreve os motivos comuns para migração e atualização, descreve as armadilhas comuns do processo de migração e atualização e fornece algumas dicas para evitar riscos à disponibilidade do sistema para que você possa ter de volta os seus fins de semana.

Qual a diferença entre migração e atualização?

Vamos começar pelo básico: você está realizando uma migração ou uma atualização? Às vezes, os termos são usados de forma intercambiável, mas compreender essa diferença é a primeira etapa para descobrir a abordagem correta para seu projeto.

A migração geralmente envolve trocar de hardware, mudar para uma nova plataforma da marca (por exemplo, de Unix para Linux ou de armazenamento EMC para Deli EqualLogic), estabelecer um novo banco de dados Oracle ou trocar completamente de um sistema de gerenciamento de banco de dados para outro (por exemplo, Oracle para SQL Server).
Todos os objetos, tabelas e dados, juntamente com as alterações que ocorrem neles enquanto o projeto está em andamento, devem ser replicados para o novo ambiente. Isso significa economizar as informações para que você tenha uma cópia exata para aplicar ao seu novo sistema. No caso de migração de um banco de dados, quanto maior for o banco de dados, maior é o risco para os negócios além do downtime. As ferramentas de migração dedicadas são projetadas para ajudá-lo a realizar a troca com um downtime de quase zero.

Em uma atualização, você aplica uma versão atualizada como Oracle versão 12c em um ambiente existente como Oracle 11g. Como as atualizações raramente afetam seus dados, a quantidade de dados que você tem armazenada não afeta nada ou quase nada em seu projeto.
Os fornecedores de banco de dados fornecem uma gama de ferramentas nativas para concluir as migrações e atualizações, mas seu escopo é limitado e seu uso pode resultar em downtime. As ferramentas de replicação dedicadas permitem que você copie o ambiente antigo e atualize o novo ambiente com downtime mínimo.

Por que migrar ou atualizar?

As empresas realizam migrações por diversos motivos:

  • As migrações de bancos de dados Oracle se tornam necessárias por causa de um suporte expirado em versõess mais antigas. Mesmo se o suporte estendido continuar após a expiração, ele é deliberadamente caro demais, um fator que obriga muitas organizações a buscar uma atualização. Novos recursos e funções são o incentivo a mais à  atualização e a TI pode optar pela migração do Oracle Enterprise Edition para a Standard Edition a fim de eliminar custos associados com recursos que ninguém está usando.
  • A migração é indicada ao mudar o sistema operacional do servidor; por exemplo, ao mudar do Solaris para o Linux. E mudar para uma arquitetura diferente, como Oracle Real Application Cluster (RAC), ambientes de cloud computing ou virtualizados, exige que a TI forneça uma cópia dos dados atuais para uma plataforma diferente.
  • A migração de armazenamento envolve o componente de atualização de hardware, quando a TI substitui um array de discos existente por um mais novo e mais rápido.
  • A TI pode aproveitar a atualização de aplicações como PeopleSoft, Siebel, Oracle E-Business Suite e SAP para atualizar hardware e bancos de dados ao mesmo tempo.

Em todos esses cenários, os administradores enfrentam duas prioridades concorrentes: realizar a atualização rapidamente e reduzir o risco e o downtime. Como eles nunca podem estar 100% seguros de atender às duas prioridades, eles são encarregados de testar e otimizar o novo ambiente em sua totalidade antes de migrar os usuários para ele.

Qual o melhor momento para migrar?

Essa é uma pergunta difícil.

Tradicionalmente, as migrações e atualizações são programadas para quando nenhum usuário estiver on-line. Isso pode reduzir a interrupção no trabalho das pessoas, mas significa que os DBAs estão ocupados com projetos de migração enquanto os colegas estão aproveitando suas tardes, fins de semana. feriados ou até mesmo as férias. Outros problemas a serem considerados são:

  • Ferramentas nativas exigem downtime. Dependendo do tamanho do ambiente. isso pode levar muitas horas ou dias.
  • Estabelecer um novo ambiente também exige o teste, o que pode exigir dias. semanas ou até mesmo meses adicionais dependendo da quantidade e abrangência do teste (Veja mais a frente “Como reduzir o risco durante sua migração ou atualização).
  • Fora do teste, a maioria das atualizações e migrações é realizada durante o fim de semana para que os DBAs possam fazer um backup, iniciar a atualização e colocar os sistemas em funcionamento a tempo, antes de os usuários chegarem na segunda-feira de manhã.

Especialmente para empresas que dependem de eCommerce, não existe o melhor momento para migrar porque não há a possibilidade de downtime. O downtime interrompe os negócios e afeta o resultado final.
Com a ferramenta certa aplicada, você pode maximizar a disponibilidade ao ter uma cópia de seu ambiente em execução em um sistema temporário separado da produção. E o mais importante. você pode passar menos noites, fins de semanas e férias pensando em migrações e atualizações.

Os 5 principais motivos de falha de projetos de migração de banco de dados

  1. Planejamento insuficiente – As empresas geralmente mergulham em grandes migrações sem revisar os ambientes existentes ou avaliar o que precisa ser movido e o que não precisa. Por exemplo, qualquer migração deve começar com uma análise de todas as aplicações, processos e usuários que precisam de acesso para garantir que os recursos e as aplicações adequadas estarão disponíveis quando a migração ocorrer. Antes de realizar uma ação, é imperativo avaliar o possível impacto da migração nos fluxos de trabalho, programas e infraestrutura.
  2. Subestimar o impacto sobre os usuários e os negócios – Um erro comum e possivelmente fatal é subestimar o impacto da migração nos usuários e operações. Os administradores podem diminuir o impacto em sistemas de produção, usuários e produtividade programando tarefas de migração intensiva de recursos durante os momentos de pouca atividade.
  3. Estratégia inconsistente ou ausente para coexistência – A coexistência é essencial, principalmente com migrações de diversas fases. Não fornecer a coexistência perfeita entre os sistemas existentes e novos é uma negligência frequente, que pode levar a interrupções de serviço, perda de produtividade e aumento de custos dos negócios.
  4. Proteção de dados inadequada – Embora o senso comum exija a realização de backups frequentes, as empresas geralmente hesitam ao tomar essa medida de proteção extra para evitar a perda de dados durante a migração. Um plano de backup e recuperação total é a chave para restaurar dados rápida e facilmente se algo der errado durante o processo de migração.
  5. Falha ao focar no gerenciamento – Atender às altas expectativas de uma migração significa ter programação, gerenciamento de projeto e relatório de progresso sólidos em tempo real para garantir que o novo sistema seja compatível, disponível, seguro e eficiente. Isso se aplica à otimização necessária do novo ambiente assim que a migração atual estiver concluída.

Migração de dados Shareplex

 

Como reduzir o risco durante sua migração ou atualização

Teste antes de implantar. Idealmente, após a migração, você testará suas aplicações completamente antes de disponibilizá-las à sua comunidade de usuários, mas a pressão para colocar o sistema de volta on-line geralmente torna o teste impossível. A maioria das organizações tenta economizar o downtime limitando o teste de aplicação, o que aumenta o risco de uma migração com falha.

Uma melhor abordagem para testar é replicar a atividade nos bancos de dados de produção, com o volume e variedade de transações que levariam horas de trabalho para duplicar. Use a replicação por pelo menos dois dias como a única forma de testar a instância. Em seguida, comece a executar testes somente leitura, verificando seus relatórios e consultas para compatibilidade com a nova plataforma.
Finalmente, implemente os recursos mais importantes de sua nova plataforma e tente atualizar suas aplicações. Essa é a maior parte da tarefa, mas vale muito para garantir que tudo funcione adequadamente assim que você fizer a alteração.
Tenha um plano B. Sempre há uma chance de sua migração falhar. No pior cenário possível, a aplicação parece estar funcionando perfeitamente e os usuários começam a inserir dados e, então, você descobre que uma parte da aplicação não está funcionando adequadamente.
É aí que o failback ao primeiro sistema entra. Se algo der errado com o novo ambiente, você precisará de uma maneira para permitir que os usuários trabalhem no ambiente original sem downtime, nem perda de dados. As ferramentas nativas não oferecem suporte ao failback automático. Portanto, a menos que você tenha capturado as alterações temporárias, você corre o risco de aumentar seu downtime com scripts e entrada de dados manuais, agravando o impacto nos negócios.

Conclusão

Como um DBA independentemente de estar com um projeto de migração ou atualização, a mudança está a sua frente. Sempre que houver uma mudança na TI, haverá o risco de downtime para seus usuários e fins de semanas perdidos para você.

Embora seja difícil descobrir o melhor momento para migrar ou atualizar, você não pode deixar atrapalhar o seu projeto. A melhor maneira de evitar armadilhas que afligem a maioria dos projetos de migração é insistir no momento adequado para teste e munir-se com um plano B.
Independentemente de estar migrando ou atualizando, os DBAs e administradores dos sistemas podem superar as deficiências de ferramentas nativas com o suporte abrangente e completo incorporado em ferramentas de software dedicado.

Para ver a segunda parte deste artigo clique aqui!

Saiba mais em

anovasolucao.net/shareplex/ 

Fonte: quest.com/br-pt/