Sobre o work-around, eu realmente ** jamais ** adivinharia , até porque vc
Não Disse que era um banco usando o (obsoleto e não-Suportado no 10g) modo
regra... Sobre o FLASHBACK, como eu disse, será que REALMENTE não teria uma
janela para vc fazer o export ? Pois SQL por SCN ** tem ** o seu preço para
performance, e não é desprezível, dependendo da carga/nível de utilização...
Da mesma maneira, vc não disse que era banco não-EE, então paralelismo de SQL
realmente tá fora... NÂO DEIXE de experimentar/testar as Outras opções de
performance que citei, porém, BEM COMO de mensurar a performance do exp
(bem-ajustado com todos os parãmetros que citei, etc) contra o expdp - teste
AMBOS via exportação do mesmo schema (só dados, sem constraints/índices/nada),
e veja o que vai ver...
Finalmente : o objetivo aqui quando eu falo de quebrar a exportação (talvez
por schema) é, além do fato de vc EVITAR exportar schemas presentes no seu
banco mas irrelevantes para a aplicação (exemplo, schema de intermedia/text,
schemas-exemplos, schemas internos como o SYSTEM, etc, e´como eu disse, vc ter
múltiplas sessões fazendo exportação : o busílis é que se vc tiver uma sessão
só, no momento em que ela começa a fazer a exportação de um objeto grande, só
quando essa exportação terminar é que o próximo objeto é exportado - é MUITO
mais eficiente vc ter outras sessões de exportação exportando outros objetos
menores enquanto o grande está sendo cuidado por outra...
O ponto a notar é que eu estou Imaginando que mais ou menos as tabelas
grandes estao distribuídas pelos schemas : caso haja um schema especial que
contenha quase todas as tabelas grandes, talvez seja mais eficiente vc ter uma
sessão de export exportando a tabela grande A, outra exportando a tabela grande
B, outra exportando a tabela grande C, e umas outras duas sessões, talvez,
exportando os schemas que só tem tabelas pequenas.... O teu objetivo aqui é
usar a capacidade do subsistema de I/O no máximo possível, sim ? POR ISSO
também que seria muito, mas MUITO mesmo, recomendável vc fazer esse export
numa janela de manutenção, EVITANDO concorrência com usuários, okdoc ? SE vc
não tiver DE JEITO NENHUM uma janela de manutenção, aí vc VAI pagar o preço do
FLASHBACK (ou do CONSISTENT=Y no exp tradicional), VAI pagar o preço de não ter
todaa capacidade de I/O para vc, VAI pagar o preço de ter que ficar indo atrás
de bloco de rollback/undo (se houver DML concorrente com os dados a exportar),
não tem milagres...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Régis Pradela escreveu
>
> Chiappa, boa tarde!
>
> Muito obrigado pela resposta, mas o bug indiciado nos links são diferentes
> do que enviei, vide mensagem de erro.
> Quanto a parte de paralelismo, infelizmente não é um ambiente EE, sendo
> assim, vou implementar o mesmo "na unha", como tenho diversos schemas no
> banco de dados, vou quebrar em diversos processos de exp/imp, por schema.
> Quanto ao flashback_time, estou utilizando pois como estou montando uma
> homologação do ambiente, o atual produção está sendo utilizado e não posso
> para-lo agora, durante a migração não estarei utilizando este parâmetro.
>
> Porem, tenho boas noticias, acabei de encontrar um solução de contorno, em
> um forum chinês (god bless google translate!!) encontrei um usuário com o
> mesmo erro e dizendo algo do tipo, "após ajustar o otimizador, o problema
> foi sanado", pois bem, este banco trabalha com o otimizador em modo regra,
> sendo assim, mudei o otimizador para custo, e o problema foi sanado.
> Como a aplicação "recomenda" utilizar modo regra, fiz uma trigger para
> alterar sempre que for uma sessão do datapump.
>
> Grande abs.
> --
> R.P.
> DBA Oracle
> Blog: www.rpradela.com.br
>
> Oracle Database 11g Administrator Certified Professional
> Oracle Database 11g Administrator Certified Associate
> Oracle Database 10g Real Applications Clusters Administrator Certified
> Expert (OCE)
> Oracle Enterprise Linux Certified Implementation Specialist (OCE)
> Oracle Database 11g Data Warehousing Certified Implementation Specialist
> Oracle Exadata 11g Certified Implementation Specialist
>
> From: "J. Laurindo Chiappa"
> Reply-To:
> Date: segunda-feira, 11 de fevereiro de 2013 16:55
> To:
> Subject: [oracle_br] Re: Problemas com o Datapump
>
>
>
>
>
>
> Colega, muito provavelmente é bug Reconhecido : aqui no Grupo mesmo
> http://br.groups.yahoo.com/group/oracle_br/message/111598 mostra um caso
> aonde apareceu esse comportamento em 10.2.0.4, e
> http://arjudba.blogspot.com.br/2010/12/datapump-export-expdp-client-gets-ude
> -8.html também .... Veja a nota metalink referente e experimente aplicar o
> patchset 10.2.0.5 ao menos, esse cara corrigiu um caminhão de bugs
> referentes à datapump, Enormes chances desse daí estar listado nas correções
> do 10.2.0.5 também...
>
> Especificamente sobre performance, um outro ponto é que DE FORMA ALGUMA vc
> pode esperar meter um FULL=Y (o que IMPLICA ter apenas UMA sessão de
> exportação, além de exportar INCLUSIVE schemas eventualmente desnecessários)
> e esperar ter a máxima performance, okdoc ? PARALELISMO é o nome do jogo
> quando se fala de exportação em grandes volumes... Da mesma forma, para que
> vc está especificando um FLASHBACK_TIME ?? Via de regra, se vc vai fazer uma
> migração, isso é uma operação PLANEJADA, em que há uma Janela de Manutenção
> sem usuários ativos, sim ?
>
> Além disso eu recomendo (tanto na tentativa de melhorar performance quanto
> de tentar work-aroundar os bugs) que vc considere os pontos abaixo, COM A
> RESSALVA que tanto a quantidade de RAM a alocar, quanto o número de sessões
> de exportação simultâneas, quanto a qtdade de Parallelismo nos SQLs do
> datapump não podem ser NEM demasiados, sob pena de vc criar gargalos, nem
> inexistentes ou muito pequenas - alguma experimentação no SEU ambiente, com
> o SEU hardware, deve ser esclarecedora :
>
> - quando vc vc fazer o paralelismo de execução (ie, ter Múltiplas sessões de
> exportação simultâneas, cada qual fazendo um schema, talvez), tente NÃO usar
> o nome de arquivo com variável(como auquela %u) - tente usar nomes FIXOS ,
> para tudo (dump files, logs, diretórios, Tudo)
>
> - não informe o nome de job
>
> - NÃO exporte índices e constraints, pois além de causarem mais I/Os eles
> podem causar má-performance se importados : é MUITO mais eficiente vc
> exportar APENAS e TÃO SOMENTE os dados, os importar, depois exportar o DDL
> de índices e constraints, e finalmente alterar esses DDLs para que eles
> possam ser Aplicados no banco-destino em modo PARALLEL DDL, com
> NOVALIDATE/NOLOGGING, cfrme necessário
>
> - use os parâmetros adequados para performance : no caso do datapump,
> principalmente PARALLEL (qtdade de paralelismo nos SQLs) e ajustes de banco
> (como aumento temporário de PGA e SGA, alocação de LARGE POOL, colocação de
> tabelas em modo NOLOGGING para permitir a IMPORTAÇÃO em direct-mode, etc), E
> no caso do exp tradicional principalmente é usar DIRECT=Y BUFFER=qtdade em
> bytes que vc VAI ter com certeza livre RECORDLENGTH=65535 10485760 , além
> das opções de Exclusão correspondentes...
>
> ==> Aliás, antes de descartar o exp tradicional, PLZ faça um teste JUSTO,
> colocando as opções de performance como necessário, para ver se Realmente o
> exp não serviria...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br
> , Régis Pradela escreveu
> >
> > Senhores, boa tarde!
> >
> > Estou enfrentando alguns problemas utilizado o Datapump, gostaria de saber
> > se já viu este problema:
> >
> > ==> Ambiente:
> > Virtualizado com Oracle VM
> > SO: Oracle Enterprise Linux 5.2
> > RAC 10.2.0.4
> > RDBMS 10.2.0.4
> >
> > Ao iniciar o export do banco de dados o seguinte erro é encontrado:
> > [oracle@prd migra]$ expdp system/xxx parfile=expdp.par
> >
> > Export: Release 10.2.0.4.0 - 64bit Production on Monday, 11 February, 2013
> > 16:03:28
> >
> > Copyright (c) 2003, 2007, Oracle. All rights reserved.
> >
> > Connected to: Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
> > With the Real Application Clusters option
> > Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** parfile=expdp.par
> > Estimate in progress using BLOCKS method...
> > Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
> >
> > UDE-00008: operation generated ORACLE error 31626
> > ORA-31626: job does not exist
> > ORA-06512: at "SYS.KUPC$QUE_INT", line 536
> > ORA-25254: time-out in LISTEN while waiting for a message
> > ORA-06512: at "SYS.DBMS_DATAPUMP", line 2772
> > ORA-06512: at "SYS.DBMS_DATAPUMP", line 3886
> > ORA-06512: at line 1
> >
> > Conteúdo do arquivo de parâmetros:
> > CONTENT=ALL
> > DIRECTORY=dmpdir
> > DUMPFILE=expdp_full_prd_%u.dmp
> > FLASHBACK_TIME="to_timestamp(to_char(sysdate,'yyyy-mm-dd
> > hh24:mi:ss'),'yyyy-mm-dd hh24:mi:ss')"
> > FULL=Y
> > JOB_NAME=expdp_full_prd
> > LOGFILE=expdp_full_prd.log
> > EXCLUDE=STATISTICS
> > FILESIZE=8G
> >
> > Fiz testes com o full e também por schema.
> > Verifiquei que todos os componentes do banco de dados estão válidos.
> > Segui a nota do metalink "How To Cleanup Orphaned DataPump Jobs In
> > DBA_DATAPUMP_JOBS ? [ID 336014.1]".
> >
> > Enfim, acredito ter feito a lição de casa, porem, não encontro resolução
> > para este problema.
> >
> > Estou precisando migrar dois bancos de dados (LNX --> AIX) , que são
> > grandes, e via exp/imp convencional está demorando muito, espero que possam
> > me ajudar.
> > Sei que posso utilizar outras formas de migração (RMAN convert + TTS), mas o
> > cliente espera que os objetos sejam reorganizados, por isto o datapump me
> > ajudaria bastante.
> >
> > OBS: o datapump via rede (dblink) funciona, mas, demora muito para
> > executar.
> >
> > --
> > R.P.
> > DBA Oracle
> > Blog: www.rpradela.com.br
> >
> > Oracle Database 11g Administrator Certified Professional
> > Oracle Database 11g Administrator Certified Associate
> > Oracle Database 10g Real Applications Clusters Administrator Certified
> > Expert (OCE)
> > Oracle Enterprise Linux Certified Implementation Specialist (OCE)
> > Oracle Database 11g Data Warehousing Certified Implementation Specialist
> > Oracle Exadata 11g Certified Implementation Specialist
> >
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
>
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
