Melhore as estatísticas. O número estimado de linhas é 1, mas o número real de linhas é superior a 7 milhões e continua aumentando. Isso faz com que o plano de execução use um loop aninhado em vez de uma junção de hash. Um loop aninhado funciona melhor para pequenas quantidades de dados e uma junção de hash funciona melhor para grandes quantidades de dados. Corrigir isso pode ser tão fácil quanto garantir que as tabelas relevantes tenham estatísticas precisas e atuais. Isso geralmente pode ser feito coletando estatísticas com as configurações padrão, por exemplo:exec dbms_stats.gather_table_stats('SIRS_UATC1', 'TBL_RECON_PM'); .

Se isso não melhorar a estimativa de cardinalidade, tente usar uma dica de amostragem dinâmica, como /*+ dynamic_sampling(5) */ . Para uma consulta de execução tão longa, vale a pena gastar um pouco de tempo extra antecipando dados de amostragem se isso levar a um plano melhor.

Use paralelismo em nível de instrução em vez de paralelismo em nível de objeto. Este é provavelmente o erro mais comum com SQL paralelo. Se você usar paralelismo em nível de objeto, a dica deve fazer referência ao alias do objeto. Desde 11gR2 não há necessidade de se preocupar em especificar objetos. Esta instrução precisa apenas de uma única dica:INSERT /*+ PARALLEL(16) APPEND */ ... . Observe que NOLOGGING não é uma dica real.