Toto je jedna z nejčastějších otázek Plánovače. Zde uvádíme některé běžné problémy a jejich řešení.
1) job_queue_processes může být příliš nízké (toto je nejběžnější problém)Hodnota job_queue_processes omezuje celkový počet úloh dbms_scheduleand dbms_job, které mohou být spuštěny v danou dobu. Chcete-li zkontrolovat, zda se jedná o tento případ, zkontrolujte aktuální hodnotu job_queue_processes pomocí SQL> select value from v$parameter where name='job_queue_processes';Poté zkontrolujte počet spuštěných úlohSQL> select count() z dba_scheduler_running_jobs;SQL> select count( ) z dba_jobs_running;
Pokud je to problém, můžete zvýšit parametr pomocí SQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes může být příliš nízký. Pokud tento parametr není NULL, pak omezuje, kolik úloh dbms_scheduler může být spuštěno současně. Chcete-li zkontrolovat, zda se jedná o problém, zkontrolujte aktuální hodnotu pomocí SQL> vyberte hodnotu z dba_scheduler_global_attributewhere název_atributu='MAX_JOB_SLAVE_PROCESSES';Poté zkontrolujte počet spuštěných úlohSQL> vyberte počet(*) z dba_scheduler_running_jobs;
Pokud je toto problém, můžete číslo zvýšit nebo jej jednoduše vynulovat pomocí SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) relace mohou být příliš nízkéTento parametr omezuje počet relací kdykoli. Každá úloha Plánovače vyžaduje 2 sezení. Chcete-li zkontrolovat, zda se jedná o tento problém, zkontrolujte aktuální hodnotu pomocí SQL> vyberte hodnotu z v$parametr kde name='sessions';Poté zkontrolujte aktuální počet relací pomocí SQL> vyberte počet(*) z v$session;
Pokud jsou čísla příliš blízko, můžete zvýšit maximum pomocí SQL> alter system set job_queue_processes=200;
4) Aplikovali jste nedávno opravu aktualizace časového pásma nebo upgradovali databázi na verzi s novějšími informacemi o časovém pásmu? Pokud jste při aktualizaci informací o časovém pásmu přeskočili některé kroky, úlohy se nemusí spustit. Chcete-li zkontrolovat, zda se jedná o tento případ, zkuste provést SQL> vyberte * ze sys.scheduler$_job;andSQL> vyberte * ze sys.scheduler$_window;a ujistěte se, že skončí bez chyb.
Pokud zobrazí varování o časovém pásmu, znovu použijte upgrade nebo opravu časového pásma a ujistěte se, že dodržujete všechny kroky.
5) Běží databáze v omezeném režimu? Pokud databáze běží v omezeném režimu, nepoběží žádné úlohy (pokud nepoužíváte 11g a nepoužíváte atribut ALLOW_RUNS_IN_RESTRICTED_MODE). Chcete-li to zkontrolovat, použijte SQL> vyberte přihlášení z v$instance;
Pokud je přihlášení omezeno, můžete omezený režim deaktivovat pomocí SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) Je naplánováno spuštění úlohy na instanci, která je mimo provoz?
Můžete to zkontrolovat tak, že se podíváte, zda je instance_id nastaveno pro úlohu (podívejte se na zobrazení dba_scheduler_jobs), a pokud ano, měli byste zkontrolovat, zda je tato instance aktivní.
7) Je naplánováno spuštění úlohy na službě, která nebyla spuštěna v žádné instanci?
Můžete to zkontrolovat tak, že zkontrolujete, na jakou třídu_práce ukazuje úloha, a poté zkontrolujete, zda tato třída ukazuje na službu. Pokud ano, ujistěte se, že služba byla spuštěna alespoň na jedné spuštěné instanci. Službu můžete spustit na instanci pomocí dbms_service.start_service.
8) Funguje Správce zdrojů s omezujícím plánem zdrojů?
Pokud je v platnosti omezující plán zdrojů, úlohy plánovače nemusí mít přidělené dostatečné zdroje, takže se nemusí spustit. Můžete zkontrolovat, jaký plán zdrojů je platný, provedením
SQL> vyberte název z V$RSRC_PLAN;
Pokud není platný žádný plán nebo je platný plán INTERNAL_PLAN, pak správce zdrojů není účinný. Pokud je správce zdrojů aktivní, můžete jej deaktivovat provedením
SQL>změnit systémovou sadu resource_manager_plan ='';
9) Byl plánovač deaktivován? Toto není podporovaná akce, ale je možné, že to někdo přesto provedl. Chcete-li zkontrolovat tento doSQL>, vyberte hodnotu z atributu dba_scheduler_global_attribute, kde název_atributu='SCHEDULER_DISABLED'
Pokud tento dotaz vrátí hodnotu PRAVDA, můžete to opravit pomocí SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Důvody, proč se úlohy mohou zpozdit
1) První věc, kterou je třeba zkontrolovat, je časové pásmo, ve kterém je úloha naplánována pomocí SQL> vyberte vlastníka, název_úlohy, datum příštího_spuštění z dba_scheduler_jobs;
Pokud jsou úlohy ve špatném časovém pásmu, nemusí se spustit v očekávanou dobu. Pokud next_run_date používá absolutní posun časového pásma (např. +08:00) místo pojmenovaného časového pásma (např. US/PACIFIC), pak se úlohy nemusí spustit podle očekávání, pokud je v platnosti letní čas – mohou se spustit o hodinu nebo později.
2) Může se stát, že v době, kdy bylo naplánováno spuštění úlohy, mohlo být dočasně dosaženo jednoho z několika výše uvedených limitů, což způsobilo zpoždění úlohy. Zkontrolujte, zda jsou výše uvedené limity dostatečně vysoké, a pokud je to možné, zkontrolujte je během doby, kdy úloha se odkládá.
3) Jedním z možných důvodů, proč může být dosaženo jednoho z výše uvedených limitů, je, že mohlo vstoupit v platnost okno údržby. Okna údržby jsou okna OracleScheduler, která patří do skupiny oken s názvemMAINTENANCE_WINDOW_GROUP. Během plánovaného okna údržby se pomocí úloh spustí několik úloh údržby. To může způsobit naplnění jednoho z výše uvedených limitů a zpoždění uživatelských úloh. Další informace o tom naleznete v průvodci správce (kapitola 24).
Chcete-li získat seznam oken údržby, použijte SQL> vyberte * z dba_scheduler_wingroup_members;
Chcete-li zjistit, kdy se okna spouštějí, použijte SQL> vyberte * z dba_scheduler_windows;
Chcete-li tento problém vyřešit, můžete buď zvýšit limity, nebo přeplánovat okna údržby tak, aby se spouštěly ve vhodnější časy.
Diagnostika dalších problémů
Pokud nic z toho nefunguje, zde je několik dalších kroků, které můžete podniknout, abyste se pokusili zjistit, co se děje.
1) Zkontrolujte, zda v protokolu výstrah nejsou nějaké chyby. Pokud má databáze potíže s alokací paměti nebo má nedostatek místa na disku nebo došlo k jiným katastrofickým chybám, měli byste je nejprve vyřešit. Umístění protokolu výstrah můžete najít pomocí SQL> vyberte hodnotu z parametru v$ kde název ='background_dump_dest'; Protokol výstrah bude v tomto adresáři s názvem začínajícím na „alert“.
2) Zkontrolujte, zda soubor trasování koordinátora úloh sleduje, a pokud ano, zkontrolujte, zda neobsahuje nějaké chyby. Pokud existuje, bude umístěn v adresáři 'background_dump_dest', který najdete výše, a bude vypadat nějak jako SID-cjq0_nnnn.trc . Pokud se zde vyskytnou nějaké chyby, mohou naznačit, proč úlohy neběží.
3) Pokud některý z výše uvedených případů naznačuje, že tabulkový prostor SYSAUX (kde plánovač ukládá své protokolovací tabulky) je plný, můžete pomocí procedury dbms_scheduler.purge_log vymazat staré položky protokolu.
4) Podívejte se, zda je aktuálně otevřené okno. Pokud existuje, můžete jej zkusit zavřít a zjistit, zda to pomůže.
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5)zkuste spustit jednoduchou úlohu spustit jednou a zjistěte, zda běží
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) Pokud se jednoduchá úloha spustit jednou nespustí, můžete zkusit restartovat plánovač následovně.
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');