Antes que você saia instalando o Oracle 10g e colocando a mão na massa para valer, você deve avaliar um detalhe importante: Como será o seu ambiente de “Laboratório”. Já escrevi sobre a importância de se ter um ambiente de produção, um de homologação e um de teste. Agora é a vez de se criar um quarto ambiente. Vejamos como utilizá-lo e como ele se integra com os outros 3 ambientes já existentes.

Entre os ambientes de banco de dados, o único que a Oracle não cobra pelo licenciamento é o laboratório. Além do ambiente de produção, a Oracle cobra licenças para o seu ambiente de testes, homologação, stand by, etc. Para isso, o seu ambiente de produção e desenvolvimento não podem depender em momento algum do laboratório. Esta é uma regra que deve estar clara. Então para que ele serve? Para testar unica e exclusivamente o SGDB e saber como ele se comporta. Você não vai utilizar o laboratório apenas para testar a migração do Oracle 9i para o 10g ou 11g. Você vai utilizar ele para validar cada novo patch de correção ou para testar funcionalidades que nunca foram exploradas antes.

De certa forma, o laboratório é o parque de diversões do DBA. Lá ele pode fazer uma carga com os dados reais das aplicações e levar o ambiente ao limite. Apesar disso, ele deve estar por perto não apenas durante um processo de migração. Você pode precisar dele quando menos espera. Imagine que você por um acaso do destino encontre um bug no Oracle e você tenha que aplicar um patch. Você não vai aplicar o patch direto no seu ambiente de produção/homologação/testes. Você vai testar primeiro ele no laboratório. Vai analisar se ele oferece impacto em outras aplicações. Se realmente vale a pena aplicar o patch ou se é melhor conviver com o bug do jeito que está, etc. Se um dia você resolver aplicar um
“patch set” que é o equivalente da Oracle a um “service pack” da Microsoft, os testes se tornam mais importantes ainda, pois você pode ter certeza que muitas características do SGDB vão sofrer alterações relevantes. O oracle 10g por exemplo está no “Release 2″ ou seja, na versão “10.2″. Já saíram alguns patch sets para o 10.2. Em março saiu o 3º patch set, estando hoje na versão “10.2.0.3″. Mas não despreze os pequenos patchs que você consegue aplicar em poucos minutos com o OPatch. Uma pequena alteração no CBO (Cost Base Optimizer) pode virar de ponta cabeça o desempenho de todas as suas consultas. E mais, um patch em uma área que pode não parecer diretamente relacionada com outra pode ter efeitos colaterais inesperados.

Em resumo, mexer no seu SGDB, seja qual for, exige muita responsabilidade e muitos testes. A validação destes testes deve ser feita de maneira progressiva. Nunca pense em mudar alguma coisa direto do laboratório para a produção. Vá com calma, independente se você está migrando de versão, de release, de point release ou mesmo aplicando um pequeno e inofensivo patch. O ideal é fazer os testes no laboratório e depois aplicar as alterações no ambiente de testes, homologação e por último na produção.

Bom, você pode ter se convencido de que ter o laboratório é necessário, não apenas para um projeto de migração de versão. Mas vai imaginar que o orçamento da empresa não vai comportar um servidor dedicado só para isso. Já vai lembrar de um servidor que estava para se aposentar ou até mesmo um desktop. Mas agora respire fundo e pense. Você vai conseguir realmente testar as funcionalidades que deseja neste ambiente? Quais as chances de você ter resultados diferentes do laboratório no ambiente de produção? Se pensar com cuidado, verá que um desktop está fora de cogitação para realizar testes. HDs IDE ou SATA (por mais eles estejam a cada dia mais rápidos, etc, etc, etc) não são opções viáveis para um servidor de laboratório. Você sempre deve se aproximar o máximo possível do seu ambiente de produção, mas… bom, todo orçamento tem limite. Então o que fazer?

