Então : veja que tanto a EXTERNAL TABLE quanto a operação de MERGE que eu
recomendo como sendo (e na Esmagadora maioria das vezes é MESMO) mais Rápida
são built-ins, nativos DO DATABASE, então por isso se por um lado te dão a
performance TOP (internamente elas são código C , ** compilado ** dentro do
database, e que usa & abusa dos hooks internos do database, coisas essas
inerentemente VEDADAS ao teu código Pl/SQL coitadinho INTERPRETADO e EXTERNO),
por Outro lado são fechados e algo inflexíveis, fazem o que fazem e cabou ....
Veja em
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:6618304976523#6623196184466
um pouco sobre as questões de performance, em
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1500471500346067777
a opção de log de erros e em
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:35615502072484#35632246331433
os detalhes sobre qtdade de registros processados , e decida se essas coisas
te atendem OU se realmente vc quer trocar performance e eficiência por controle
e log detalhado...
SE quiser/precisar optar pela opção menos performática porém mais controlada
de fazer o processamento EXTERNAMENTE ao database, sem ser por um só comando
SQL, AUTOMATICAMENTE vc vai ter que escrever mais código e VAI ter que se
preocupar com limites dos resultados.... E que fique CLARO, esses limites (que
incluiriam o LIMIT da cláusula de COLLECT, e tamanhos de arrays) não são
GENÉRICOS, eles dependem fundamentalmente do SEU ambiente, de quanta RAM vc tem
livre, da capacidade/poder de processamento... É TOTALMENTE POR SUA CONTA,
portanto, testar no SEU ambiente e ver até onde vc pode chegar sem queda de
performance e sem erros ORA-40xxx de falta de recursos : os valores de 100
registros coletados por vez que vc vai encontrar tanto na documentação quanto
(principalmente) na maioria dos links que goolglar e/ou que vou indicar) são
simplesmente um valor TÍPICO, mas nem de longe isso vai ser Ótimo no seu
ambiente...
Eu ** IMAGINO ** que a opção menos ruim de processamento PL/SQL aonde vc teria
a opção de controle detalhado/log detalhado de cada registro seja a external
table sendo joineada num cursor PL/SQL com a tabela a atualizar, sendo lida com
BULK e o UPDATE é em múltiplos registros de uma vez com FORALL - veja
http://www.morganslibrary.org/reference/plsql/array_processing.html ,
http://ksadba.wordpress.com/2008/06/16/updating-millions-of-rows-merge-vs-bulk-collect/
,
http://www.oracle-base.com/articles/9i/bulk-binds-and-record-processing-9i.php
(e seus links do 10g) e http://psoug.org/reference/array_processing.html para
refs/exemplos, BEM COMO os manuais Oracle correspondentes....
REPITO, o que não faz sentido é vc ler 2x o arquivo de texto, sendo uma vez
pra carregar na GTT e Outra vez para processar a GTT - talvez a exceção seja
se vc quiser ter o log detalhado da leitura do arquivo-texto (digamos, log dos
registros inválidos) : como vc aprendeu, o log da external table em si é o que
é, no formato e na localização que é : CASO realmente precise muito de algo
diferente E não seja viável ler/transformar o log da external, não tem jeito é
engolir o sapo e a GTT sem tempero, sim ... Aí o BULK/FOR ALL vai usar a GTT ao
invés da external...
[]s
Chiappa
