Bem, imho a pessoa ** não ** vai ter que "usuário vai ter que analisar o log
do concurrent e depois o log do LOADER/external table", pois os logs detalhados
que são gerados para a external table são em caso de EXCEÇÕES (ie, o BADFILE eo
DISCARDFILE), enquanto o LOGFILE propriamente dito tem poucas e curtas msgs
...Por exemplo, veja abaixo o logfile de uma query bem-sucedida (sem exceções)
numa external table :
/tmp$ cat POP_EXT_3688.log
LOG file opened at 04/17/14 13:08:54
Field Definitions for table POP_EXT
Record format DELIMITED BY NEWLINE
Data in file has same endianness as the platform
Rows with all null fields are accepted
Fields in Data Source:
CITY CHAR (255)
Terminated by ","
Trim whitespace same as SQL Loader
COUNTRY CHAR (255)
Terminated by ","
Trim whitespace same as SQL Loader
POPULATION CHAR (255)
Terminated by ","
Trim whitespace same as SQL Loader
/tmp$
==> é informação técnica INTERNA, absolutamente Não Interessante para o
usuário-final, yep ?? Então imho vc simplesmente teria uma tela customizada
aonde, SE / QUANDO o usuário precisar, ele lê o BADFILE e o DISCARDFILE, Acho
que é isso que o usuário precisaria ter...
Já sobre o ponto de verificar se o registro que está vindo existe, e gerar uma
mensagem se não existir : não sei se o MERGE aceita, mas veja lá se vc não
poderia simplesmente pedir pro MERGE fazer o INSERT duma string numa tabela de
erros, que depois vc apresentaria na tela de log pro usuário... Eu ACHO que não
daria, mas veja lá...
Sobre a questão de leitura dos dados e comparação, sim : para evitar o
trabalho de carregar o arquivo-texto pra uma GTT antes de poder acessar, é o
que vc falou, seria um OUTER JOIN, sim:
for r in (SELECT dadosdesejados FROM tabelareal A, externaltable B
WHERE A.colunachave (+) = B.colunachave
loop
....
IF r.colunachave IS NULL then -- não houve match
gera uma mensagem...
claro, o PL/SQL sempre trabalha logicamente registro-a-registro mas
OBVIAMENTE vc colocaria os registros lidos e a updatear/inserir num ARRAY, é
isso que faz a cláusula de BULK COLLECT e o FORALL .... yes ?? Se REALMENTE vc
precisa gerar uma ação espeífica para cada registro processado, aí a solução de
apenas SQL (que sria o MERGE) não atende, aí toca a aceitar a performance
provavelmente inferior e programar em PL/SQL, sim....
E o último ponto, sobre a falta de índice na external table - veja, eu entendo
que a. a tabela real vai ser ** muito MAIOR ** que o arquivo-texto com os
dados a carregar E QUE necessariamente os dados TODOS que estarão no
arquivo-texto TEM QUE SER PROCESSADOS do primeiro ao último, Integralmente, sim
??? Notar que o índice só é positivo para a performance quando vc quer
recuperar UM, ou no máximo uma pequena FRAÇÃO do todos, aí o fato de vc
precisar ler o arquivo-texto TODINHO inviabilizaria o uso de índice, okdoc ???
Por isso que a Oracle não colocou ainda a opção de indexação em external
tables, tipicamente esses caras são dados a carregar/procesar, TEM que ser
lidos integralmente, não compensaria para a performance..... E o fato da tabela
real de destino ser (imagino) MUITO MUITO maior e o fato de que é nela que vc
tem que procurar para ver se o valor lido da external existe ou não indicaria
que o índice útil aí seria é na TABELA REAL, que é Muito maior E é onde
queremos pesquisar apenas uma linha, yep ??
[]s
Chiappa
