Opa, blz ? Sobre PERFORMANCE nem preciso dizer que a pessoa TEM que testar no seu ambiente, com a sua versão e as suas restrições, mas via de regra, se o desejado é ** realmente ** processar múltiplas linhas de uma vez E o ambiente é capaz de suportar um suculento scanzão (provavelmente em parallel, etc), sem dúvida MERGE é o caminho : https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:13401777766527 exemplifica (dramaticamente, caso de alguns minutos versus algumas horas - NEM SEMPRE se obtém algo tão evidente) mas isso é a indicação geral.... CASO não seja possível um único suculento MERGE (por causa de alguma das restrições que vou citar), normalmente um BULK COLLECT com um arraysize decente é uma aposta segura, MAS aí a pessoa provavelmente vai ter que paralelizar por conta própria, e se fazer isso abrindo múltiplas sessões PROVAVELMENTE VAI CAIR na questão de uma sessão não vendo registros inseridos em outra - essa INTERCOMUNICAÇÂO entre as sessões não é algo Simples de se fazer na mão, e é um dos Trunfos do Parallel ...
Sobre restrições do MERGE : a) cada registro lido tem que fazer match em UM e APENAS UM registro da tabela destino, então fontes de dados a carregar "sujas", com repetições, OU tabelas-destino sem chaves, via de regra causam issues b) normalmente não é permitido o MERGE fazer update nas colunas da chave, referidas na cláusula ON c) via de regra o INSERT feito é "normal" - nada de APPEND-mode -, e (devido ao MERGE processar lendo uma só vez a fonte de dados) normalmente não tem como o RDBMS detectar que o volume de UPDATEs é tão alto que valeria mais a pena truncar e inserir em append-mode os dados com as alterações : em ambientes DW típicos, essas coisas PODEM interferir em performance/usabilidade do MERGE d) salvo alguma alteração recente que eu esteja por fora, afaik não tem como vc ter SQL dinâmico nas cláusulas de MATCH/NO MATCH : lógicas doidas tipo "se o dado lido é X, inserir na tabela T1, se for Y inserir na tabela T2, etc" inviabilizam MERGE... Idem se vc quiser ter qualquer lógica que não seja logar numa tabela de erros as exceptions.... e) MERGE é um sql único e atômico, então ROWCOUNT vai te dizer (como qualquer outro SQL) o ** Total ** de linhas processadas : se vc precisar saber Separadamente qtdade de inserts e de updates, afaik não vai conseguir f) para vc poder Paralelizar um MERGE único, que lê toda a fonte de dados (via de regra é ISSO que se quer) a fonte de dados TEM que estar disponível pro banco Oracle : assim, se (digamos) a fonte for um arquivo-texto que vai ser lido via EXTERNAL TABLE, o arquivo TEM que estar acessível pelo servidor do RDBMS Oracle De cara são essas que me recordo mais.... []s Chiappa
