Baseado parte na documentação Oracle (manuais e notas do Suporte), parte na minha experiência, so EXP em geral, e das suas experiências, eu digo o seguinte : primeiro, quando o exp foi criado (no tempo em que os dinossauros andavam pela Terra, lá pela versão 6 do bd :), o bd Oracle já rodava em múltiplas plataformas, E portanto o formato de bloco, de datafile, o formato físico enfim já era diferente entre as plataformas, E mesmo na mesma plataforma mas entre versões de bd diferentes os formatos podem/podiam mudar, então o paradigma principal, a função cruz do exp era e é sem ** COMPATÍVEL ** entre SOs/plataformas diferentes e entre versões diferentes do banco (versão origem sendo MENOR OU IGUAL á destino, é claro), NOS CASOS EM QUE os bancos não tinham comunicação de rede confiável e boa entre si (pois senão se usava dblinks e SQLs entre os bancos, nessa versão isso já existia - ASSIM SENDO, a sua opção de usar exp+imp pruma migração NO MESMO BANCO certamente é questionável...). Por causa disso, , TODAS as opções que poderiam acrescer performance mas interferir na compatibilidade foram sempre limadas dele, não era e não é só a performance em si o escopo desse cara - nessa toada, o export ** sempre ** gera comandos SQL dentro dum .DMP (só quem grava blocos diretamente é o nosso amigo RMAN), via de regra NÃO gera esses SQLs (tanto os DMLs, como INSERT, quanto os DDLs, como CREATE INDEX) em modo APPEND (pois sabe-se lá se o banco destino é archive ou não, se está usando bd hot incremental ou não), não usa paralelismo (sabe- se lá se o bd destino o aceita, se não é bd Standard onde parallel não funciona), não usa array processing (ou o usa bem pequeno), normalmente gera UM INSERT pra cada registro a criar... Essas 2 últimas características, INCLUSIVE, ajudam a explicar o porque do CREATE TABLE nnn as (SELECT from outrabela) ser via de regra *** MUITO muito *** mais rápido que exp+imp, pois com o CREATE : - normalmente ele é executado no sql*plus, que JÁ APLICA array processing automaticamente (pequeno, com 15 regs normalmente, mas aplica), o imp é uma linha lógica por vez - um comando SQL como CREATE é atômico, é uma "coisa" única que é executada (e portanto parseada) apenas uma vez, enquanto o imp tem um ** cursor *8, que deve ser aberto, E cujos valores de bind DEVEM ser informados pra cada linha a inserir.... isso NÂO É "grátis" o processamento no banco, isso exige SIM CPU extra, um pouco de RAM extra.... Pra vc comprovar que é isso mesmo, pesquise em http://asktom.oracle.com por PERFORMANCE SQL PROCEDURAL que vc acha n exemplos onde um único comando SQL dá um ** BANHO ** de performance na opção procedural linha a linha ==> e é claro, SE além disso tudo vc ainda usar modo APPEND, aí é até covardia, o CREATE dá de goleada... Outra coisa é que o nosso amigo exp e seu companheiro imp foram criado lá no período jurássico e cfrme a Terra foi girando e as eras passando ele NEM SEMPRE foi atualizado correspondentemente, ** PRINCIPALMENTE ** na versão 8i em diante do banco, onde OUTRAS opções foram agregadas ao banco (exemplo, dump de dados com o logminer, cópia de arquivos via transport tablespace, envio de dados com MVs e STREAMS e stanbys diversos), com essa evolução de outros métodos o exp/imp pura e simplesmente foi aos poucos ficando LEGADO, até que finalmente na versão 10g ficou mesmo obsoleto. Assim sendo, TODA e QUALQUER feature de banco criada na 8i ou após vc pode SIM ter senões, falhas, bugs lógicos (ou mesmo físicos!!) se for aplicado exp/imp num bd que as use - como exemplos, sem ser lista total e completa, eu citaria MVs, SQL types, object/nested tables, directories, tabelas externas, funções analíticas, opções "avançadas" de SQL como WITH clause, column subquery, subquery na cláusula FROM , etc... Assim sim, no caso específico da MV o exp/imp usa a sintaxe 8i anterior de CREATE SNAPSHOT, fatalmente pode dar enrosco - desse modo, eu se vou usar exp/imp ** E ** o banco em questão possui features pós-8i, eu COM ABSOLUTA CERTEZA testo antes...
Ainda outra, também como resquício da sua antiguidade, exp e imp tem DIVERSAS opções que hohe em dia não se justificam mais (como COMPRESS, que hoje em dia com as tablespaces LMT rulando não faz sentido), E tem diversos outros que interferem MUITO positivamente na performance, TRANQUILAMENTE poderiam estar ativos como default mas não estão, como DIRECT, BUFFER, RECORDLENGTH, a pessoa que usará o programa TEM QUE ter estudado no manual de Utilities quais são e o que fazem as opções, pra poder usar as melhores E finalmente, ainda em nome da compatibilidade, pra poder rodar na maioria dos hardwares, o exp e o imp são SERIAIS, ie : primeiro trabalham a primeira tabela, só depois a segunda, só depois a terceira..... Hoje em dia qquer servidor minimamente decente tem capacidade pra fazer mais que isso. Então o resumo da ópera é : - usar o exp/imp só onde REALMENTE for preciso (ie, não há possibilidade de se aplicar outros comandos/opções/utilitários) - testar se vc tem feats pós-8i - sabendo que o exp/imp NÃO usam todas as opções possíveis de performance por questões de compatibilidade, VC AS USAR onde adequado , principalmente constraints criadas sem serem validadas (pois já o foram no bd origem), APPEND mode e paralelismo - sabendo que o exp/imp é serial, dar uma paralelizada rodando vários []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Everton Dias" <[EMAIL PROTECTED]> escreveu > > Pessoal, uma ferramenta muito utilizada é o exp / imp, porém o mesmo apesar > de simples requer algum conhecimento de seu funcionamento, tanto para evitar > surpresas quanto para se tirar o máximo de proveito da ferramenta, como por > exemplo: > > - Fiz um export de alguns schemas e os importei em outro db, porém depois > notei que as materialized views se transformaram em tabelas na base de > destino....pra mim isto foi um surpresa. > > - Como em uma de minhas migrações eu estava trocando a base para outra base > na mesma máquina (trocando de storage e aproveitando para reorganizar os > objetos) notei que as tabelas maiores poderiam ser levadas **MUITO** mais > rapidamente se fossem levadas com create table as select ao invés de export > impor... o que pra mim tb foi uma surpresa. > > Como cada dia que uso esta ferramenta descubro opções e detalhes como estes, > gostaria de compartilhar este conhecimento e também pedir para que os > colegas compartilhem pontos como estes... acredito que seria muito > interessante. > > Por exemplo, alguem tem algum roteiro, check list, ou curiosidade sobre > migrações com exp / imp ? > > Obrigado. > > _________________________________________________________________ > MSN Busca: fácil, rápido, direto ao ponto. http://search.msn.com.br >
