O planejamento é uma das fases mais delicadas do processo. Você deve realmente dedicar um bom período para ele e estar pronto para corrigir o processo todo no meio do caminho. Há uma série de decisões para serem tomadas no caminho e você deve conhecer bem as possibilidades para fazer uma migração bem feita.
O cronograma
A primeira coisa é prever um calendário generoso que contenha ao menos as seguintes etapas:
- Estudo das novas funcionalidades. Leia a documentação oficial da Oracle. Conheça as novas funcionalidades, limitações e facilidades. Verifique atentamente as suas opções de licenciamento e verifique quais são as suas necessidades reais.
- Disponibilize um ambiente de teste dedicado. Você deve ter um servidor dedicado exclusivamente para os seus testes. Você terá de reiniciar o servidor, particionar discos e fazer tarefas que exigem um servidor exclusivo. Não tente compartilhar ele com outro ambiente, mesmo que ele seja de teste também.
- Testes o desempenho. Para os testes iniciais, um servidor mais simples pode dar conta. Mas se você se preocupa com testes comparativos de performance, um ambiente de homologação semelhante ao de produção é fundamental. A configuração de discos e memória mudam bastante no 10g em relação às versões anteriores e você deve estar apto a decidir qual é a configuração ideal para o seu servidor antes dele entrar em produção.
- Documentação do processo. Você deve anotar todo o processo de forma a tornar qualquer pessoa capaz de reproduzir ele sem a sua presença. Tire o tempo que for necessário para isso. Não deixe de anotar detalhes, ajustes finos no servidor, alterações sutis e pequenos passos que possam passar desapercebidos.
- Criação de scripts para agilizar a migração do ambiente de produção. A partir da sua documentação crie um conjunto de scripts para automatizar um pouco o seu processo. Faça scripts separados para bancos de dados distintos. Os scripts vão fazer você ganhar agilidade na hora H além de diminuir a chance de você cometer erros.
- Teste cronometrado da migração. Depois que todos a documentação estiver pronta junto com os scripts, faça uma simulação final da migração o mais realista possível, utilizando os seus scripts e seguindo rigorosamente a sua documentação. Corrija a documentação tiver que alterar alguma coisa no caminho.
- Agende a migração do ambiente de produção para um final-de-semana ou feriado prolongado, em uma época que não for crítica para os negócios (como época de lançamento de folha de pagamento, fechamento de ano fiscal, etc).
- Monitore atentamente o servidor depois que ele entrar em produção: não agente nenhuma outra tarefa para o período imediatamente após a migração. Você precisará estar 100% atento para eventuais problemas que possam surgir. Se você estiver muito esgotado antes da migração, considere tirar uns dias de folga antes da migração (já que você vai ter que trabalhar no final-de-semana).
- Após estabilizar o ambiente de produção, lembre-se de migrar também o ambiente de homologação e de testes também.
Lembre-se que muitos problemas vão surgir durante os testes e você terá que pesquisar novas soluções no meio do caminho. Algumas decisões você só poderá tomar depois de testar algumas coisas, então é possível prever com segurança quando você poderá agendar a migração do ambiente de produção.
As decisões
Uma parte difícil do processo é tomar algumas decisões. Algumas você só descobrirá no meio do projeto, mas posso lhe adiantar algumas. Vou aproveitar aqui para explorar algumas mudanças que poderiam ser feitas na versão atual, mas que por ocasião da migração podem se tornar interessantes.
- Devo instalar a interface gráfica no meu servidor? 10 em 10 administradores de sistemas em Linux respeitáveis lhe dirão NÃO. Mas em se tratando de Oracle, alguns podem abrir exceções. Se as pessoas responsáveis pela manutenção do Sistema Operacional e pela instalação do Oracle estão presentes e se sentem a vontade com o procedimento, não há porque instalar a interface gráfica. Mas parece que muitos DBAs tem dificuldade de instalar o Oracle em Linux e não se acertam bem com o administrador de sistema responsável pelo SO. A própria documentação da Oracle dá pouca ênfase ao processo de instalação sem utilizar a interface gráfica. Vale a pena testar ambos os métodos. Eu realmente prefiro não utilizar a interface gráfica quando possível pois:
- Você economiza recursos do sistema, principalemente memória;
- Você tem um menor número de falhas de segurança no seu servidor;
- No dia-a-dia de um DBA ou de um administrador de sistemas, o SSH é a ferramenta mais utilizada e não a interface gráfica;
- Você pode utilizar todas as ferramentas clientes remotamente: sqlplus, Enterprise Manager (a versão client-server), SQL Developer, etc;
- A instalação e a atualização do servidor se tornam muito mais simples;
- O processo de instalação sem interface gráfica é mais rápido e mais fácil de ser reproduzido sem erros.
- Devo utilizar a migração automática do servidor? A Oracle disponibiliza uma ferramenta para migração automática do servidor de 9i para 10g. Apesar de poder tornar o processo mais simples e rápido, deixa pouca margem para ajustes no meio do caminho. Se o tempo for um limitador muito grande, a migração automática pode ser uma opção, mas se puder evite.
- Devo instalar as ferramentas web? O Oracle 10g traz duas ferramentas web que rodam no mesmo servidor que o banco de dados.
- O iSQLplus é uma ferramenta leve mas que também não ajuda muito. O uso do SQLplus original ou o SQL Developer são mais recomendados. O iSQLplus pode ser interessante por ser web, mas é bom lembrar que a sua distribuição foi descontinuada no 11g;
- O Enterprise Manager ou Database Control é uma ferramenta muito interessante e um pouco mais pesada. É particularmente interessante para quem comprou os pacotes extras para a versão Enterprise. Vale a pena experimentar para conhecê-la. Vale a pena lembrar que a versão cliente-servidor do Enterprise Manager foi descontinuada no 11g.
- Devo utilizar o ASM (Automatic Storage Management) ou RAW Devices? Esta é uma dúvida realmente difícil. O ASM é realmente uma grande novidade na versão 10g. O ASM é um pouco mais lento que o RAW Devices mas tras a possibilidade de fazer o balanceamento dos datafiles entre diversos discos. Se você procura extrair até a última gota de desempenho do seu SGDB, o RAW Device é uma opção extrema. O ASM pode ser muito interessante se você dispões de vários discos ou arranjos em RAID e possue centenas de datafiles que precisam ser distribuídos. Particularmente eu prefiro utilizar os sistemas de arquivos pois consigo ter acesso aos arquivos do banco de dados através do Sistema Operacional. Mesmo em ambientes RAC, o OCFS2 é amplamente utilizado no lugar do ASM ou dos RAW Devices. No entanto, se você já utiliza opções como o Data Guard e o RMAN, o acesso aos arquivos podem ser menos vital. Em geral, nas versões Standard do Oracle, você tem menos recursos da própria Oracle para manipular os arquivos então não é uma boa idéia utilizar o ASM ou RAW Devices neste ambiente.
- Devo utilizar o bigfile? No Oracle 10g você pode criar datafiles com tamanhos realmente enormes! Isto pode facilitar muito a administração dos arquivos do banco de dados. Até a versão 8 do Oracle, havia uma recomendação para não criar datafiles maiores de 250MB. Esta limitação deixou de existir na versão 9, mas alguns DBAs preferem evitar arquivos muito maiores do que 1GB para facilitar o trabalho de movimentação destes entre discos. Com a nova orientação de criar grandes RAIDs 0+1, o uso de arquivos grandes se tornou mais comum, tendendo a se criar um datafile por TABLESPACE. Se você tem TABLESPACES realmente grandes, cabe a você olhar para a sua estrutura de Storage e avaliar isso.
- Devo utilizar o gerenciamento automático de memória? Uma facilidade interessante no 10g é poder deixar o próprio Oracle distribuir dinamicamente os buffers disponíveis para os processos do Oracle. Eu acredito que esta seja uma funcionalidade que você deve utilizar a menos que você seja um mestre nesta área. É claro que você pode impor limites para este gerenciamento automático, impondo limites mínimos para algumas áreas. Somente uma homologação com testes de carga muito bem realizados poderão lhe dizer se o desempenho vai melhorar ou não com o gerenciamento automático. Monitore com cuidado o servidor em produção e guarde as configurações utilizadas no 9i debaixo do braço em todo caso. A versão 11g inclui novas melhorias no gerenciamento automático de memória estendendo o gerenciamento a PGA, além da SGA.
Não existem fórmulas mágicas para responder estas questões, mas é bom saber que elas existem e estar pronto para tomar decisões antes de migrar definitivamente. Algumas decisões são fáceis de serem alteradas mesmo depois da migração estar concluída, como a parte de memória ou de ferramentas, mas particularmente as decisões a respeito de Storage são difíceis de serem revertidas e devem ser tomadas com muito cuidado.