A primeira coisa a se pensar é que se o seu servidor de produção vai migrar, então seria bom migrar para um novo hardware também. O seu servidor de laboratório poderá ser o novo servidor. Migrar o servidor de produção para uma nova versão na mesma máquina é muito arriscado. Você não tem como voltar atrás se alguma coisa der errado. Se você utilizar o novo servidor, fará o favor de testar bem o novo hardware e ter uma idéia realista de como será o desempenho dele num futuro próximo. Como um servidor de produção não deve estar ativo por mais de 3 ou 4 anos, o upgrade de hardware acaba muitas vezes casando com o upgrade de software. Além do mais, por tradição as novas versões com suas novas funcionalidades costumam trazer ganhos de performance acompanhados com aumento no consumo de recursos de hardware. No Oracle 11g por exemplo a exigência mínima de memória saltou de 512MB para 1GB.

Mas, você vai querer manter um laboratório só para testar novas versões ou patch. Você pode querer começar a testar o 11g só para verificar qual tipo de ganho sua empresa terá e decidir se vale a pena migrar mais rápido (eu diria que daqui a um ano é rápido para uma versão nova como o 11g) ou esperar mais tempo. Você vai querer manter o laboratório ativo para testar patchs de segurança e outros que venham a aparecer. A partir do lançamento da versão 10.2.0.3 em março de 2007, já foram publicados mais de 400 patchs até setembro. Isto é sério ao ponto de ambientes críticos manterem equipes especializadas em aplicações de patchs, pois saber o que aplicar, quando e como não é tão simples quanto parece. Se quiser manter um laboratório para esta finalidade, você pode pensar em fazer algumas concessões como possuir até metade do espaço em disco original no ambiente de produção. Um corte deste tipo exigirá que você carregue as tabelas das aplicações com uma fração das linhas originais. Isto pode dar um certo trabalho, pois você terá que manter as restrições de integridade entre as tabelas intactas. Neste caso, você deve se lembrar que você não tem testes de desempenho válidos neste ambiente. Os planos de consulta irão mudar radicalmente no ambiente de produção. Se você for aplicar as alterações validadas num servidor de laboratório limitado mas aplicar as alterações primeiro no ambiente de testes e depois no servidor de homologação, você poderá resolver os problemas de desempenho no ambiente de homologação antes de chegar no ambiente de produção. Isto é claro, se o ambiente de homologação for realmente semelhante ao ambiente de produção.

Em uma empresa menor, pode ser inviável manter 4 ambientes. O custo para se manter 4 servidores para cada ambiente de produção é bem pesado. Ninguém disse que brincar de banco de dados seria barato, mas existe uma regra em TI que deve sempre ser lembrada: “O valor do cofre não pode ser maior que valor dos objetos que você quer guardar nele”. O custo/benefício deve ser avaliado. Principalmente os riscos devem ser avaliados:

• Migrar de versão de banco de dados nem sempre é uma opção se você deseja continuar a ter suporte do seu fornecedor. Você pode desejar migrar de versão atraído por novas funcionalidades ou aumento de desempenho. Mas é fato que todo software deixa de receber suporte e atualizações de segurança depois de um tempo. No caso da Oracle, é seguro estar na penúltima versão. Com o lançamento do 11g, está na hora de pensar seriamente em migrar para o 10g, uma vez que o 9i será descontinuado pela Oracle.
• Migrar de hardware a cada 3 ou 4 anos não é uma opção. Você pode até continuar utilizando o servidor depois deste período para operações menos críticas, mas este não costuma ser o caso dos bancos de dados em produção. Os DBAs podem e devem se considerar privilegiados na hora de fatiar o orçamento de investimento na área de TI.
• Você nunca vai conseguir testar 100% o desempenho da sua aplicação no laboratório, o que significa que você sempre vai estar sujeito gargalos imprevistos. Por outro lado, de 90 a 99% dos problemas (dependendo do tipo de testes que você executou) podem ser detectados com testes de desempenho. É muito mais fácil lidar com 1% a 10% de problemas no ambiente de produção, do que 100%.
• Considere seriamente a possibilidade de realizar operação paralela entre ambiente de produção e laboratório por um ciclo do software - como um mês numa folha de pagamento - incluindo a época de fechamento - como a geração de rotinas anuais. Negocie isto com os usuários da aplicação e exponha francamente para eles qual é o risco de não fazê-lo. Imagine uma base de dados de contabilidade que você migre e só depois de quase um ano, no fechamento do ano fiscal, você descobre sérios problemas. Distribua o risco!
• Quanto maior o seu gargalo de desempenho no ambiente de produção, maior será o desejo de migrar para novas versões. Ambientes onde o desempenho é sempre crítico e uma preocupação constante devem investir pesado no ambiente de laboratório e homologação.

