Cursor anidado en un cursor

Normalmente, simplemente unirías las dos mesas.

FOR some_cursor IN (SELECT s.col1,
                           s.col2
                      FROM sometable s
                           JOIN temp_table t ON (s.col3 = t.col1))
LOOP
  <<do something>>
END LOOP

Sin embargo, dado que le preocupa la eficiencia

• Es TEMP_TABLE realmente una tabla temporal? Si es así, ¿por qué? Es extremadamente raro que Oracle realmente necesite usar tablas temporales, por lo que me lleva a sospechar que probablemente esté haciendo algo ineficiente para llenar la tabla temporal en primer lugar.
• ¿Por qué tienes un cursor FOR? bucle para procesar los datos de TEMP_TABLE ? El procesamiento fila por fila es la forma más lenta de hacer cualquier cosa en PL/SQL, por lo que generalmente se evitaría si le preocupa la eficiencia. Desde el punto de vista del rendimiento, desea maximizar SQL para que, en lugar de hacer un bucle que haga una serie de INSERT de una sola fila o UPDATE operaciones, haría un solo INSERT o UPDATE que modificó un conjunto completo de filas. Si realmente necesita procesar datos en fragmentos, ahí es donde entrarían en juego las recopilaciones PL/SQL y el procesamiento masivo, pero eso no será tan eficiente como SQL directo.
• ¿Por qué tienes el DISTINCT? en su consulta contra TEMP_TABLE ? ¿Realmente esperas que haya big_id duplicados? valores que no son erróneos? La mayoría de las veces, la gente usa DISTINCT incorrectamente, ya sea para encubrir problemas en los que los datos se han unido incorrectamente o en los que está obligando a Oracle a realizar una ordenación costosa en caso de que se creen datos incorrectos en el futuro cuando una restricción sería la forma más adecuada de protegerse.