Questa è una delle domande più comuni poste sull'Utilità di pianificazione. Di seguito elenchiamo alcuni dei problemi più comuni e le relative soluzioni.
1) job_queue_processes potrebbe essere troppo basso (questo è il problema più comune) Il valore di job_queue_processes limita il numero totale di job dbms_scheduler e dbms_job che possono essere eseguiti in un dato momento. select value from v$parameter where name='job_queue_processes';Quindi controlla il numero di job in esecuzioneSQL> select count() da dba_scheduler_running_jobs;SQL> select count( ) da dba_jobs_running;
Se questo è il problema puoi aumentare il parametro usandoSQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes potrebbe essere troppo basso Se questo parametro non è NULL, limita il numero di lavori dbms_scheduler che possono essere eseguiti alla volta. Per verificare se questo è il problema, controlla il valore corrente usandoSQL> seleziona il valore da dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES';Quindi controlla il numero di lavori in esecuzioneSQL> seleziona count(*) da dba_scheduler_running_jobs;
Se questo è il problema puoi aumentare il numero o semplicemente annullarlo usandoSQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) le sessioni potrebbero essere troppo basseQuesto parametro limita il numero di sessioni in qualsiasi momento. Ogni lavoro di pianificazione richiede 2 sessioni. Per verificare se questo è il problema, controlla il valore corrente usando SQL> seleziona il valore da v$parameter dove name='sessions'; Quindi controlla il numero corrente di sessioni usando SQL> seleziona count(*) da v$session;
Se i numeri sono troppo vicini puoi aumentare il massimo usandoSQL> alter system set job_queue_processes=200;
4) Hai recentemente applicato una patch di aggiornamento del fuso orario o aggiornato il database a una versione con informazioni sul fuso orario più recenti? Se hai saltato dei passaggi durante l'aggiornamento delle informazioni sul fuso orario, i lavori potrebbero non essere eseguiti. Per verificare se questo è il caso, prova a fareSQL> seleziona * da sys.scheduler$_job;eSQL> seleziona * da sys.scheduler$_window;e assicurati che finiscano senza errori.
Se genera un avviso di fuso orario, riapplica l'aggiornamento o la patch del fuso orario assicurandoti di seguire tutti i passaggi.
5) Il database è in esecuzione in modalità con restrizioni? Se il database è in esecuzione in modalità con restrizioni, non verrà eseguito alcun lavoro (a meno che tu non stia utilizzando 11g e utilizzi l'attributo ALLOW_RUNS_IN_RESTRICTED_MODE).>
Se gli accessi sono limitati, puoi disabilitare la modalità con restrizioni utilizzandoSQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) Il lavoro è pianificato per l'esecuzione su un'istanza inattiva?
Puoi verificarlo vedendo se instance_id è impostato per il lavoro (controlla la vista dba_scheduler_jobs) e, in tal caso, dovresti controllare se quell'istanza è attiva.
7) Il lavoro è pianificato per l'esecuzione su un servizio che non è stato avviato in nessuna istanza?
Puoi verificarlo controllando a quale job_class punta un lavoro e quindi controllando se quella classe punta a un servizio. In tal caso, assicurati che il servizio sia stato avviato su almeno un'istanza in esecuzione. Puoi avviare un servizio su un'istanza utilizzando dbms_service.start_service.
8) Il Resource Manager è in vigore con un piano di risorse restrittivo?
Se è in vigore un piano per le risorse restrittivo, i lavori di pianificazione potrebbero non disporre di risorse sufficienti allocate, pertanto potrebbero non essere eseguiti. Puoi controllare quale piano per le risorse è in vigore facendo
SQL> seleziona il nome da V$RSRC_PLAN;
Se nessun piano è in vigore o il piano in vigore è INTERNAL_PLAN, il gestore risorse non è attivo. Se il gestore risorse è attivo puoi disabilitarlo facendo
SQL>alter system set resource_manager_plan ='';
9) Lo Scheduler è stato disabilitato? Questa non è un'azione supportata, ma è possibile che qualcuno l'abbia fatta comunque. Per controllare questo doSQL> seleziona il valore da dba_scheduler_global_attribute dove attribute_name='SCHEDULER_DISABLED'
Se questa query restituisce TRUE, puoi risolverlo utilizzandoSQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Motivi per cui i lavori potrebbero essere eseguiti in ritardo
1) La prima cosa da controllare è il fuso orario in cui il lavoro è pianificato conSQL> seleziona proprietario, nome_lavoro, data_esecuzione_prossima da dba_scheduler_jobs;
Se i lavori si trovano nel fuso orario sbagliato, potrebbero non essere eseguiti all'ora prevista. Se next_run_date utilizza un fuso orario assoluto (come +08:00) invece di un fuso orario con nome (come USA/PACIFICO), i lavori potrebbero non essere eseguiti come previsto se è in vigore l'ora legale:potrebbero essere eseguiti un'ora prima o in ritardo.
2) È possibile che al momento dell'esecuzione programmata del lavoro, sia stato temporaneamente raggiunto uno dei vari limiti sopra indicati causando un ritardo del lavoro. Verificare se i limiti sopra indicati sono sufficientemente elevati e, se possibile, verificarli durante il tempo in cui il il lavoro è in ritardo.
3) Una possibile ragione per cui uno dei limiti di cui sopra potrebbe essere raggiunto è che la finestra di manutenzione potrebbe essere entrata in vigore. Le finestre di manutenzione sono finestre OracleScheduler che appartengono al gruppo di finestre denominatoMAINTENANCE_WINDOW_GROUP. Durante una finestra di manutenzione programmata, diverse attività di manutenzione vengono eseguite utilizzando i lavori. Ciò potrebbe causare il raggiungimento di uno dei limiti sopra elencati e il ritardo dei lavori degli utenti. Consulta la guida dell'amministratore per ulteriori informazioni su questo (capitolo 24).
Per ottenere un elenco delle finestre di manutenzione, usa SQL> seleziona * da dba_scheduler_wingroup_members;
Per vedere quando le finestre vengono eseguite usaSQL> seleziona * da dba_scheduler_windows;
Per risolvere questo problema puoi aumentare i limiti o riprogrammare le finestre di manutenzione in modo che vengano eseguite in orari più convenienti.
Diagnosi di altri problemi
Se nulla di tutto ciò funziona, ecco alcuni ulteriori passaggi che puoi eseguire per cercare di capire cosa sta succedendo.
1) Verificare se ci sono errori nel registro degli avvisi. Se il database ha problemi nell'allocazione della memoria o ha esaurito lo spazio su disco o si sono verificati altri errori catastrofici, è necessario risolverli prima. Puoi trovare la posizione del registro degli avvisi utilizzandoSQL> seleziona il valore da v$parameter dove nome ='background_dump_dest';Il registro degli avvisi sarà in questa directory con un nome che inizia con "alert".
2) Verificare se un file di traccia del coordinatore del lavoro e se lo fa, verificare se contiene errori. Se esiste, si troverà nella directory 'background_dump_dest' che puoi trovare come sopra e assomiglierà a SID-cjq0_nnnn.trc . Se ci sono errori qui, potrebbero suggerire perché i lavori non sono in esecuzione.
3) Se uno dei precedenti indica che lo spazio tabella SYSAUX (in cui lo scheduler memorizza le sue tabelle di registrazione) è pieno, è possibile utilizzare la procedura dbms_scheduler.purge_log per cancellare le vecchie voci di registro.
4) Verifica se c'è una finestra attualmente aperta. Se c'è, puoi provare a chiuderlo per vedere se questo aiuta .
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5) prova a eseguire un semplice lavoro eseguito una sola volta e verifica se viene eseguito
SQL>begin
dbms_scheduler.create_job (
job_name => 'test_job',
job_type => 'plsql_block',
job_action => 'null;',
enabled => true);
end;
/
SQL> -- wait a while
SQL> select * from user_scheduler_job_run_details where job_name='TEST_JOB';
6) Se un semplice lavoro eseguito una sola volta non viene eseguito, puoi provare a riavviare lo scheduler come segue.
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'TRUE');
SQL> alter system set job_queue_processes=0;
SQL> exec dbms_ijob.set_enabled(FALSE);
SQL>
SQL> alter system flush shared_pool;
SQL> alter system flush shared_pool;
SQL>
SQL> exec dbms_ijob.set_enabled(TRUE);
SQL> alter system set job_queue_processes=99;
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');
