Do que se trata o artigo:

Este artigo apresenta todas as etapas para um upgrade manual de um banco de dados Oracle para a versão 11g. Neste contexto, falamos um pouco das razões que levam um banco de dados a ser migrado, do planejamento e dos testes que são fundamentais para o upgrade ser realizado com sucesso. Além disso, apresentamos as opções de upgrade, versões que podem ser migradas, e um passo a passo de como executar a migração.

Em que situação o tema útil:

Este tema é útil para quem está pensando em fazer o upgrade do banco de dados Oracle para a versão 11g, ou, para quem ainda não tem certeza, conhecer as razões que podem ser fundamentais na decisão.

Resumo DevMan:

Neste artigo apontamos as razões que levam ao upgrade do banco de dados Oracle para a versão 11g, e o que deve ser feito antes da implementação, como por exemplo, avaliações, planejamento e testes. Mostramos quais versões podem ser migradas diretamente e quais precisam de atualização antes de ser migrada para o 11g. Abordamos também as opções que temos para executar o upgrade, sendo elas via linha de comando, via DBUA, via Export/Import ou Cópia de Dados. Para finalizar, apresentamos um passo a passo, com exemplos, de uma migração de banco de dados 10g para a versão 11g.

Uma das principais razões para pensarmos em um upgrade do nosso banco de dados é que sempre a versão atual lançada pela Oracle corrige diversos bugs das versões anteriores. Porém, as novas funcionalidades da versão recém-lançada também contam muito no momento da avaliação, pois sempre temos itens novos referentes à segurança da informação, escalabilidade, desempenho e estabilidade do ambiente. Só não se pode esquecer, é claro, que muitas destas novas funcionalidades são pagas separadamente do seu software de banco de dados.

Outro fator que dependendo da situação pode requerer um upgrade da sua versão atual do banco de dados para uma versão mais nova pode ser o fato de sua empresa adquirir um novo hardware e as licenças estarem atreladas a esta compra. Ou seja, você terá que migrar seu ambiente, pois comprou um hardware novo que nem sempre é do mesmo fabricante, e que já está licenciado com uma versão mais atualizada. Contudo, apesar das razões levantadas até agora, acredita-se que o fim do suporte de algumas versões é um dos motivos fundamentais.

Com o final do Premier Support para a versão do Oracle 10g, que ocorreu em Julho de 2010, muitas empresas que não possuem Extended Support (suporte até Julho de 2013) estão migrando seus bancos de dados da versão 10g para a versão 11g para que possam ter total suporte ao produto em caso de novos problemas que necessitem de desenvolvimento para correção de bugs.

A Figura 1 apresenta as datas de encerramento de cada modalidade de suporte para cada versão. Para mais informações, acesse o endereço: http://www.oracle.com/support.

Figura 1. Datas de encerramento para cada modalidade de suporte.

No endereço http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf é possível ter acesso a mais detalhes sobre cada uma destas opções.

Iniciando o projeto

Como toda mudança que realizamos na área de sistemas, um upgrade precisa ser muito bem planejado e homologado para não colocar em risco o negócio da empresa. E para isso, o DBA deve ter ciência de como elaborar um planejamento adequado. Neste artigo, abordaremos uma das formas de migração mais utilizadas, que é a migração manual, através da execução de scripts da própria ORACLE, via CLI (Command Line Interface).

Neste momento vale ressaltar que existem outras etapas tão importantes quanto o upgrade, que devem ser muito bem estudadas para que esta atividade seja executada com sucesso. Estas etapas basicamente seriam: Avaliação, Planejamento, Configuração, Testes, Implementação e Aceitação.

Avaliação

Avalie todos os pré-requisitos de hardware e software necessários para a nova versão. Uma matriz de compatibilidade atualizada pode ser obtida no site da ORACLE. Avalie se a aplicação atual possui características específicas que precisam ser revistas, como por exemplo, comandos característicos da versão atual que foram descontinuados na nova versão. Alinhe com todos os responsáveis, as expectativas da migração, pois muitos acreditam que um upgrade do banco de dados acabará com todos os problemas da versão anterior, porém, esquecem que não adianta atualizar a versão do banco de dados se o problema estiver no desenho da aplicação.

Planejamento

Nesta etapa será necessário o envolvimento de um gerente de projetos, pois apesar de parecer simples, algumas das áreas de TI da empresa devem ser envolvidas no upgrade. Lembre-se que existem atividades relacionadas a Sistema Operacional, Segurança da Informação, Redes, Aplicações, dentre outras. Um cronograma com todas as atividades de todas as equipes deve ser criado e seguido para que se possa obter sucesso no upgrade. Deve-se criar também, junto às áreas usuárias, um cronograma de testes das aplicações. Além disso, não deve ser esquecido um plano de treinamento para os DBAs que irão migrar e suportar este banco de dados.

O tempo total disponibilizado pela empresa para a migração do banco de dados de produção precisa ser avaliado, pois dependendo da forma como será executada, poderá causar indisponibilidade de algumas horas no ambiente. Os tempos de cada atividade do processo de migração já deverão ser coletados quando o processo for executado no ambiente de testes/homologação.

Tenha ciência que um fallback de toda a atividade poderá ser solicitado e todas as etapas necessárias para isso já deverão estar planejadas; se possível, já executadas no ambiente de testes para que não haja surpresas. É possível encontrar casos onde devido à bugs ou características da nova versão, torna-se necessário fazer o fallback do upgrade. Em uma das migrações que nossa equipe executou, cogitou-se voltar à versão anterior do banco de dados, pois o sistema começou a gerar vários locks que antes não ocorriam com a mesma frequência, o que nesta oportunidade explicitou a falta de testes mais complexos no ambiente de homologação. Por isso, execute ao menos uma vez os procedimentos de fallback.

...
Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo