|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
Есть основной джоб. Из него циклом запускаются новые джобы, которые параллельно собирают данные на сервер. По завершении сбора (то есть после того как вызванные джобы пройдут), нужно продолжить выполнение старого\вызвать новый джоб с процедурой обработки собранных данных. Пока приходит только идея с записью во временную таблицу по завершении каждого джоба и триггер на эту таблицу, после апдейта проверяется кол-во записей в этой таблице, если оно равно определенному значению, запускается новый джоб с процедурой обработки собранных данных. Но как то это "кустарно". У кого-нибудь еще есть идеи как это реализовать? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2019, 16:08 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
DBMS_SCHEDULER chain. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2019, 16:16 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
SY, спасибо, пошел читать документацию! ... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2019, 16:47 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
Погуглил, получилось сделать, но не нравится, что хардкодом. У меня около 40 chain_step' ов, которые состоят из процедуры proc(i), где i= 1...40. То есть: BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain', 'proc_1', 'my_program1'); DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain', 'proc_2', 'my_program2'); .............. END; proc_1 = proc(1); proc_2 = proc(2)..... Нагуглил, что "There is no direct way of passing parameters to a chain step on the fly but there is a way to workaround it.". https://community.oracle.com/message/9666831#9664831 Там есть ссылка на пример, но все равно ясности не появилось как делать. Ну и пример 2007 года, может что новое появилось в этом плане. То есть не хочется создавать 40 отдельных программ, с каждой программой связывать 40 стэпов, а потом передавать это все в define_chain_rule, учитывая, что каждая программа - это одна и та же ХП с разными параметрами. Может кто-то сталкивался, буду благодарен за пример или ссылочку где эта проблема подробно описана. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 15:58 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
ArchiSQLПогуглил, получилось сделать, но не нравится, что хардкодом. У меня около 40 chain_step' ов, которые состоят из процедуры proc(i), где i= 1...40. То есть: BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain', 'proc_1', 'my_program1'); DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain', 'proc_2', 'my_program2'); .............. END; proc_1 = proc(1); proc_2 = proc(2)..... Нагуглил, что "There is no direct way of passing parameters to a chain step on the fly but there is a way to workaround it.". https://community.oracle.com/message/9666831#9664831 Там есть ссылка на пример, но все равно ясности не появилось как делать. Ну и пример 2007 года, может что новое появилось в этом плане. То есть не хочется создавать 40 отдельных программ, с каждой программой связывать 40 стэпов, а потом передавать это все в define_chain_rule, учитывая, что каждая программа - это одна и та же ХП с разными параметрами. Может кто-то сталкивался, буду благодарен за пример или ссылочку где эта проблема подробно описана. Спасибо. Может проще все это сделать в одной процедуре? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 16:03 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
ArchiSQLЕсть основной джоб. Из него циклом запускаются новые джобы, которые параллельно собирают данные на сервер. По завершении сбора (то есть после того как вызванные джобы пройдут), нужно продолжить выполнение старого\\вызвать новый джоб с процедурой обработки собранных данных.Параллельная обработка данных из процедуры ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 16:04 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
Vadim Lejnin, так если я делаю в одной процедуре - где распараллеливание? Там же будет выполняться все последовательно, собственно сейчас так и есть. Ведь вся суть состоит в том, что скрипты через дблинки обращаются к нескольким серверам, сейчас это все происходит последовательно, занимает много времени, я хочу сделать параллельно. Или я Вас неправильно понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 16:48 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
Elic, Спасибо, я думал над таким вариантом (правда думал делать через системное представление dba_jobs_running), но хочется спросить вот что - если к примеру ночью запустился job, процедура зависла, получается цикл loop будет крутиться все время, пока не сделаешь дисконнект сессии вручную. К примеру если тебя нет несколько дней на работе и все это время цикл крутится - такая практика будет считаться нормальной? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 16:55 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
ArchiSQL, версия сервера? джобики 1-40 должны/могут выполняться параллельно? DBMS_PARALLEL_EXECUTE.create_chunks_by_sql ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 17:04 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
Прекрасно обходится чeрез global context. Step1 устанавливает global context variables в значения параметров всех процедур. Step2 - Step41 выполняются параллельно по завершении Step1 и есть: Код: plsql 1. 2. 3.
SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 17:14 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
ArchiSQLК примеру если тебя нет несколько дней на работе и все это время цикл крутится - такая практика будет считаться нормальной?Тут как и "кому кобыла невеста". ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 17:28 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
SYПрекрасно обходится чeрез global context. Step1 устанавливает global context variables в значения параметров всех процедур. Step2 - Step41 выполняются параллельно по завершении Step1 и есть: Код: plsql 1. 2. 3.
SY. Сейчас у меня нечто подобное: Код: 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. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84.
Не понимаю, как мне могут помочь глобальные контекстные переменные. Если при создании программ я еще могу сделать нечто подобное (взял из статьи Пржиялковского), указав параметр number_of_arguments : Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Но как сделать так, чтобы не было 40 отдельных степов.... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2019, 09:27 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
MazoHistArchiSQL, версия сервера? джобики 1-40 должны/могут выполняться параллельно? DBMS_PARALLEL_EXECUTE.create_chunks_by_sql 12с. По хорошему должны выполняться параллельно. Про parallel_execute сейчас почитаю, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2019, 09:29 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
Глобальный контекст создается один раз. Всe шаги создаются один раз. Первый шаг присваивает значения параметров 40-ка параллельных шагов переменным контeкста. Параллельные шаги выполняются по завершении первого шага. Каждый из них использует соосветствующие значения глобального контекста вместо того что было раньше передано как параметр (тупо делаем обертку). Последний шаг выполняется после завершения (successful) параллельных шагов. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2019, 15:36 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
ArchiSQLMazoHistArchiSQL, версия сервера? джобики 1-40 должны/могут выполняться параллельно? DBMS_PARALLEL_EXECUTE.create_chunks_by_sql 12с. По хорошему должны выполняться параллельно. Про parallel_execute сейчас почитаю, спасибо. Вроде бы получилось - то что я хотел - 40 процедур запускаются параллельно, по завершении всех этих процедур запускается еще одна процедура, которая обрабатывает собранные данные. Упрощенно выглядит так: Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2019, 17:04 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
SYГлобальный контекст создается один раз. Всe шаги создаются один раз. Первый шаг присваивает значения параметров 40-ка параллельных шагов переменным контeкста. Параллельные шаги выполняются по завершении первого шага. Каждый из них использует соосветствующие значения глобального контекста вместо того что было раньше передано как параметр (тупо делаем обертку). Последний шаг выполняется после завершения (successful) параллельных шагов. SY. Спасибо, завтра на свежую голову подумаю на Вашими словами, хочется с chain также сделать, очень понравилась гибкость пакета DBMS_SCHEDULER :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2019, 17:07 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
SYГлобальный контекст создается один раз. Всe шаги создаются один раз. Первый шаг присваивает значения параметров 40-ка параллельных шагов переменным контeкста. Параллельные шаги выполняются по завершении первого шага. Каждый из них использует соосветствующие значения глобального контекста вместо того что было раньше передано как параметр (тупо делаем обертку). Последний шаг выполняется после завершения (successful) параллельных шагов. SY. Я Вас правильно понял, что вот здесь: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
я i заменяю на SYS_CONTEXT('CONTEXT_NAME','PROC_PAR' || i), предварительно создав глобальную контекстную переменную: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Я все равно не могу понять - у нас все так же 40 программ и все так же будет 40 созданных шагов. В чем преимущество или я неправильно Вас понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 15:05 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
SYПрекрасно обходится чeрез global context. Step1 устанавливает global context variables в значения параметров всех процедур. Step2 - Step41 выполняются параллельно по завершении Step1 и есть: Код: plsql 1. 2. 3.
SY. И почему здесь у функции PROC1 кол-во параметров равно n? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 15:06 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
ArchiSQLЯ все равно не могу понять - у нас все так же 40 программ и все так же будет 40 созданных шагов. В чем преимущество или я неправильно Вас понял? CHAIN удобно использовать когда у нас сильно "ветвистая" логика - 1 -2 потом 3-4 параллельно потом если что-то неудачно то 5 если все удачно то 6. Если у нас 40 почти одинаковых процессов которые запускаются одновременно, а потом вне зависимости от их исхода выполняется еще что-то, то DBMS_PARALLEL_EXECUTE - то что доктор прописал. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 15:39 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
MazoHistArchiSQLЯ все равно не могу понять - у нас все так же 40 программ и все так же будет 40 созданных шагов. В чем преимущество или я неправильно Вас понял? CHAIN удобно использовать когда у нас сильно "ветвистая" логика - 1 -2 потом 3-4 параллельно потом если что-то неудачно то 5 если все удачно то 6. Если у нас 40 почти одинаковых процессов которые запускаются одновременно, а потом вне зависимости от их исхода выполняется еще что-то, то DBMS_PARALLEL_EXECUTE - то что доктор прописал. Да, с помощью DBMS_PARALLEL_EXECUTE (Вам спасибо за подсказку по этому пакету) я уже сделал, сейчас тестируется, теперь хочу с chain разобраться что SY имел ввиду с контекстными переменными - я скорее всего его мысль не уловил, иначе у меня смысла использования контекстных переменных нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2019, 16:03 |
|
Распараллеливание джобов. Продолжение работы после завершения выполнения вызванных джобов.
|
|||
---|---|---|---|
#18+
SY, Вы имели ввиду такую реализацию с глобальными контекстными переменными? Код: 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. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2019, 16:13 |
|
|
start [/forum/topic.php?fid=52&fpage=84&tid=1882777]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 150ms |
0 / 0 |