Oracle не запускаются джобы
При выполнении команды lsnrctl status я получаю следующие ошибки:
Он работал нормально до перезапуска, но теперь он не работает, и я также не могу получить доступ к своей домашней странице Oracle.
Мой listener.ora : (Здесь была ошибка из-за неуместных скобок, добавление нескольких пробелов решило проблему TNS-12518)
Ниже приводится вывод команды lsnrctl start .
Ниже приводится последняя необходимая запись из файла журнала.
Пытался разрешить TNS-12518, и слушатель запущен, но все еще не может получить доступ к домашней странице Oracle
Вывод lnsrctl stat
Команда успешно завершена
1. Проверьте переменные среды (должны быть установлены для System , а не для пользователя):
2. Проверьте правильность определения в listener.ora
3. перезапустите службу (Services> OracleServiceXE)
После этого вы можете увидеть новую службу OracleXETNSListenerXE.
Уже есть старый OracleXETNSListener.
Я запустил оба, а затем смог установить успешное соединение.
Если все работает, но вы по-прежнему не можете подключиться, проверьте, нет ли ошибки: ORA-12557: TNS: адаптер протокола не загружается .
У меня такая же проблема. Решение в моем случае: запустить CMD от имени АДМИНИСТРАТОРА. затем введите и выполните: "lsnrctl start" подождите около 2 минут, после чего все должно работать. (в моем случае было всего 50 секунд, но на всякий случай)
Я решил это, обновив файл listener.ora внутри каталога oracle oraclexe \ app \ oracle \ product \ 11.2.0 \ server \ network \ ADMIN.
Это случилось со мной из-за того, что я изменил имя своей системы, но внутри listener.ora было старое имя для HOST.
Это может быть одной из причин . для тех, кто все еще сталкивается с такой проблемой, тоже могут подумать об этой возможности.
Убедитесь, что переменная среды ORACLE_HOME указывает на правильный дом оракула. В моем случае это было изменено другой установкой программного обеспечения.
У меня возникла аналогичная проблема при установке oracle 11gR2 на сервер Windows 2012. проблема решается, когда я запускаю cmd.exe с правами администратора и запускаю «lsnrctl start LISTENER».
Я столкнулся с той же проблемой и причиной: у меня персональный ПК с Windows. И я изменил имя компьютера, и это не отразилось на listener.ora. Обновление ORACLE_HOME \ network \ ADMIN \ listener.ora с обновленным именем хоста устранило проблему.
В моем случае я попытался запустить слушатель через консоль:
Эта команда напечатала следующую ошибку:
Итак, я выполнил следующие действия:
- Проверьте, содержит ли файл Oracle listener.ora или sqlnet.ora специальные символы
- Проверьте, не имеет ли файл Oracle listener.ora или sqlnet.ora` неправильный формат или синтаксис
- Проверьте, есть ли в файле Oracle listener.ora или sqlnet.ora какие-нибудь выровненные по левому краю круглые скобки, которые не принимаются парсером Oracle.
Взгляните на эти файлы и проверьте правильный синтаксис. Если возможно, удалите / переименуйте sqlnet.ora и попробуйте перезапустить слушатель. Или удалите / переименуйте файл listener.ora или sqlnet.ora и заново создайте его должным образом. Это определенно решит проблему.
В моем случае каким-то образом служба слушателя Windows перестала работать, поэтому я не смог подключиться к Qracle с помощью SQL Developer. Однако мне удалось подключиться через sqlplus .
Ниже решение работало для меня:
Во-первых, убедитесь, что ваша служба прослушивателя запущена.
Если служба прослушивателя не запущена, перезапустите службу прослушивателя с помощью диспетчера задач Windows или используйте служебную программу командной строки DOS, чтобы перезапустить службу Windows с помощью команды net start :
Попробуйте запустить службу прослушивания, используя lsnrctl из командной строки DOS.
Мне удалось решить проблему, из-за которой произошел сбой конфигурации в контейнере докеров, на котором запущена песочница Hortonworks HDP 2.6.
Если первоначальная конфигурация не удалась, слушатель будет запущен, и его сначала нужно будет убить:
Следующим шагом будет решение проблемы с общей памятью, которая приводит к сбою процесса настройки.
Изменить / добавить строку в:
Затем перезагрузите конфигурацию:
Имейте в виду, что в следующий раз, когда вы перезапустите контейнер докеров, вам, возможно, придется выполнить команду «mount -a».
В моем случае служба прослушивателя не запускалась, потому что она была настроена на прослушивание VPN-соединения, а также других серверных интерфейсов.
Как только я подключился к VPN, он просто запустился.
Однако трюк @ Imre с "lsnrctl start" направил меня на верный путь.
Служба прослушивателя остановлена в services.msc .
Пароль пользователя был изменен.
В моем случае с Windows прослушиватель не запускался, и lsnrctl start зависал навсегда. Решением было убить все процессы extproc. Я подозреваю, что это было забавно связано с моим vpn
The DBMS_JOB package schedules and manages jobs in the job queue.
The DBMS_JOB package has been superseded by the DBMS_SCHEDULER package. In particular, if you are administering jobs to manage system load, you should consider disabling DBMS_JOB by revoking the package execution privilege for users.
This chapter contains the following topics:
Summary of DBMS_JOB Subprograms
Disables job execution
Alters any of the user-definable parameters associated with a job
Assigns a job to be run by a instance
Alters the interval between executions for a specified job
Alters the next execution time for a specified job
Removes specified job from the job queue
Forces a specified job to run
Submits a new job to the job queue
Re-creates a given job for export, or re-creates a given job for export with instance affinity
Alters the job description for a specified job
CHANGE Procedure
This procedure changes any of the fields a user can set in a job.
Number of the job being run.
PL/SQL procedure to run.
Date of the next refresh.
Date function; evaluated immediately before the job starts running.
When a job is submitted, specifies which instance can run the job. This defaults to NULL , which indicates that instance affinity is not changed.
If this is FALSE , then the specified instance (to which the instance number change) must be running. Otherwise, the routine raises an exception.
If this is TRUE , then any positive integer is acceptable as the job instance.
You must issue a COMMIT statement immediately after the statement.
The parameters instance and force are added for job queue affinity. Job queue affinity gives users the ability to indicate whether a particular instance or any instance can run a submitted job.
If the parameters what , next_date , or interval are NULL , then leave that value as it is.
BROKEN Procedure
This procedure sets the broken flag. Broken jobs are never run.
Number of the job being run.
Job broken: IN value is FALSE .
Date of the next refresh.
If you set job as broken while it is running, Oracle resets the job's status to normal after the job completes. Therefore, only execute this procedure for jobs that are not running.
You must issue a COMMIT statement immediately after the statement.
I NSTANCE Procedure
This procedure changes job instance affinity.
Number of the job being run.
When a job is submitted, a user can specify which instance can run the job.
If this is TRUE , then any positive integer is acceptable as the job instance. If this is FALSE (the default), then the specified instance must be running; otherwise the routine raises an exception.
You must issue a COMMIT statement immediately after the statement.
SUBMIT Procedure
This procedure submits a new job. It chooses the job from the sequence sys . jobseq .
Number of the job being run.
PL/SQL procedure to run.
Next date when the job will be run.
Date function that calculates the next time to run the job. The default is NULL . This must evaluate to a either a future point in time or NULL .
A flag. The default is FALSE . If this is set to FALSE , then Oracle parses the procedure associated with the job. If this is set to TRUE , then Oracle parses the procedure associated with the job the first time that the job is run.
For example, if you want to submit a job before you have created the tables associated with the job, then set this to TRUE .
When a job is submitted, specifies which instance can run the job.
If this is TRUE , then any positive integer is acceptable as the job instance. If this is FALSE (the default), then the specified instance must be running; otherwise the routine raises an exception.
You must issue a COMMIT statement immediately after the statement.
The parameters instance and force are added for job queue affinity. Job queue affinity gives users the ability to indicate whether a particular instance or any instance can run a submitted job.
This submits a new job to the job queue. The job calls the procedure DBMS_DDL . ANALYZE_OBJECT to generate optimizer statistics for the table DQUON . ACCOUNTS . The statistics are based on a sample of half the rows of the ACCOUNTS table. The job is run every 24 hours:
RUN Procedure
This procedure runs job JOB now. It runs it even if it is broken.
Running the job recomputes next_date . See view user_jobs .
Number of the job being run.
If this is TRUE , then instance affinity is irrelevant for running jobs in the foreground process. If this is FALSE , then the job can be run in the foreground only in the specified instance.
This re-initializes the current session's packages.
An exception is raised if force is FALSE , and if the connected instance is the wrong one.
USER_EXPORT Procedures
There are two overloaded procedures. The first produces the text of a call to re-create the given job. The second alters instance affinity (8 i and after) and preserves the compatibility.
Number of the job being run.
Text of a call to re-create the given job.
Text of a call to alter instance affinity.
WHAT Procedure
This procedure changes what an existing job does, and replaces its environment.
This is one of the most common Scheduler questions asked.
Here we list some of the common problems and their solutions.
1) job_queue_processes may be too low (this is the most common problem)
The value of job_queue_processes limits the total number of dbms_scheduler
and dbms_job jobs that can be running at a given time.
To check whether this is the case check the current value of
job_queue_processes with
SQL> select value from v$parameter where name='job_queue_processes';
Then check the number of running jobs
SQL> select count(*) from dba_scheduler_running_jobs;
SQL> select count(*) from dba_jobs_running;
If this is the problem you can increase the parameter using
SQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes may be too low
If this parameter is not NULL then it limits how many dbms_scheduler jobs can
be running at a time. To check whether this is the problem, check the current
value using
SQL> select value from dba_scheduler_global_attribute
where attribute_name='MAX_JOB_SLAVE_PROCESSES';
Then check the number of running jobs
SQL> select count(*) from dba_scheduler_running_jobs;
If this is the problem you can increase the number or just NULL it out using
SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) sessions may be too low
This parameter limits the number of sessions at any time. Every Scheduler job
requires 2 sessions. To check whether this is the problem, check the current
valule using
SQL> select value from v$parameter where name='sessions';
Then check the current number of sessions using
SQL> select count(*) from v$session ;
If the numbers are too close you can increase the maximum using
SQL> alter system set job_queue_processes=200;
4) Have you recently applied a timezone update patch or upgraded the database
to a version with newer timezone information ? If you skipped any steps when
updating the timezone information, jobs may not run. To check whether this
is the case try doing
SQL> select * from sys.scheduler$_job;
and
SQL> select * from sys.scheduler$_window;
and make sure they finish without errors.
If it throws a timezone warning, reapply the upgrade or
timezone patch making sure to follow all the steps.
5) Is the database running in restricted mode ?
If the database is running in restricted mode then no jobs will run (unless
you are using 11g and use the ALLOW_RUNS_IN_RESTRICTED_MODE attribute).
To check this use
SQL> select logins from v$instance ;
If logins is restricted you can disable the restricted mode using
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) Is the job scheduled to run on an instance which is down ?
You can check this by seeing whether instance_id is set for the job (check the dba_scheduler_jobs view), and if so you should check whether that instance is up.
7) Is the job scheduled to run on a service which has not been started on any instances ?
You can check this by checking what job_class a job points to and then checking whether that class points to a service. If it does, make sure the service has been started on at least one running instance. You can start a service on an instance using dbms_service.start_service.
8) Is the Resource Manager in effect with a restrictive resource plan ?
If a restrictive resource plan is in effect, scheduler jobs may not have sufficient resources allocated so they may not run. You can check what resource plan is in effect by doing
SQL> select name from V$RSRC_PLAN ;
If no plan is in effect or the plan in effect is INTERNAL_PLAN then the resource manager is not in effect. If the resource manager is in effect you can disable it by doing
SQL>alter system set resource_manager_plan = '';
9) Has the Scheduler been disabled ? This is not a supported action
but it is possible that someone has done it anyway. To check this do
SQL> select value from dba_scheduler_global_attribute where attribute_name='SCHEDULER_DISABLED'
If this query returns TRUE then you can fix this using
SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Reasons why jobs may run late
1) The first thing to check is the timezone that the job is scheduled with
SQL> select owner, job_name, next_run_date from dba_scheduler_jobs ;
If the jobs are in the wrong timezone they may not run at the expected
time. If the next_run_date is using an absolute timezone offset (like
+08:00) instead of a named timezone (like US/PACIFIC) then the jobs may not
run as expected if daylight savings is in effect - they may run an hour
early or late.
2) It may be that at the time the job was scheduled to run, one of the several
limits above may have been temporarily reached causing the job to be delayed.
Check if the limits above are high enough and if possible check them during
the time that the job is being delayed.
3) One possible reason that one of the above limits may be hit is that a
maintenance window may have come into effect. Maintenance windows are Oracle
Scheduler windows that belong to the window group named
MAINTENANCE_WINDOW_GROUP. During a scheduled maintenance window, several
maintenance tasks are run using jobs. This may cause one of the limits listed
above to be hit and user jobs to be delayed. See the admin guide for more info
about this (chapter 24).
To get a list of maintenance windows use
SQL> select * from dba_scheduler_wingroup_members;
To see when the windows run use
SQL> select * from dba_scheduler_windows;
To fix this you can either increase the limits or reschedule the maintenance
windows to run at more convenient times.
Diagnosing other Problems
If none of this works, here are some further steps you can take to try to
figure out what is going on.
1) Check whether there are any errors in the alert log. If the database is
having trouble allocating memory or has run out of disk space or any other
catastrophic errors have occurred, you should resolve those first. You can
find the location of the alert log by using
SQL> select value from v$parameter where name = 'background_dump_dest';
The alert log will be in this directory with a name starting with "alert".
2) Check whether if a job coordinator trace file and if it does, check if it
contains any errors. If this exists, it will be located in the
'background_dump_dest' directory which you can find as above and will look
something like SID-cjq0_nnnn.trc . If there are any errors here they may
hint at why jobs are not running.
3) If either of the above indicates that the SYSAUX tablespace (where the scheduler stores its logging tables) is full, you can use the dbms_scheduler.purge_log procedure to clear out old log entries.
4) See if there is a window currently open. If there is, you can try closing it to see if that helps .
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5)try running a simple run-once job and see if it runs
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) If a simple run-once job doesn't run, you can try restarting the scheduler as follows.
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');
Это один из наиболее часто задаваемых вопросов Планировщику. Здесь мы перечисляем некоторые из распространенных проблем и способы их решения.
1) job_queue_processes может быть слишком низким (это наиболее распространенная проблема) Значение job_queue_processes ограничивает общее количество dbms_scheduler и задания dbms_job, которые могут выполняться в заданное время. Чтобы проверить, так ли это, проверьте текущее значение job_queue_processes с SQL> выберите значение из параметра v $, где name = 'job_queue_processes'; Затем проверьте количество запущенных заданий. SQL> выберите количество () из dba_scheduler_running_jobs; SQL> выберите количество () из dba_jobs_running;
Если это проблема, вы можете увеличить параметр, используя SQL> alter system set job_queue_processes = 1000;
2) max_job_slave_processes может быть слишком низким. Если этот параметр не равен NULL, он ограничивает количество заданий dbms_scheduler, которые могут выполняться одновременно. Чтобы проверить, является ли это проблемой, проверьте текущее значение с помощью SQL> выберите значение из dba_scheduler_global_attribute, где attribute_name = 'MAX_JOB_SLAVE_PROCESSES'; Затем проверьте количество выполняемых заданий. SQL> выберите количество (*) из dba_scheduler_running_jobs;
Если это проблема, вы можете увеличить число или просто обнулить его, используя SQL> exec dbms_scheduler.set_scheduler_attribute ('max_job_slave_processes', null)
3) количество сеансов может быть слишком низким. Этот параметр ограничивает количество сеансов в любое время. Для каждого задания планировщика требуется 2 сеанса. Чтобы проверить, является ли это проблемой, проверьте текущее значение с помощью SQL> выберите значение из параметра v $, где name = 'sessions'; Затем проверьте текущее количество сеансов с помощью SQL> выберите count (*) from v $ session;
Если числа слишком близки, вы можете увеличить максимум, используя SQL> alter system set job_queue_processes = 200;
4) Применяли ли вы недавно патч обновления часового пояса или обновляли ли базу данных до версии с более новой информацией о часовом поясе? Если вы пропустили какие-либо шаги при обновлении информации о часовом поясе, задания могут не выполняться. Чтобы проверить, так ли это, попробуйте выполнить SQL> select * from 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) Планировщик отключен? Это не поддерживаемое действие, но возможно, что кто-то все равно его выполнил. Чтобы проверить это, выполните SQL> выберите значение из dba_scheduler_global_attribute, где attribute_name = 'SCHEDULER_DISABLED'
Причины опоздания с вакансиями
1) Первое, что нужно проверить, - это часовой пояс, в котором задание запланировано с помощью SQL> выберите владельца, имя_задания, дату_следующего_пуска из dba_scheduler_jobs;
Если задания находятся в неправильном часовом поясе, они могут не выполняться в ожидаемое время. Если next_run_date использует абсолютное смещение часового пояса (например, +08: 00) вместо именованного часового пояса (например, US / PACIFIC), тогда задания могут выполняться не так, как ожидалось, если действует летнее время - они могут выполняться на час раньше или позже. .
2) Может случиться так, что в то время, когда задание было запланировано для запуска, одно из нескольких указанных выше ограничений могло быть временно достигнуто, что привело к задержке задания. Убедитесь, что указанные выше пределы достаточно высоки, и, если возможно, проверьте их во время задержки задания.
3) Одна из возможных причин, по которой может быть превышен один из вышеуказанных пределов, заключается в том, что, возможно, вступил в силу интервал обслуживания. Окна обслуживания - это окна планировщика Oracle, которые принадлежат группе окон с именем MAINTENANCE_WINDOW_GROUP. Во время планового окна обслуживания несколько задач обслуживания запускаются с помощью заданий. Это может привести к срабатыванию одного из перечисленных выше ограничений и задержке пользовательских заданий. Дополнительную информацию об этом см. В руководстве администратора (глава 24).
Чтобы получить список окон обслуживания, используйте SQL> выберите * from dba_scheduler_wingroup_members;
Чтобы увидеть, когда запускаются окна, используйте SQL> выберите * from dba_scheduler_windows;
Диагностика других проблем
Если ничего из этого не сработает, вот еще несколько шагов, которые вы можете предпринять, чтобы попытаться выяснить, что происходит.
1) Проверьте, нет ли ошибок в журнале предупреждений. Если у базы данных возникли проблемы с выделением памяти, закончилось место на диске или возникли другие катастрофические ошибки, вы должны сначала устранить их. Вы можете найти местоположение журнала предупреждений, используя SQL> выберите значение из параметра v $, где name = 'background_dump_dest'; Журнал предупреждений будет находиться в этом каталоге с именем, начинающимся с "предупреждения".
2) Проверьте, есть ли файл трассировки координатора заданий, и если он есть, проверьте, содержит ли он какие-либо ошибки. Если он существует, он будет расположен в каталоге 'background_dump_dest', который вы можете найти, как указано выше, и будет выглядеть примерно как SID-cjq0_nnnn.trc. Если здесь есть какие-либо ошибки, они могут намекнуть, почему задания не выполняются.
3) Если любое из вышеперечисленных указывает, что табличное пространство SYSAUX (где планировщик хранит свои таблицы журналирования) заполнено, вы можете использовать процедуру dbms_scheduler.purge_log для очистки старых записей журнала.
4) Посмотрите, открыто ли в данный момент окно. Если есть, вы можете попробовать закрыть его, чтобы посмотреть, поможет ли это.
5) попробуйте запустить простое однократное задание и посмотрите, работает ли оно
6) Если простое однократное задание не запускается, вы можете попробовать перезапустить планировщик следующим образом.
В многопользовательской среде контейнер также должен иметь правильное значение для job_queue_processes.
This is one of the most common Scheduler questions asked. Here we list some of the common problems and their solutions.
1) job_queue_processes may be too low (this is the most common problem) The value of job_queue_processes limits the total number of dbms_scheduler and dbms_job jobs that can be running at a given time. To check whether this is the case check the current value of job_queue_processes with SQL> select value from v$parameter where name='job_queue_processes'; Then check the number of running jobs SQL> select count() from dba_scheduler_running_jobs; SQL> select count() from dba_jobs_running;
If this is the problem you can increase the parameter using SQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes may be too low If this parameter is not NULL then it limits how many dbms_scheduler jobs can be running at a time. To check whether this is the problem, check the current value using SQL> select value from dba_scheduler_global_attribute where attribute_name='MAX_JOB_SLAVE_PROCESSES'; Then check the number of running jobs SQL> select count(*) from dba_scheduler_running_jobs;
If this is the problem you can increase the number or just NULL it out using SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) sessions may be too low This parameter limits the number of sessions at any time. Every Scheduler job requires 2 sessions. To check whether this is the problem, check the current valule using SQL> select value from v$parameter where name='sessions'; Then check the current number of sessions using SQL> select count(*) from v$session ;
If the numbers are too close you can increase the maximum using SQL> alter system set job_queue_processes=200;
4) Have you recently applied a timezone update patch or upgraded the database to a version with newer timezone information ? If you skipped any steps when updating the timezone information, jobs may not run. To check whether this is the case try doing SQL> select * from sys.scheduler$_job; and SQL> select * from sys.scheduler$_window; and make sure they finish without errors.
If it throws a timezone warning, reapply the upgrade or timezone patch making sure to follow all the steps.
5) Is the database running in restricted mode ? If the database is running in restricted mode then no jobs will run (unless you are using 11g and use the ALLOW_RUNS_IN_RESTRICTED_MODE attribute). To check this use SQL> select logins from v$instance ;
If logins is restricted you can disable the restricted mode using SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) Is the job scheduled to run on an instance which is down ?
You can check this by seeing whether instance_id is set for the job (check the dba_scheduler_jobs view), and if so you should check whether that instance is up.
7) Is the job scheduled to run on a service which has not been started on any instances ?
You can check this by checking what job_class a job points to and then checking whether that class points to a service. If it does, make sure the service has been started on at least one running instance. You can start a service on an instance using dbms_service.start_service.
8) Is the Resource Manager in effect with a restrictive resource plan ?
If a restrictive resource plan is in effect, scheduler jobs may not have sufficient resources allocated so they may not run. You can check what resource plan is in effect by doing
SQL> select name from V$RSRC_PLAN ;
If no plan is in effect or the plan in effect is INTERNAL_PLAN then the resource manager is not in effect. If the resource manager is in effect you can disable it by doing
SQL>alter system set resource_manager_plan = '';
9) Has the Scheduler been disabled ? This is not a supported action but it is possible that someone has done it anyway. To check this do SQL> select value from dba_scheduler_global_attribute where attribute_name='SCHEDULER_DISABLED'
If this query returns TRUE then you can fix this using SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Reasons why jobs may run late
1) The first thing to check is the timezone that the job is scheduled with SQL> select owner, job_name, next_run_date from dba_scheduler_jobs ;
If the jobs are in the wrong timezone they may not run at the expected time. If the next_run_date is using an absolute timezone offset (like +08:00) instead of a named timezone (like US/PACIFIC) then the jobs may not run as expected if daylight savings is in effect - they may run an hour early or late.
2) It may be that at the time the job was scheduled to run, one of the several limits above may have been temporarily reached causing the job to be delayed. Check if the limits above are high enough and if possible check them during the time that the job is being delayed.
3) One possible reason that one of the above limits may be hit is that a maintenance window may have come into effect. Maintenance windows are Oracle Scheduler windows that belong to the window group named MAINTENANCE_WINDOW_GROUP. During a scheduled maintenance window, several maintenance tasks are run using jobs. This may cause one of the limits listed above to be hit and user jobs to be delayed. See the admin guide for more info about this (chapter 24).
To get a list of maintenance windows use SQL> select * from dba_scheduler_wingroup_members;
To see when the windows run use SQL> select * from dba_scheduler_windows;
To fix this you can either increase the limits or reschedule the maintenance windows to run at more convenient times.
Diagnosing other Problems
If none of this works, here are some further steps you can take to try to figure out what is going on.
1) Check whether there are any errors in the alert log. If the database is having trouble allocating memory or has run out of disk space or any other catastrophic errors have occurred, you should resolve those first. You can find the location of the alert log by using SQL> select value from v$parameter where name = 'background_dump_dest'; The alert log will be in this directory with a name starting with "alert".
2) Check whether if a job coordinator trace file and if it does, check if it contains any errors. If this exists, it will be located in the 'background_dump_dest' directory which you can find as above and will look something like SID-cjq0_nnnn.trc . If there are any errors here they may hint at why jobs are not running.
3) If either of the above indicates that the SYSAUX tablespace (where the scheduler stores its logging tables) is full, you can use the dbms_scheduler.purge_log procedure to clear out old log entries.
4) See if there is a window currently open. If there is, you can try closing it to see if that helps .
5)try running a simple run-once job and see if it runs
6) If a simple run-once job doesn't run, you can try restarting the scheduler as follows.
Security Model
No specific system privileges are required to use DBMS_JOB . No system privileges are available to manage DBMS_JOB . Jobs cannot be altered or deleted other than jobs owned by the user. This is true for all users including those users granted DBA privileges.
You can execute procedures that are owned by the user or for which the user is explicitly granted EXECUTE . However, procedures for which the user is granted the execute privilege through roles cannot be executed.
Note that, once a job is started and running, there is no easy way to stop the job.
Using DBMS_JOB
NEXT_DATE Procedure
This procedure changes when an existing job next runs.
Number of the job being run.
Date of the next refresh: it is when the job will be automatically run, assuming there are background processes attempting to run it.
You must issue a COMMIT statement immediately after the statement.
REMOVE Procedure
This procedure removes an existing job from the job queue. This currently does not stop a running job.
Number of the job being run.
You must issue a COMMIT statement immediately after the statement.
INTERVAL Procedure
This procedure changes how often a job runs.
Number of the job being run.
Date function, evaluated immediately before the job starts running.
If the job completes successfully, then this new date is placed in next_date . interval is evaluated by plugging it into the statement select interval into next_date from dual;
The interval parameter must evaluate to a time in the future. Legal intervals include:
Interval | Description |
---|---|
'sysdate + 7' | Run once a week. |
'next_day(sysdate,''TUESDAY'')' | Run once every Tuesday. |
'null' | Run only once. |
If interval evaluates to NULL and if a job completes successfully, then the job is automatically deleted from the queue.
You must issue a COMMIT statement immediately after the statement.
Operational Notes
Working with Real Application Clusters
DBMS_JOB supports multi-instance execution of jobs. By default jobs can be executed on any instance, but only one single instance will execute the job. In addition, you can force instance binding by binding the job to a particular instance. You implement instance binding by specifying an instance number to the instance affinity parameter. Note, however, that in Oracle Database 10g Release 1 (10.1) instance binding is not recommended. Service affinity is preferred. This concept is implemented in the DBMS_SCHEDULER package.
The following procedures can be used to create, alter or run jobs with instance affinity. Note that not specifying affinity means any instance can run the job.
DBMS_JOB.SUBMIT
To submit a job to the job queue, use the following syntax:
Use the parameters instance and force to control job and instance affinity. The default value of instance is 0 (zero) to indicate that any instance can execute the job. To run the job on a certain instance, specify the instance value. Oracle displays error ORA-23319 if the instance value is a negative number or NULL.
The force parameter defaults to false. If force is TRUE, any positive integer is acceptable as the job instance. If force is FALSE, the specified instance must be running, or Oracle displays error number ORA-23428.
DBMS_JOB.INSTANCE
To assign a particular instance to execute a job, use the following syntax:
The FORCE parameter in this example defaults to FALSE. If the instance value is 0 (zero), job affinity is altered and any available instance can execute the job despite the value of force. If the INSTANCE value is positive and the FORCE parameter is FALSE, job affinity is altered only if the specified instance is running, or Oracle displays error ORA-23428.
If the force parameter is TRUE , any positive integer is acceptable as the job instance and the job affinity is altered. Oracle displays error ORA-23319 if the instance value is negative or NULL .
To alter user-definable parameters associated with a job, use the following syntax:
Two parameters, instance and force, appear in this example. The default value of instance is null indicating that job affinity will not change.
The default value of force is FALSE. Oracle displays error ORA-23428 if the specified instance is not running and error ORA-23319 if the instance number is negative.
Stopping a Job
Note that, once a job is started and running, there is no easy way to stop the job.
Читайте также: