Buenas pra todos que acompanham nossas postagens aqui!
Vou explicar aqui, brevemente, a estratégia utilizada para a migração do ambiente de um cliente.

Cenário antigo:
O.S. 64bit
Oracle 9i 32bit enterprise (banco 32 em o.s. 64...)
Tamanho inicial do banco:
Tamanho do Banc Espaco Utilizad Espaco Livre
--------------- --------------- ---------------
694782 MB       567235 MB       127547 MB

free -m
             total       used       free     shared    buffers     cached
Mem:         64422      64211        211          0        311      56889
-/+ buffers/cache:       7010      57412
Swap:        17406        127      17278

Dois Intel(R) Xeon(R) CPU X5570  @ 2.93GHz quad-core, com HT,
atuando como 16 cores
Cenário desejado:
O.S. 64bit
Oracle 11g 64bit enterprise (em matriz suportada pela Oracle...)
Tamanho final do banco:
Tamanho do Banc Espaco Utilizad Espaco Livre
--------------- --------------- ------------
400386 MB       370658 MB       29728 MB

free -m
             total       used       free     shared    buffers     cached
Mem:        129060     128670        389          0        323      25250
-/+ buffers/cache:     103097      25962
Swap:        16378         63      16315

Dois Intel(R) Xeon(R) CPU X5670  @ 2.93GHz six-core, com HT,
atuando como 24 cores

* A janela disponível para a migração era de 4hs;
* Não podíamos utilizar o ‘upgrade’ pois o banco 9i já teve vários sinistros e não queríamos corrupções e vícios;
* Um SCHEMA corresponde a praticamente 80% do tamanho final do bd;
* Aproveitando o poderío do hardware (proc + mem + I/O) a chave para otimizar o processo foi… paralelizar ao máximo! 🙂
* Desta forma chegamos a seguinte estratégia de migração:
A- Preparação da base no dia anterior:
– Limpeza (drop database) da base utilizada para inúmeros testes;
– Limpeza dos logs dos scripts shell desenvolvidos para a migração;
– Criação do banco conforme a produção 9i, com as tablespaces já pré-alocadas no tamanho final;
– Export full rows=n a partir da produção 9i;
– Import full rows=n ignore=y indexes=n constraints=n para a criação dos usuários e import dos objetos e estrutura de tabelas;
– Criação de db_link entre as bases 11g e 9i e ajuste dos grants do sys para usuários (v$session, v$instance…)
– Compilação dos objetos inválidos (utlrp.sql);
– Disable das triggers e drop das sequences;
– Alter table setando o degree para 60 das 20 maiores tabelas (para habilitar constraints em parallel);
– Script de comparação de objetos entre as instances 9i e 11g (ignorando a diferença das sequences dropadas).

B- Upgrade day!!! Start 0h e 25m do dia 18/03/2012
— Foram separados 4 SCHEMAS denominados ‘big owners’ e outro SCHEMA denominado ‘master owner’, estes SCHEMAS não seria migrados via exp/imp e sim via db_link, reduzindo drasticamente o tempo de migração!
– Exp indexes=y constraints=y do restante dos SCHEMAS;
– Paralelo ao passo acima foram disparados os seguintes scripts:
— Insert via db_link (INSERT /*+ APPEND Parallel(A,6) */) para todas as tabelas dos ‘big owners’, create dos indexes (parallel 60) e create das check constraints;
— Para o ‘master owner’ foi utilizado outro nível ainda de paralelismo dividindo os processos em 10 scripts para insert via db_link e create index (parallel 60) das maiores tabelas e outros 2 scripts onde foram divididas o restante das tabelas do ‘master owner’ (insert db_link+create index+create constraint)
– Após término do exp dos SCHEMAS, disparo de forma paralela do imp de todos os dumps indexes=y constraints=n
– Após término dos imps disparo de script para criação das constraints (PK e UK) de todos os SCHEMAS;
– Após os inserts via db_link, disparo de script para criação das constraints (PK e UK) do ‘master owner’;
– Dois disparos de imps dos SCHEMAS de forma serializada para enable das constraints rows=n constraintsy;
– Último import full indexes=y rows=n ignore=y constraints=y para que fossem criados quaisquer indexes que tivessem faltado e/ou constraints;
– Ajuste dos parâmetros:
alter system set parallel_max_servers=12 scope=both;
alter system set optimizer_index_cost_adj = 30 scope=both;
alter system set optimizer_index_caching = 90 scope = both;
– Disable do degree para as 20 maiores tabelas e para os indexes criados com parallel 60;
– Enable das triggers;
– Import das estatísticas do banco 9i;
– Comparação dos objetos entre as instances 9i e 11g, agora já levando em conta as sequences ajustadas nos últimos imports realizados;
– Script para comparação de quantidade/status das constraints entre as instances 9i e 11g;
– Comparação dos jobs entre as instances 9i e 11g;
– Compilação dos objetos inválidos (utlrp.sql);
– Script de comparação de dados entre instances, ou seja, fazia um select count(*) from tabela where rownum = 1 no 9i e fazia o mesmo no 11g, caso houvesse diferença logava em uma tabela. Com isso poderíamos ver qualquer tabela que não tivesse sido carregada, tendo dados na origem, mas não no destino.

Ufaaaaa… acreditem se quiser senhores… com esse controle todo, esse paralelismo todo, e tirando todo o proveito do ótimo hardware oferecido, fomos capazes de migrar essa base em 200 minutos.

A máquina em certos momentos atingiu um L.A. de 142… hehehehe, principalmente durante a criação dos indexes com paralell 60 e enable das constraints. Chegavam a existir em certo momento 260 processos slave no banco. (evil… hehehehe)

Então foi isso, gostaria de compartilhar essa experiência com todos… foi um ótimo aprendizado e exigiu muito controle e log de tudo, mas otimizou demais o processo!
Qualquer dúvida, maiores explicações ou até mesmo sugestões de como eu poderia ter melhorado o processo, por favor comentem.
Um grande abraço…

Ps. Amigo Valter, vale uma barra de chocolate se adivinhar qual o cliente e qual a base? 😉

Att,/Regards,

Vitor Jr.
Infraestrutura / Infrastructure Team
Oracle 11g DBA Certified Professional – OCP
Oracle Database 11g Performance Tuning Certified Expert – OCE
Oracle Exadata 11g Certified Implementation Specialist
mail, gtalk e msn: vitorjr81@gmail.com
skype: vjunior1981