Então Chiappa, eu não conhecia não. Já tinha utilizado o SQL LOADER,que é bem parecido com esse recurso da external table, que utiliza o ORACLE_LOADER.
Logo que o Alexandre comentou sobre a external table, troquei uma ideia com ele. Realmente é uma alternativa bem interessante, o único porém é a questão do log de saída. Como vou executar esse programa de um concurrent no EBS, o ideal era ter o log todo no log do próprio concurrent, para o usuário poder identificar qualquer problema. Pelo que vi, o external table gera um arquivo de log separado. Eu teria que ter um outro comando para ler esse arquivo de log e colocar na saída do concurrent. Sem contar que não teria como formatar, pois não tenho controle sobre como esse arquivo é gerado. Fazendo pelo processo normal, lendo linha a linha via PL/SQL, eu consigo saber em cada linha o que acontece e posso mostrar da maneira que eu quiser no log. Não sei se fui claro... -- Eduardo Schurtz 2014-04-16 18:44 GMT-03:00 <jlchia...@yahoo.com.br>: > > > Blz ? Então, a opção de carregar os dados do arquivo pra GTT (seja como > for, com SQL ou PL/SQL, bulk ou não, etc), simplesmente ** NÃO FAZ SENTIDO > ** frente à opção de EXTERNAL TABLE - não sei se vc a conmhece, mas é uma > feature relativamente antiga que permite que vc use o arquivo-texto > DIRETAMENTE NUM SQL, como se ele fosse uma tabela , SEM a necessidade de > carregar os dados pra dentro do banco, okdoc ?? veja vc, com GTT vc iar > fazer ** DUAS ** (2) leituras completas no arquivo-texto, UMA para carregar > o texto pra dentro da GTT e OUTRA para ir lendo os dados da GTT, com > EXTERNAL TABLE vc simplesmente faria um JOIN (ou mesmo um MERGE - veja > http://www.akadia.com/services/ora_etl.html#The%20MERGE%20Statement para > um exemplo, e o manual de SQL Reference e o de DW Oracle para mais > detalhes) !! Com isso num ÚNICO SQL vc já lê os dados do arquivo-texto e > faz a comparação com os dados da tabela, SEM precisar se preocupar com > limites de arrays, SEM precisar se preocupar com tamanhos de resultsets > (pois COMO SABEMOS um SQL pode manipular Qualquer Quantidade de registros > num database Oracle através do mecanismo de FETCH automático que possui), e > ainda por cima via de regra vc obtém a melhor performance (pois um único > SQL significa menos código Pl/SQL a analisar, um SQL puro pode se > beneficiar das transformações/otimizações que o RDBMS pode fazer, o que um > cursor PL/SQL ** TOTALMNENTE nÃO CONSEGUE **), é tudo de bom... > > []s > > Chiappa > >
