Oracle DBMS Job не се изпълнява

Това е един от най-често задаваните въпроси за Scheduler. Тук изброяваме някои от често срещаните проблеми и техните решения.

1) job_queue_processes може да е твърде малък (това е най-често срещаният проблем) Стойността на job_queue_processes ограничава общия брой на dbms_scheduler и dbms_job задания, които могат да се изпълняват в даден момент. За да проверите дали това е така, проверете текущата стойност наjob_queue_processes със SQL> изберете стойност от v$parameter where name='job_queue_processes';След това проверете броя на изпълняваните заданияSQL> изберете count() от dba_scheduler_running_jobs;SQL> изберете count( ) от dba_jobs_running;

Ако това е проблемът, можете да увеличите параметъра с помощта на SQL> alter system set job_queue_processes=1000;

2) max_job_slave_processes може да е твърде ниско. Ако този параметър не е NULL, тогава той ограничава колко задания на dbms_scheduler могат да се изпълняват наведнъж. За да проверите дали това е проблемът, проверете текущата стойност с помощта на SQL> изберете стойност от dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES'; След това проверете броя на изпълняваните задачиSQL> изберете count(*) от dba_scheduler_running_jobs;

Ако това е проблемът, можете да увеличите броя или просто да го NULL използвате SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)

3) сесиите може да са твърде ниски Този параметър ограничава броя на сесиите по всяко време. Всяка задача на Scheduler изисква 2 сесии. За да проверите дали това е проблемът, проверете текущата стойност с помощта на SQL> изберете стойност от v$parameter where name='sessions'; След това проверете текущия брой сесии с помощта на SQL> изберете броя(*) от v$session;

Ако числата са твърде близки, можете да увеличите максимума с помощта на SQL> alter system set job_queue_processes=200;

4) Приложили ли сте наскоро корекция за актуализиране на часовата зона или сте надстроили базата данни до версия с по-нова информация за часовата зона? Ако сте пропуснали стъпки при актуализиране на информацията за часовата зона, заданията може да не се изпълняват. За да проверите дали случаят е такъв, опитайте да направите SQL> изберете * от sys.scheduler$_job; и SQL> изберете * от sys.scheduler$_window; и се уверете, че завършват без грешки.

Ако изведе предупреждение за часова зона, приложете отново надстройката или корекцията за часова зона, като се уверите, че следвате всички стъпки.

5) Базата данни работи ли в ограничен режим? Ако базата данни работи в ограничен режим, тогава няма да се изпълняват задачи (освен ако не използвате 11g и използвате атрибута ALLOW_RUNS_IN_RESTRICTED_MODE). За да проверите това, използвайте SQL> изберете влизания от v$instance;

Ако влизането е ограничено, можете да деактивирате ограничения режим с помощта на SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

6) Планирано ли е заданието да се изпълнява на екземпляр, който не работи?

Можете да проверите това, като видите дали instance_id е зададено за заданието (проверете изгледа dba_scheduler_jobs) и ако е така, трябва да проверите дали този екземпляр е активен.

7) Заданието планирано ли е да се изпълнява на услуга, която не е стартирана на никакви екземпляри?

Можете да проверите това, като проверите към какво job_class сочи дадено задание и след това проверите дали този клас сочи към услуга. Ако го направи, уверете се, че услугата е стартирана на поне един работещ екземпляр. Можете да стартирате услуга на екземпляр, като използвате dbms_service.start_service.

8) Диспечерът на ресурси действа ли с ограничителен план за ресурси?

Ако е в сила ограничителен план за ресурси, заданията на планировчика може да нямат достатъчно разпределени ресурси, така че може да не се изпълняват. Можете да проверите какъв план за ресурси е в сила, като направите

SQL> изберете име от V$RSRC_PLAN;

Ако няма действащ план или действащият план е INTERNAL_PLAN, тогава мениджърът на ресурси не е в сила. Ако мениджърът на ресурсите е активен, можете да го деактивирате, като направите

