El enfoque más simple posible sería tomar el l_job parámetros de salida de dbms_job.submit y luego escribe un ciclo que verifique cuántos de esos job los valores están en dba_jobs , sale cuando el recuento es 0 y, de lo contrario, entra en suspensión a través de una llamada a dbms_lock.sleep por un período de tiempo razonable. Obviamente, debe evitar sobrescribir el l_job actual variable para capturar los cinco puestos de trabajo. Algo como
CREATE TYPE num_tbl
AS TABLE OF NUMBER;
PROCEDURE refresh_all_MViews AS
l_job BINARY_INTEGER;
l_jobs num_tbl;
BEGIN
l_jobs.extend(5);
dbms_job.submit (l_job, ...) ;
l_jobs(1) := l_job;
dbms_job.submit (l_job, ...) ;
l_jobs(2) := l_job;
dbms_job.submit (l_job, ...) ;
l_jobs(3) := l_job;
dbms_job.submit (l_job, ...) ;
l_jobs(4) := l_job;
dbms_job.submit (l_job, ...) ;
l_jobs(5) := l_job;
loop
select count(*)
into l_cnt
from dba_jobs
where job in (select column_value from table(l_jobs));
if( l_cnt = 0 )
then
exit;
end if;
dbms_lock.sleep( 10 ); -- Sleep for 10 seconds
end loop;
refresh_Dependent_MViews;
END refresh_all_MViews;
Ahora, obviamente podrías modificar el refresh_Independent_MViews procedimiento para devolver la colección de números de trabajo que necesitan ser monitoreados para que refresh_all_mviews el procedimiento llama a refresh_independent_mviews , implementa el ciclo y luego llama a refresh_dependent_mviews .
Puede volverse más sofisticado haciendo que sus trabajos escriban en una tabla que registre el éxito o el fracaso o enviando un mensaje a través de Oracle AQ que otro proceso escuche para iniciar la actualización de mview dependiente. Probablemente no sea necesario en este caso, pero podría serlo si sus dependencias se vuelven más sofisticadas. Sin duda, también podrías crear un dbms_scheduler cadena que haría esto por ti.