Se você chegou aqui e acha tudo isso uma extravagancia e desperdício de recursos, lembre-se que em geral os testes por mais que tenham sido feitos com esmero (o que em geral não acontece na prática), eles nunca simulam o ambiente real de forma fidedigna. Uma expressão que traduz isso muito bem é “Shit happens“. E quem já viu, sabe que certas situações não podem ser expressadas com vocabulário formal. A questão no final será: você poderia ter prevenido isso? A resposta a esta pergunta lhe dirá se você continuará ou não empregado!

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.

Para quem não conhece, o ora2pg é um pequeno script escrito em PERL que quebra um grande galho na migração de Oracle para PostgreSQL. Ele não faz milagres, mas já adianta muita coisa, convertendo algumas coisas na sintaxe do Oracle que tem equivalência na sintaxe do PostgreSQL.

Estes dias me perguntaram sobre ele aqui no blog e eu demorei um pouco para encontrá-lo. Outrora o ora2pg foi mais prestigiado, chegando a fazer parte do contrib do PostgreSQL. Como todo projeto pessoal (o ora2pg é desenvolvido pelo Sr. Gilles Darold) o ora2pg chegou a ter alguns períodos de inatividade. Começando em 2001 o ora2pg já está na versão 4.5 lançada há pouco tempo em 20/06/2007 . Isto é uma ótima notícia, pois além de acompanhar as novidades nas últimas versões do PostgreSQL, Gilles Darold, tem corrigido alguns bugs e ainda implementado algumas funcionalidades novas. O único detalhe a se notar é que o local onde o projeto é hospedado parece um tanto instável, então não se assuste se o link não estiver funcionando… :-/

Se você está pensando em migrar de Oracle para PostgreSQL, o ora2pg continua sendo uma excelente opção. Longa vida ao ora2pg!!!

• ora2pg - Site do projeto
• Migração de Oracle para PostgreSQL - palestra realizada no VII FISL

Este será o primeiro de uma série de postagens documentando o processo de migração do Oracle 9i para o 10g. Algumas decisões foram tomadas no meio do projeto e portanto não será possível adotar este guia ao pé da letra para todos os casos de migração possível. Particularmente, fiz a opção de não utilizar a ferramenta de migração automática da Oracle e seguir o esquema tradicional de importar e exportar os dados manualmente. Este guia poderá ser utilizado em grande parte numa migração com outras versões do Oracle como origem dos dados, mas isto não foi testado. Outras decisões foram tomadas para maximinizar a flexibilidade das instalações e importações como realizar as instalações sem a interface gráfica, utilizar um particionamento de disco um pouco mais agressivo (sem o uso do ASM) e realizar a importação dos dados esquema por esquema.

Fase I - Planejamento

Conheça o banco de dados atual:

1 - Veja como anda a ocupação dos discos, veja se o servidor novo tem a mesma configuração do atual. Veja se pretende manter o esquema de particionamento atual ou se seria um bom momento para mudar. O Oracle 10g trás uma nova ferramenta chamada ASM, pode ser uma alternativa interessante de se utilizar, se você tiver um número grande de discos ou grupos de discos (RAID) e principalmente se você pretende utilizar o RAC em um futuro próximo e já está utilizando um Storage externo. O ASM funciona muito melhor que utilizar RAW devices ou OCFS, mas ainda apresenta uma limitação conhecida: não é possível manipular os arquivos dentro de uma partição ASM através do SO. Além disso anote:
- O espaço ocupado por cada tablespace + margem de segurança + taxa de crescimento esperada;
- O número de datafiles que cada tablespace possui. Você pode utilizar os novos tablespaces do tipo bigfiles para tablespaces muito grandes;
- O espaço ocupado pelos archives;
- O espaço ocupado pelos backups lógicos e físicos;
- O número de logs de REDO;

