|
|
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. Знаю, что Оракл не real time система, но саппорт баг признал, дали патч, патч не помог, ждём следующего патча. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 12:27 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avas, а зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 12:32 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avasЗнаю, что Оракл не real time системаНо, тем не менее, продолжали грызть кактус. avasно саппорт баг признал,Корпоративно толерантный индус вежливо не стал спорить с неадекватным клиентом? avasдали патч, Код: plsql 1. ? avasпатч не помог,Фимоз головного мозга не патчится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 12:38 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
dbms_lock.спатьavas, а зачем? вызывать sync на oracle text индекс. сейчас он на commit стоит, но с ним есть такая проблема, что если параллельно идёт много изменений одного параметра в xml (в разных записях, не одной) - то возникает много локов, и индекс обновляется медленно. oracle text используем для быстрого поиска из UI ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 12:45 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
ElicНо, тем не менее, продолжали грызть кактус. на elastic за неделю не перейдёшь Elic Код: plsql 1. ? 19417094 a _job_queue_interval помогает на 11, на 12 не помогает ElicФимоз головного мозга не патчится. Они стараются: Thanks for your patience, we have created Predefect update with internal Bug Engineers and we will update soon ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 12:53 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
ElicКорпоративно толерантный индус вежливо не стал спорить с неадекватным клиентом? не понял, а о чём мы должны были спорить (к тому же у нас есть свой корпоративно толерантный индус)? Есть воспроизводимая проблема, значит или мы не правильно используем (тогда ожидаем что это будет официально написано, что interval = 1 sec ничего не гарантирует), или система работаем не в соответствии с документацией. Они не стали говорить что так нельзя делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 13:12 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avasdbms_lock.спатьavas, а зачем? вызывать sync на oracle text индексповесь триггер, который в очередь кидает событие. джоб на событие, который заглатывает все события, накопленные к моменту чтения очереди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 13:15 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avasdbms_lock.спатьavas, а зачем? вызывать sync на oracle text индекс. сейчас он на commit стоит А значение параметра Код: plsql 1. тебе зачем сделали? Или ты документацию принципиально не читаешь? Прав Элик... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 13:17 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
цтх_контекст Код: plsql 1. тебе зачем сделали? Или ты документацию принципиально не читаешь? Прав Элик... SYNC EVERY создаёт scheduler job, который и вызывает sync. Наблюдая как выполняется этот job и обнаружили проблему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 13:24 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
монополовой доступповесь триггер, который в очередь кидает событие. джоб на событие, который заглатывает все события, накопленные к моменту чтения очереди. шо? индекс и так позволяет создать sync on commit. а джоб не получается выполнять слишком часто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 13:28 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avasЕсть воспроизводимая проблема, значит или мы не правильно используем (тогда ожидаем что это будет официально написано, что interval = 1 sec ничего не гарантирует), или система работаем не в соответствии с документацией.А голова-то на что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 13:31 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
цтх_контекст Код: plsql 1. полагаешь, указанное в every заносится в швейцарские часы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 13:34 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
На самом деле вы не совсем на ту дату смотрите Запрос показывающий детализацию (время постановки джоба в очередь на выполнение=REQ_START_DATE, реальное время запуска джоба=ACTUAL_START_DATE, и время записи в лог=LOG_DATE Код: plsql 1. 2. 3. Из этого следует что джоб в очередь на выполнение поставлен как раз с интервалом в секунду, только вот Oracle официально не гарантирует что джоб начнет выполняться сразу после постановки в очередь - задержка старта выполнения джоба может зависеть и от ко-ва выполняемых джобов в данный момент и от общей нагрузки на БД и тд и тп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 14:00 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
или наглядно: Код: plsql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 14:49 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
REQ_START_DATEИз этого следует что джоб в очередь на выполнение поставлен как раз с интервалом в секунду, только вот Oracle официально не гарантирует что джоб начнет выполняться сразу после постановки в очередь - задержка старта выполнения джоба может зависеть и от ко-ва выполняемых джобов в данный момент и от общей нагрузки на БД и тд и тп. точнее будет сказать, через секунду после последнего выполнения: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 14:55 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
ElicА голова-то на что? В отсутствии полных данных как оно работает внутри, полагаться на догадки и предположения тоже не есть хорошо. Голова говорит, что раз заявлена поддержка одно-секундного интервала, то в +/- 33% должно попадать. Ну и в конце концов их индус нашего индуса не послал с аргументом что такое поведение by design ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 15:03 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avasраз заявлена поддержка одно-секундного интервалаГде? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 15:05 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 15:17 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
Elicavasраз заявлена поддержка одно-секундного интервалаГде? ладно, давайте переформулирую: Есть документация на пакет dbms_scheduler - http://docs.oracle.com/database/122/ARPLS/DBMS_SCHEDULER.htm Для параметра repeat_interval можно указывать следующие значения: FREQ - SECONDLY, INTERVAL - positive integer (default is 1, which means every second for secondly) - т.е. этой фразой и отсутствием какого-либо предупреждения о том что 1 second interval не будут работать стабильно - неявно (да, неявно, но другого ничего нет) говорят о том, что 1 second interval вполне нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2017, 15:21 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
orcl2avas, Не пробовали Lightweight Jobs ? пробовали, тоже самое: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 11:51 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
Разбирались с похожей поблемой года 3 назад на 11.2.0.4. У нас генерилось достаточно большое количество джобов (сотни в секунду). Иногда запуск джобов начинал замедляться. При этом были видны ожидания у процесса CJQ (джоб координатор). Попробовали перевести все что смогли на lightweight и сократить до минимума информацию о джобах (поставили минимальные сроки хранения логов и т.п., проверили и почистили очереди и таблицы очередей), стало полегче, но проблема все равно проявлялась при пиковых нагрузках. Завели тикет в поддержку, долго разбирались, ставили все патчи, которые так или иначе относятся к шедулеру, но ситуация не менялась. Подняли важность проблемы до максимального через наших американских коллег, но в итоге получили ответ, что механизм шедулера на такой юз кейс не рассчитан (к сожалению не могу цитировать точно, т.к. нет доступа к старому аккаунту поддержки) , т.е. ставить можно джобов сколько угодно, но вот то что они будут запускаться секунда в секунду никто гарантировать не может. В итоге пришлось срочно писать обходной механизм, который исключил какую-то часть джобов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 12:55 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avas Сейчас столкнулись с проблемой из этой области. После миграции с 11.2 на 12-ю версию, начались проблемы по одному заданию. Задание на старом приложении запускалось каждые 5 сек, через старый Job, где приложение каждый раз создавало 1 разовый. После миграции начались проблемы, что это задание просто отрубалось 1-2 раза в день. Причем ошибок никаких нигде не было, просто отрабатывало и отрубалось на уровне приложения. Перевели механизм на dbms_scheduler так-же с интервалом в 5 сек. На пару дней забыли о проблеме, задание работало беспрерывно, нигде не отключалось, и казалось бы горя не знать, но поймали одну ошибку о медленном обновлении, поднял логи из all_SCHEDULER_JOB_RUN_DETAILS и обнаружил, что есть лаги, где от предыдущего до следующего выполнения задание где-то может шариться от 30-40 секунд до 23-х минут! . Причем никаких ошибок нигде нет. Везде успешные логи. Кто сталкивался с такой проблемой? Есть варианты решения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2017, 11:09 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avasdbms_lock.спатьavas, а зачем? вызывать sync на oracle text индекс. сейчас он на commit стоит, но с ним есть такая проблема, что если параллельно идёт много изменений одного параметра в xml (в разных записях, не одной) - то возникает много локов, и индекс обновляется медленно. oracle text используем для быстрого поиска из UI Гуглите small_r_row опцию для текстовых индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2017, 12:28 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
avas, вам не нужен sync(on commit) - сделайте индекс TRANSACTIONAL и уменьшите частоту синхронизации до 5-15 минут. Кроме того, с 12-й версии появилась такая хорошая штука как near realtime indexes - http://www.oracle.com/technetwork/database/information-management/oracletext12cfeatures-1932547.pdf зы. в 12-й версии с sync(on commit) и small_r_row есть адский баг с бесконечным циклом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2017, 12:43 |
|
||
|
Scheduler job с интервалом в 1 секунду
|
|||
|---|---|---|---|
|
#18+
dimyazavas Сейчас столкнулись с проблемой из этой области. После миграции с 11.2 на 12-ю версию, начались проблемы по одному заданию. Задание на старом приложении запускалось каждые 5 сек, через старый Job, где приложение каждый раз создавало 1 разовый. После миграции начались проблемы, что это задание просто отрубалось 1-2 раза в день. Причем ошибок никаких нигде не было, просто отрабатывало и отрубалось на уровне приложения. Перевели механизм на dbms_scheduler так-же с интервалом в 5 сек. На пару дней забыли о проблеме, задание работало беспрерывно, нигде не отключалось, и казалось бы горя не знать, но поймали одну ошибку о медленном обновлении, поднял логи из all_SCHEDULER_JOB_RUN_DETAILS и обнаружил, что есть лаги, где от предыдущего до следующего выполнения задание где-то может шариться от 30-40 секунд до 23-х минут! . Причем никаких ошибок нигде нет. Везде успешные логи. Кто сталкивался с такой проблемой? Есть варианты решения? UP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2017, 14:13 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39410839&tid=1884330]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
31ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 383ms |

| 0 / 0 |
