Améliorez les statistiques. Le nombre estimé de lignes est de 1, mais le nombre réel de lignes est supérieur à 7 millions et continue. Ainsi, le plan d'exécution utilise une boucle imbriquée au lieu d'une jointure par hachage. Une boucle imbriquée fonctionne mieux pour de petites quantités de données et une jointure par hachage fonctionne mieux pour de grandes quantités de données. Pour résoudre ce problème, il suffit de s'assurer que les tableaux pertinents contiennent des statistiques exactes et à jour. Cela peut généralement être fait en collectant des statistiques avec les paramètres par défaut, par exemple :exec dbms_stats.gather_table_stats('SIRS_UATC1', 'TBL_RECON_PM'); .
Si cela n'améliore pas l'estimation de la cardinalité, essayez d'utiliser un indice d'échantillonnage dynamique, tel que /*+ dynamic_sampling(5) */ . Pour une requête aussi longue, il vaut la peine de consacrer un peu plus de temps à l'échantillonnage initial des données si cela conduit à un meilleur plan.
Utilisez le parallélisme au niveau des instructions au lieu du parallélisme au niveau des objets. C'est probablement l'erreur la plus courante avec le SQL parallèle. Si vous utilisez le parallélisme au niveau de l'objet, l'indice doit faire référence à l'alias de l'objet. Depuis 11gR2, il n'y a plus besoin de se soucier de la spécification des objets. Cette instruction n'a besoin que d'un seul indice :INSERT /*+ PARALLEL(16) APPEND */ ... . Notez que NOLOGGING n'est pas un vrai indice.