SQL>промяна на системния набор resource_manager_plan ='';

9) Деактивиран ли е Scheduler? Това не е поддържано действие, но все пак е възможно някой да го е направил. За да проверите този doSQL> изберете стойност от dba_scheduler_global_attribute, където attribute_name='SCHEDULER_DISABLED'

Ако тази заявка върне TRUE, тогава можете да коригирате това с помощта на SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');

Причини, поради които заданията могат да се изпълняват със закъснение

1) Първото нещо, което трябва да проверите, е часовата зона, в която заданието е планирано със SQL> изберете собственик, име на задание, дата на следващо изпълнение от dba_scheduler_jobs;

Ако задачите са в грешна часова зона, те може да не се изпълняват в очакваното време. Ако next_run_date използва абсолютно отместване на часовата зона (като +08:00) вместо назована часова зона (като US/PACIFIC), тогава задачите може да не се изпълняват според очакванията, ако лятното часово време е в сила - те може да се изпълняват с час по-рано или късно.

2) Може да се окаже, че по времето, когато заданието е планирано да се изпълни, едно от няколкото ограничения по-горе може да е било временно достигнато, причинявайки забавяне на заданието. Проверете дали ограниченията по-горе са достатъчно високи и ако е възможно, проверете ги през времето, през което задачата се забавя.

3) Една възможна причина, поради която едно от горните ограничения може да бъде достигнато, е, че прозорецът за поддръжка може да е влязъл в сила. Прозорците за поддръжка са прозорци на OracleScheduler, които принадлежат към групата прозорци, наречена MAINTENANCE_WINDOW_GROUP. По време на прозорец за планирана поддръжка няколко задачи за поддръжка се изпълняват с помощта на задания. Това може да доведе до достигане на едно от ограниченията, изброени по-горе, и забавяне на потребителски задачи. Вижте ръководството на администратора за повече информация относно това (глава 24).

За да получите списък с прозорци за поддръжка, използвайте SQL> изберете * от dba_scheduler_wingroup_members;

За да видите кога прозорците се изпълняват, използвайте SQL> изберете * от dba_scheduler_windows;

За да коригирате това, можете или да увеличите лимитите, или да пренасрочите прозорците за поддръжка, за да се изпълняват в по-удобни моменти.

Диагностициране на други проблеми

Ако нищо от това не работи, ето някои допълнителни стъпки, които можете да предприемете, за да се опитате да разберете какво се случва.

1) Проверете дали има грешки в регистъра на предупрежденията. Ако базата данни има проблеми с разпределянето на памет или е свършило дисковото пространство или са възникнали други катастрофални грешки, първо трябва да ги разрешите. Можете да намерите местоположението на регистрационния файл с предупреждения, като използвате SQL> изберете стойност от v$parameter where name ='background_dump_dest';Регистрационният файл с предупреждения ще бъде в тази директория с име, започващо с "alert".

2) Проверете дали има файл за проследяване на координатор на задания и ако има, проверете дали съдържа грешки. Ако това съществува, то ще се намира в директорията 'background_dump_dest', която можете да намерите както по-горе, и ще изглежда нещо като SID-cjq0_nnnn.trc. Ако има някакви грешки тук, те може да подскажат защо заданията не се изпълняват.

3) Ако някое от горните показва, че пространството за таблици SYSAUX (където планировчикът съхранява своите регистриращи таблици) е пълно, можете да използвате процедурата dbms_scheduler.purge_log, за да изчистите старите записи в журнала.

4) Вижте дали в момента има отворен прозорец. Ако има, можете да опитате да го затворите, за да видите дали това помага.

SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where 
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');

5)опитайте да изпълните просто еднократно изпълнение и вижте дали работи

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) Ако проста задача за еднократно изпълнение не се изпълнява, можете да опитате да рестартирате планировчика по следния начин.

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');