| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
diman.tm
Участник
Вступление в Клуб: 19.04.2013
|
 Вт Апр 23, 2013 11:01 Интервал запуска job |
 |
Полезность: Нет оценки
|
Добрый день. Коллеги, столкнулся с проблемой - долго приходит ответ от ПЦ по запросу по картам. Выяснилось, что для обработки запроса и ответа на запрос, должны отработать 3 (!!!) задания по расписанию. В истории запуска заметил, что хоть интервал запуска у них и выставлен 2 секунды, запускаются они все равно каждые 5 секунд. То есть в итоге ожидание примерно 15 секунд.
Поискал о проблеме, наткнулся на рекомендацию изменить JOB_QUEUE_INTERVAL , либо вместо DBMS_JOB использовать DBMS_SCHEDULER. Но по первой рекомендации - такого параметра уже нет в 11.2.0.2.5 Oracle. По поводу второй рекомендации - рестартовал задания по расписанию, выставив галочку тип очереди SCHEDULER. Возросла нагрузка на базу, и стали очень часто генерироваться архивлоги! (порядка 100 ГБ вдень, когда нормально около 16 ГБ в день). Что нагружает базу и генерирует выяснить не получилось, пришлось возвращать обратно.
Можете подсказать как решить проблему с интервалом? Или может есть какие - нибудь рекомендации по использованию DBMS_SCHEDULER ? Саппорт как обычно ничего вразумительного не говорит. |
|
 |
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Вт Апр 23, 2013 12:23 |
|
Полезность: Нет оценки
|
Что то сложно как то все у все у вас , у себя , правда у нас карточный модуль в РБС сделал - просто раз в час интервал запуска задания и все , номер джоба вытаскиваем из dba_jobs
| Код: |
select job from dba_jobs where WHAT like '%UC_FILE%';
BEGIN
DBMS_JOB.CHANGE(168653, null, null, '(SYSDATE + 60/1440)');
COMMIT;
END;
|
_JOB_QUEUE_INTERVAL - не трогать(кстати он есть и в 11.2.ххх), иначе все может встать колом - ибо -
| Цитата: |
The job queue processes "wake up" periodically and check the job queue catalog to see if any jobs are due to execute. The INIT.ORA parameter JOB_QUEUE_INTERVAL controls how long the SNP processes "sleep" (in seconds) between catalog checks. Setting the interval too low can cause unnecessary overhead as SNP processes constantly check the catalog. Setting the interval too high can keep jobs from executing at the expected time if an SNP process does not awaken promptly enough. The proper balance will depend on the specific mix of jobs in a given environment. For most purposes, the default setting of 60 seconds is adequate.
|
|
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Вт Апр 23, 2013 12:31 Re: Интервал запуска job |
|
Полезность: Нет оценки
|
| diman.tm пишет: | | В истории запуска заметил, что хоть интервал запуска у них и выставлен 2 секунды, запускаются они все равно каждые 5 секунд. |
- а может банально не отрабатывать за 2 секунды соответственно тогда не запустится ранее чем отработает. |
|
|
diman.tm
Участник
Вступление в Клуб: 19.04.2013
|
| Вт Апр 23, 2013 12:37 |
|
Полезность: Нет оценки
|
Когда у нас карточный модуль был в РБС - я бед с ним не знал.
Но карточный модуль в ИБСО - это что-то с чем. Реализация просто поражает. Почему нельзя было сделать по проще как в РБС, одному Богу известно.
А джоб отрабатывает моментально, и потом ждем 5 секунд до следующего запуска. |
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Вт Апр 23, 2013 12:40 |
|
Полезность: Нет оценки
|
| Это видно из user_scheduler_job_log ? |
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Вт Апр 23, 2013 12:43 |
|
Полезность: Нет оценки
|
repeat_interval => 'FREQ= SECONDLY; interval=2' так прописано ?
и в z#system_jobs - какой интервал установлен? |
|
|
diman.tm
Участник
Вступление в Клуб: 19.04.2013
|
| Вт Апр 23, 2013 13:03 |
|
Полезность: Нет оценки
|
Я так понял, что user_scheduler_job_log это как раз лог DBMS_SCHEDULER и он распух за 2 дня до 9 миллиона записей, возможно архив логи и растут изза этого...
А историю выполнения я смотрю через сам ИБСО
| Код: |
Запущено 23/04/2013 13:56:19. Выполнено 23/04/2013 13:56:19.
Запущено 23/04/2013 13:56:24. Выполнено 23/04/2013 13:56:24.
Запущено 23/04/2013 13:56:29. Выполнено 23/04/2013 13:56:29.
Запущено 23/04/2013 13:56:34. Выполнено 23/04/2013 13:56:34.
Запущено 23/04/2013 13:56:39. Выполнено 23/04/2013 13:56:39.
Запущено 23/04/2013 13:56:44. Выполнено 23/04/2013 13:56:44.
Запущено 23/04/2013 13:56:49. Выполнено 23/04/2013 13:56:49.
Запущено 23/04/2013 13:56:54. Выполнено 23/04/2013 13:56:54.
Запущено 23/04/2013 13:56:59. Выполнено 23/04/2013 13:56:59.
Запущено 23/04/2013 13:57:04. Выполнено 23/04/2013 13:57:04.
Запущено 23/04/2013 13:57:09. Выполнено 23/04/2013 13:57:09.
Запущено 23/04/2013 13:57:14. Выполнено 23/04/2013 13:57:14.
|
При этом сам джоб
| Код: |
begin
sys.dbms_job.change(job => 2830,
what => 'Z$SYSTEM_JOBS_JOB_LIB.run(''5923757517'',job,next_date,broken);',
next_date => to_date('23-04-2013 14:00:07', 'dd-mm-yyyy hh24:mi:ss'),
interval => 'null');
commit;
end;
/
|
хотя в ИБСО выставлен интервал
|
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Вт Апр 23, 2013 13:18 |
|
Полезность: Нет оценки
|
А если типа вот так попробовать ?
| Код: |
DBMS_SCHEDULER.create_job (
job_name => 'CARD_JOB',
job_type => 'PLSQL_BLOCK',
job_action => 'ТУТ СТАВИМ ТО ЧТО ДОЛЖНО ВЫПОЛНЯТЬСЯ',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ= SECONDLY; interval=2',
end_date => NULL,
enabled => TRUE,
comments => 'Testing job');
|
|
|
|
diman.tm
Участник
Вступление в Клуб: 19.04.2013
|
| Вт Апр 23, 2013 14:22 |
|
Полезность: Нет оценки
|
Аналогично, стартует раз в 5 секунд...
У нас есть джобы созданные не средствами ИБСО, интервал запуска 2 секунды, но стартует тоже раз в 5 секунд.
Отключил логирование DBMS_SCHEDULER джобов, но архивлоги все равно генерирются... |
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Вт Апр 23, 2013 14:43 |
|
Полезность: Нет оценки
|
Надо точно глянуть по логу - что за 2 секунды успевает отработать
процедура -
| Код: |
select log_date,job_name from user_scheduler_job_log order by log_date;
|
Генерация архив логов - это прекрасно, это поможет защитить данные, лог шедуллера никак не относится к объему, чтобы понять кто виноват -
| Код: |
select b.sid, s.serial#, s.username, s.osuser, s.module, s.action, a.name, b.value from v$statname a, v$sesstat b, v$session s where a.statistic#=b.statistic#
and s.sid=b.sid and name like 'redo%' order by value desc
|
|
|
|
diman.tm
Участник
Вступление в Клуб: 19.04.2013
|
| Ср Апр 24, 2013 09:18 |
|
Полезность: Нет оценки
|
user_scheduler_job_log - пуст под IBS. Под SYS записи о джобах SYS
Судя по описанию DBMS_JOB логирование job никуда не ведется.
В статистике мониторить операции "redo blocks written" ? |
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Ср Апр 24, 2013 09:55 |
|
Полезность: Нет оценки
|
| Изначально вопрос же ставился про планировщик - или я что то упустил ?- его и нужно смотреть, настроить в нем задание с интервалом 2 секунды и смотреть, что оно выполняется именно за 2 секунды. Что касаемо роста количества архив логов, в запросе смотрим чья сессия генерирует больше redo записей(redo size) - первые записи и будут лидерами. |
|
|
diman.tm
Участник
Вступление в Клуб: 19.04.2013
|
| Сб Апр 27, 2013 17:50 |
|
Полезность: Нет оценки
|
| Код: |
LOG_DATE JOB_NAME
1 27.04.13 18:24:31.921527 +04:00 JOB$5923757517
2 27.04.13 18:24:32.034790 +04:00 JOB$5923757517
3 27.04.13 18:24:32.138222 +04:00 JOB$5923757517
4 27.04.13 18:24:32.229484 +04:00 JOB$5923757517
5 27.04.13 18:24:32.340931 +04:00 JOB$5923757517
6 27.04.13 18:24:32.430606 +04:00 JOB$5923757517
7 27.04.13 18:24:32.528057 +04:00 JOB$5923757517
8 27.04.13 18:24:32.648399 +04:00 JOB$5923757517
9 27.04.13 18:24:32.740918 +04:00 JOB$5923757517
10 27.04.13 18:24:32.820341 +04:00 JOB$5923757517
11 27.04.13 18:24:32.931962 +04:00 JOB$5923757517
12 27.04.13 18:24:33.031188 +04:00 JOB$5923757517
13 27.04.13 18:24:33.127079 +04:00 JOB$5923757517
14 27.04.13 18:24:33.237342 +04:00 JOB$5923757517
15 27.04.13 18:24:33.353341 +04:00 JOB$5923757517
16 27.04.13 18:24:33.464210 +04:00 JOB$5923757517
17 27.04.13 18:24:33.527564 +04:00 JOB$5923757517
18 27.04.13 18:24:33.639801 +04:00 JOB$5923757517
|
Эмм, судя по выборке задание в планировщике выполняется не раз в 2 секунды, а 10 раз в секунду!
При включении заданий в планировщике начинают безумно быстро генерироваться redo wastage. То есть получается изза слишком частого запуска задания требуется очень частый коммит, и он вызывает запись redo wastage |
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Пн Апр 29, 2013 07:52 |
|
Полезность: Нет оценки
|
| diman.tm пишет: |
Эмм, судя по выборке задание в планировщике выполняется не раз в 2 секунды, а 10 раз в секунду!
|
Я бы сказал что, задание выполняется несколько раз в секунду - это является очень короткой транзакцией и ежели в операции действительно commit, то это бессмысленно нагружает всю БД.
| diman.tm пишет: |
При включении заданий в планировщике начинают безумно быстро генерироваться redo wastage. То есть получается изза слишком частого запуска задания требуется очень частый коммит, и он вызывает запись redo wastage |
Сам по себе вейстидж обычное событие ожидания, но стоит ему "зачастить" и все - превед. Все так и чтоб стало ясно - ставим задание на выполнение в планировщике с интервалом в 2 секунды - не пользуемся Заданиями по расписанию ИБСО ? |
|
|
Denis Scar
Участник со стажем
Вступление в Клуб: 28.09.2007
|
| Вт Апр 30, 2013 05:01 |
|
Полезность: Нет оценки
|
А что вам мешает собрать awr за промежуток и посмотреть кто генерит redo ? А не гадать на кофейной гуще.
Самое просто посмотреть секции "Segments by DB Blocks Changes" и
"Segments by XXX Writes XXX" (XXX потому что там несколько секции так или иначе связанных с записью)
Что касается _JOB_QUEUE_INTERVAL
"The proper balance will depend on the specific mix of jobs in a given environment"
Сомневаюсь что у вас такое большое кол-во джобов, что SNP может встать. Просмотр каталога оптимизирован и будет он просматриваться в 5 раза чаще, думаю проблем не будет. Да, даже если и встанет, то всегда можно откатить.
Он есть в 11.2, посмотреть можно так:
sELECT
a.ksppinm Param ,
b.ksppstvl SessionVal ,
c.ksppstvl InstanceVal,
a.ksppdesc Descr
FROM
x$ksppi a ,
x$ksppcv b ,
x$ksppsv c
WHERE
a.indx = b.indx AND
a.indx = c.indx AND
a.ksppinm LIKE '/_job%' escape '/'
ORDER BY
1;
Если не изменяет память надо с перезагрузкой менять этот параметр.
_________________
shutdown abort;
shutdowning database in progress ... |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
