L'approche la plus simple possible serait de prendre le l_job paramètres de sortie de dbms_job.submit puis écrivez une boucle qui vérifie combien de ces job les valeurs sont dans dba_jobs , se termine lorsque le compte est 0, et sinon se met en veille via un appel à dbms_lock.sleep pendant une durée raisonnable. Évidemment, vous devez éviter d'écraser le l_job actuel variable afin de saisir les cinq emplois. Quelque chose comme
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;
Maintenant, vous pouvez évidemment modifier le refresh_Independent_MViews procédure pour renvoyer la collection de numéros de travail qui doivent être surveillés afin que le refresh_all_mviews appels de procédure refresh_independent_mviews , implémente la boucle, puis appelle refresh_dependent_mviews .
Vous pouvez devenir plus sophistiqué en faisant écrire vos tâches dans une table qui enregistre le succès ou l'échec ou en envoyant un message via Oracle AQ qu'un autre processus écoute afin de lancer l'actualisation dépendante de mview. Ce n'est probablement pas nécessaire dans ce cas, mais cela pourrait l'être si vos dépendances deviennent plus sophistiquées. Sans aucun doute, vous pouvez également créer un dbms_scheduler chaîne qui le ferait pour vous.
