Förbättra statistiken. Det uppskattade antalet rader är 1, men det faktiska antalet rader är över 7 miljoner och räknas. Detta gör att exekveringsplanen använder en kapslad loop istället för en hash-join. En kapslad loop fungerar bättre för små mängder data och en hash-join fungerar bättre för stora datamängder. Det kan vara lika enkelt att fixa som att se till att de relevanta tabellerna har korrekt, aktuell statistik. Detta kan vanligtvis göras genom att samla in statistik med standardinställningarna, till exempel:exec dbms_stats.gather_table_stats('SIRS_UATC1', 'TBL_RECON_PM'); .
Om det inte förbättrar kardinalitetsuppskattningen, försök använda ett dynamiskt samplingstips, såsom /*+ dynamic_sampling(5) */ . För en så långvarig fråga är det värt att lägga lite extra tid på att sampla data i förväg om det leder till en bättre plan.
Använd parallellism på uttalandenivå istället för parallellism på objektnivå. Detta är förmodligen det vanligaste misstaget med parallell SQL. Om du använder parallellism på objektnivå måste tipset referera till aliaset av objektet. Eftersom 11gR2 behöver du inte oroa dig för att specificera objekt. Denna sats behöver bara en enda ledtråd:INSERT /*+ PARALLEL(16) APPEND */ ... . Observera att NOLOGGING är inte en riktig ledtråd.