2 - Conheça os recursos utilizados como JOBs, DB Links, Packages, XML, BLOBs, Streams, etc.

3 - Conheça os usuários, roles e permissões. Permissões de sistema que os usuários e roles possuem também são alvo de checagem cuidadosa neste processo.

4 - Verifique como anda o desempenho do seu banco. Apesar de muitas funcionalidade mudarem no 10g, você não deve desprezar os sinais que você já tem hoje. A distribuição dos Tablespaces, archives, logs de redo devem ser revistos. Os ajustes de memória provavelmente serão alterados, mas vale a pena checar o tamanho da SGA e PGA além do tamanho dos blocos. O momento da migração é um momento propício para fazer algumas mudanças, uma vez que exigem a parada do banco de dados, exportação e reimportação de dados, processo que será realizado na migração. No entanto, tome cuidado para não exagerar na dose:
- Se não tiver segurança no que estiver fazendo, não faça;
- Se for utilizar uma nova funcionalidade que nunca testou antes, não teste agora faça isso depois da migração;
- Se precisar comparar o desempenho entre o 9i e o 10g, você deve manter ao máximo a estrutura atual;
- Muitas mudanças ao mesmo tempo aumentam as chances de erro no processo;
- Se o tempo disponível para a migração for crítico, algumas alterações podem exigir tempo extra para implementar e testar.

5 - Conheça o tempo que leva para:
- Realizar um export e import full do banco de dados;
- Realizar um export e import por schema do banco de dados;
- Copiar todos os datafiles;

6 - Reserve espaço adicional para receber os arquivos de backup.

Fase II - Backup

1 - Pare o banco de dados e assegure-se que ninguém mais, além de você pode entrar no banco de dados. Você pode fazer subindo o banco de dados no modo restrito. Você também pode garantir que ninguém altere os dados colocando os tablespaces apenas para leitura.

2 - Realize um export full do banco de dados e um export para cada schema a ser migrado. Não exporte os schemas referentes a ferramentas do próprio Oracle.

3 - Rode scripts para copiar os dados sobre:
- Tablespaces e datafiles e quotas em datafiles;
- Usuários, roles, permissões e permissões de sistema;

Se estiver utilizando, copie também:
- Sinônimos públicos;
- Nomes para diretórios externos;
- Contexto de aplicações
- Definições de segmentos de rollback
- Perfis de usuários

4 - Se for migrar e utilizar o mesmo servidor, então copie para outro local:
- Todos os datafiles, controlfiles e logs de redo;
- Todos os exports gerados anteriormente;
- O init.ora, tnsnames.ora, listner.ora, sqlnet.ora;
- Outros scripts de manutenção criados no SO;
- Todos os dados gerados anteriormente (tablespaces, usuários, etc.)

Fase III - Preparação do SO:

Eu particularmente gosto de formatar o servidor onde a instalação será feita e configurar tudo a partir do zero. É comum durante a vida de um servidor serem instalados pacotes desnecessários, alterações em configurações não documentadas e outras coisas mais. Se você tem 100% de confiança sobre a configuração do seu SO, então você não precisa reinstalar ele.

1 - Instale o SO:
- Tome cuidado para não instalar pacotes desnecessários, particularmente eu prefiro não instalar a interface gráfica como um todo, o que economiza um pouco de espaço em disco, um pouco de memória e abre menos brechas de segurança;
- Faça o particionamento dos discos minuciosamente de acordo com o seu planejamento prévio;
- Instale todos os paths de segurança no SO.

2 - Instale as dependências do Oracle

3 - Crie os usuários e grupos no SO

4 - Crie os diretórios necessários e dê as permissões adequadas neles

5 - Faça alterações nos parâmetros do kernel e outros arquivos de configuração

6 - Copie o software do Oracle para o seu HD

7 - Copie os dumps e todos os arquivos a serem utilizados para para a criação do banco de dados

Fase IV - Instalação do Servidor Oracle:

Aqui você fará a instalação do software da Oracle. Existem 3 formas básicas de se fazer isso:
- Utilizando o Oracle Universal Instaler (OUI) no modo interativo, que é o método mais conhecido e exige a instalação da interface gráfica no servidor;
- Utilizando um arquivo de respostas para automatizar algumas respostas para o OUI, que automatiza e padroniza uma parte do trabalho e tem respostas visuais gráficas, o que exige a instalação da interface gráfica no servidor;
- Utilizar um arquivo de respostas no modo silencioso, que não exige o uso da interface gráfica no servidor.

