yep, é bem comum vc ter um punhado de tabelas gigantes, excelentes candidatas
para insert /*+APPEND*/ , e ter um resto de tabelas relativamente pequenas, que
não compensam o trabalho de montar INSERT /*+APPEND */ nelas, podem
tranquilamente ser exportadas/importadas, sim ...
E só pra deixar claro pra quem eventualmente ler a thread, vc só está
testando/validando a possibilidade de criar banco vazio em novo release e
depois trazer os dados via import/dblink/whatever porque :
- a sua janela não obrigatoriamente tem que ser a menor das menores
e
- vc pensa que pode se aproveitar da vantagem de recriar, que é criar as
estruturas do banco vazio efetivamente usando as novas features e recomendações
da nova versão
é Claro que SE o tempo fosse absolutamente, completamente primordial já é
sabido que conversão é mais rápida que recriação, E se o seu objetivo fosse ter
o banco no novo release ainda sem usar/se aproveitar as novas features não se
justificaria criação de banco vazio + transferência de dados, só se faria mesmo
a Conversão do que vc já tem....
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Daniel Mello <djnmello@...> escreveu
>
> Show de bola Chiappa.
>
> Realmente não havia pensado na hipótese de criar dblink, criar faixas de
> execuções (no meu caso são poucas tabelas, porém gigantes) e disparar sessões
> em paralelo consumindo as faixas previamente criadas.
> Com insert + append e bulk collect imagino que a performance realmente será
> melhor do que exp/imp. Vou começar a testar para encontrar o melhor
> equilíbrio de "faixas x sessões" que meu hardware irá suportar. De qualquer
> forma respondo pra vocês qual foi a melhor alternativa pro meu cenário.
>
> Muito obrigado.
> Daniel.
>
>
>
>
> Em Terça-feira, 29 de Outubro de 2013 18:30, J. Laurindo Chiappa
> <jlchiappa@...> escreveu:
>
> Sim, é isso mesmo... Apenas friso que :
>
> a. sem a menor dúvida o procedimento de conversão/upgrade do banco que já
> existe vai ser Pelo Menos umas 3x mais rápido do criar banco vazio e
> transferir/exportar dados para ele, mas para saber exatamente o quanto mais,
> PLZ faça uma comparação ** JUSTA ** , usando os procedimentos Corretos -
> mandar um exp e um imp full com tudo default é Óbvio que vai demorar uma
> imensidão...
> Dá uma olhada nas msgs arquivadas do Grupo sobre o assunto, mas PELO MENOS
> vc deveria :
>
> 1. para as relativamente poucas tabelas Realmente gigantes que
> normalmente se tem num database , ao invés de exp+imp tente um INSERT /*+
> APPEND */ via dblink, em paralelo
>
> 2. vc vai exportar APENAS e TÃO SOMENTE dados : índices, constraints,
> estatísticas, grants, triggers e quetais vc só extrai o DDL, altera-o para
> permitir paralelismo/novalidate/nologging e só DEPOIS dos dados todos
> importados/inseridos vc os cria...
> Teste também o quanto melhora a performance da importação vc pré-criar
> antes as tablespaces/tabelas usando apenas tablespaces LMT, segmentos ASSM,
> initial/next/pctincrease controlado default pela tablespace, PCTFREE/PCTUSED
> otimizado para INSERTs (sem reservar espaço, ou reservando o mínimo para
> UPDATEs)...
>
> 3. vc vai ter múltiplas sessões de exportação e depois múltiplas de
> importação, em paralelo : quantas vai depender do seu hardware, mas teus
> testes vão indicar isso, fatalmente vc aumentando sessões simultâneas chega
> rapidamente uma hora que o retorno é negativo
>
> 4. se forem servidores diferentes, vc vai testar mas via de regra é mais
> performático vc gerar os arquivos de export localmente primeiro e só depois
> os transferir para o servidor-destino via ftp ou qquer coisa assim do que os
> gerar diretamente no servidor-destino via rede
>
> 5. as OPÇÕES , principalmente para a exportação , NUNCA devem ser default
> : se vc for usar exp tradicional (provável, já que 8i não aceita
> expdp/datapump), assegure-se de ao menos incluir (em todas as sessões)
> DIRECT=Y BUFFER=algunsmbytesnúmerograndemasquevcteemRAM RECORDLENGTH=65535
> STATISTICS=NONE RECORD=N COMPRESS=N
>
> b . Não deixe de aproveitar essas migrações-teste para TESTAR também a
> Aplicação contra o banco mais recente : não é de jeito nenhum impossível vc
> ter alterações até radicais de comportamento/performance no novo release do
> RDBMS, que podem demandar upgrade também do middleware, e/ou ajustes em SQLs,
> ou coisas assim...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, Daniel Mello <djnmello@> escreveu
> >
> > Muito obrigado a todos pela ajuda.
> > Pra eu encontrar a média de tempo para janela de migração, terei que
> > ensaia-la algumas vezes, vou tentar todas as alternativas para escolher a
> > que se sair melhor.
> >
> > Agradecido.
> > Daniel.
> >
> >
> >
> > Em Segunda-feira, 28 de Outubro de 2013 18:13, J. Laurindo Chiappa
> > <jlchiappa@> escreveu:
> >
> > Tudo jóia, Daniel ? Deixe-me aproveitar e esclarecer um pouco o assunto,
> > para vc poder fazer uma análise mais criteriosa aí das suas opções e tomar
> > uma decisão mais informada ....
> >
> > 1. Quando a gente fala em database , no mundo Oracle, a gente está se
> > referendo aos arquivos em disco que contém dados e metadados (ie,
> > datafiles, tempfiles, controlfiles, etc), arquivos esses que são
> > abertos/controlados pelo software RDBMS Oracle, formando a instância
> > Oracle...
> > Para podermos passar a utilizar uma versão mais recente do RDBMS Oracle
> > (o software), vc primeiro precisa (tirando um BACKUP COMPLETO antes, óbvio
> > :) instalar a nova versão do software no servidor em questão (no mesmo
> > diretório/oracle home ou em um diferente, embora o mais recomnendado seja
> > num HOME novo), E depois aí sim : ** OU ** vc cria um database vazio com
> > esses binários da nova versão e transporta/transfere os dados do banco
> > velho para o novo banco vazio, ** OU ** vc CONVERTE esse database (esse
> > conjunto todo de arquivos de dados e metadados) já existente para poder ser
> > aberto e usado pela nova versão de RDBMS...
> > Ambos os procedimentos tem vantagens e desvantagens : para a opção de
> > transferir os dados para um novo database, a Vantagem principal é que, como
> > vc criou um database vazio, com tablespaces novas, tudo novo, vc Obviamente
> > usou/vai usar as features de armazenamento e controle introduzidas pelo
> > novo RDBMS que te sejam úteis e que vc não usava na antiga, como (digamos)
> > ASSM, undo automático , tablespace SYSTEM criada como LMT, etc, etc... A
> > Desvantagem é que realmente criar E transferir os dados demora Muito Mais
> > do que só a conversão, que é relativamente simples e rápida.. Vice-versa as
> > vantagens/desvantagens de usar a conversão...
> >
> > 2. Rigorosamente NÃO É só o tamanho do teu database que vai ser o seu
> > único guia, mas sim TAMBÉM o tamanho da tua janela de manutenção : Lógico
> > que se vc tiver, digamos, os dois dias do fim de semana para fazer o
> > upgrade E as vantagens de recriar o database são atrativas para vc, Não Tem
> > porque deixar de considerar as técnicas de export/transferência de dados do
> > database velho para um novo recém criado vazio...
> >
> > 3. A sua performance NECESSARIAMENTE vai variar grandemente dependendo do
> > teu hardware, Óbvio, mas tipicamente em hardware de Produção eu vi
> > conversão de database de 500 GB demorar coisa de 4 ou 5 horas, e
> > transporte/export de dados (USANDO as técnicas corretas/adequadas. como
> > Paralelismo, múltiplas instâncias, não-validação de constraints, etc, etc)
> > para esses mesmos 500 GB levar coisa de umas 15 horas....
> >
> > []s
> >
> > Chiappa
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, Daniel Mello <djnmello@> escreveu
> > >
> > > Boa tarde pessoal.
> > >
> > > Por favor, tenho um banco para migrar e por ele ser uma versão antiga,
> > > a 8i (vai para a 11g), não sei ao certo qual estratégia usar, levando em
> > > consideração seu tamanho, aproximadamente 500gb, pensei em expdp, mas
> > > acredito que o tempo será mto alto para esse cenário. Alguém já fez algo
> > > semelhante?
> > >
> > > Obrigado.
> > > Daniel.
> > >
> >
> >
> >
> >
> > ------------------------------------
> >
> > --------------------------------------------------------------------------------------------------------------------------
> > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de
> > >inteira responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> > --------------------------------------------------------------------------------------------------------------------------
> > >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure
> > >» Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE:
> > >http://www.oraclebr.com.br/
> > ------------------------------------------------------------------------------------------------------------------------
> > Links do Yahoo! Grupos
> >
> > http://info.yahoo.com/legal/br/yahoo/utos/terms/
>
> >
>
>
>
>
> ------------------------------------
>
> --------------------------------------------------------------------------------------------------------------------------
> >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira
> >responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> --------------------------------------------------------------------------------------------------------------------------
> >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure »
> >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE:
> >http://www.oraclebr.com.br/
> ------------------------------------------------------------------------------------------------------------------------
> Links do Yahoo Grupos
>
> http://info.yahoo.com/legal/br/yahoo/utos/terms/
>