1 - Configure as variáveis de ambiente necessárias.

2 - Crie o arquivo /etc/orainst.loc .

3 - Configure as variáveis de ambiente adequadas.

4 - Rode o instalador do Oracle no modo escolhido.

5 - Aplicaque os paths de atualização do Oracle

Fase V - Instalação do Banco de Dados Oracle

Novamente você tem 3 formas básicas de criar o seu banco de dados:
- Durante a instalação do Servidor Oracle que é a forma mais simples e menos flexível, que eu não recomendo para ambientes de produção;
- Utilizando o Data Base Configuration Assistant (DBCA), que é uma forma bastante flexível, mas exige o uso da interface gráfica instalada no servidor;
- Utilizando scripts SQL para a criação do banco de dados, que é a forma mais complexa, mais flexível e que não exige o uso da interface gráfica;

1 - Configurar as variáveis de ambiente

2 - Criar um arquivo init.ora

3 - Utilize o DBCA ou rode seus scripts para criar o banco de dados

4 - Configure a rede (listner.ora, tnsnames.ora, sqlnet.ora)

5 - Teste o banco de dados

6 - Crie o pfile

Fase VI - Importe os dados

1 - Crie os tablespaces adicionais

2 - Crie os usuários, roles e privilégios de sistema

3 - Crie os alias para diretórios dumps, perfis e DB Links.

4 - Importe os dados a partir dos exports por esquema

5 - Crie os privilégios e os sinônimos públicos e outros objetos exportados anteriormente

6 - Importe novamente os dados por esquema

7 - Compile os views, packages, procedures, functions e triggers

8 - Rode um analyze em todas tabelas e índices

9 - Realize testes preliminares

Fase VII - Configurações finais

1 - Configure as variáveis de ambiente no usuário Oracle

2 - Configure a inicialização automática do Oracle em /etc/init.d/

3 - Crie os scrips de manutenção

4 - Coloque a instância no modo archive

5 - Ative os parâmetros de auditoria mínimos

6 - Verifique a utilização do espaço em disco

7 - Verifique as políticas de segurança

8 - Crie um script para o controlfile

Fase VIII - Testes

1 - Teste os backups

2 - Teste a reinicialização do servidor

3 - Teste as aplicações

4 - Monitore o desempenho

5 - Termine a documentação do processo antes de liberar o servidor

6 - Libere o servidor

7 - Monitore atentamente o servidor nas primeiras semanas

Um pequeno lembrete para mim. Estou migrando do Oracle 9i para o 10g utilizando export e import.

O export por esquema “exp… owner… ” não traz para o Oracle 10g os usuários, portanto a importação irá falhar. O jeito é exportar primeiro os usuários. O procedimento é simples, basta puxar os usuários da tabela ‘dba_users’, mas um pequeno detalhe deve ser observado na importação da senha.

Segue o script:

SELECT
'CREATE USER ' || username ||
  ' IDENTIFIED BY VALUES''' || password ||
  ''' DEFAULT TABLESPACE ' || default_tablespace || ';'
  FROM dba_users
  WHERE
  password != 'EXTERNAL' AND
  default_tablespace NOT IN ('EXAMPLE','DRSYS','CWMLITE','ODM','XDB','SYSTEM')
  ORDER BY default_tablespace, username
;
 
SELECT
  'CREATE USER ' || username ||
  ' IDENTIFIED BY EXTERNAL DEFAULT TABLESPACE ' || default_tablespace || ';'  
  FROM dba_users
  WHERE password = 'EXTERNAL'
;

Não é nada complexo, mas o detalhe está justamente no uso da senha criptografada. Na documentação da Oracle sobre o comando CREATE USER, não aparece nada sobre a opção de criar um usuário com uma senha criptografada, somente com uma senha normal, que precisa clausula ‘VALUES’. Bom… demorei para lembrar deste pequeno detalhe, agora não esqueço mais!