Dmitry. ФилиппКаким образом выше выделенное может быть решено многопоточным запуском процедуры proc1 и proc2 proc3 соответственно?
Вместо запуска этого алгоритма 20 раз последовательно, хотят запускать его 20 раз но паралельно. т.е. снизить общее время выполнения в разы.
Правда с таким же успехом можно получить и замедление в несколько раз :-(

Лучше для начала провести эсперимент...

OutcastОптимизировать... процедур путем внедрения исправлений в код - шаг нетривиальный и скорее всего неприемлемый
поскольку сразу теряется тех поддержка разработчиков установленного БД
Весьма странный подход, когда для ускорения работы серверной компоненты, правится клиентская часть.

Чем и хорош SQL сервер, что в нем не обязательно исправлять исходные процедуры, можно написать свои паралельные, оптимизированные. Дописывание надеюсь не приводит к "потере поддержки"?

Как вариант таки заставить разработчиков оптимизировать это хозяйство, если нет править самому, нахрен такая поддержка нужна.

Ну и последнее я не специалист по ORACLE, но судя по опыту в SQL, практически все что делается курсором можно сделать проще, быстрее и надежнее, без курсора. Обрабатывая записи пакетом и соответственно избавившись от линейной зависимости времени от количества записей.

OutcastПравда Ваш код в этом случае будет отрабатывать N (=20) запросов за время, равное самому длительному подтверждению из N. Это возможно волне приемлемое решение. Спасибо.

Именно тут на мой взгляд и кроется ошибка, код будет отрабатывать, точно дольше чем "время, равное самому длительному подтверждению из N", возможно за время "сумма всех времен выполнения 1..N", может меньше, может больше, это уже зависит от количества процессоров на сервере, настроек самого сервера и много чего еще.

И не стоит забывать о такой проблеме ORACLE как возможный Rollback в одном из потоков, на сколько вырастет сегмент отката (если не ошибаюсь) при выполнении не одной а 20 процедур.

OutcastНе знаю, что сказать Вам на этот счет ))) (Подробности же Вас не интересуют, не правда ли? )

Если бы не интересовало, то я бы не встревал в разговор.
Outcast
Меня же интересует "принципиальная схема механизма параллельного
запуска хранимых процедур" на клиенте.

Линейного возрастания скорости я не жду - это и ежу понятно, но качественного ускорения добиться этим можно.
У меня была практически аналогичная задача, по проведению документов и решалась примерно так же, DW со списком идентификаторов, и бегущий курсорчик вызывающий ХП с нужным идентификатором и отмечающий в списке галочку/крестик по итогам выполнения процедуры. 100 документов - 200 секунд.

Была поставлена задача повести 10 000 документов за 2 000 секунд АКА пол часа. Вообщем задача была решена, но решена именно:

1) Оптимизацией самой ХП, оптимизацией логики, выкидыванием ненужных проверок, укорением нужных проверок и т.п.
2) Переносом всей обработки на сервер, т.е. на сервере в ХП формируется временная таблица с нужными данными и исползуется уже серверный курсор для вызова ХП-проведения. Этим мы убираем потери на сеть и вызов ХП с клиента.

Все это дало ускорение в 15 раз, правда никаких красивостей на клиенте не отображалось типа галочек и прогресс-баров. Это один из вариантов решения

P.S. Запусть паралельно еще один поток мне даже не пришло в голову, потому что есть у меня подозрение что если это и даст ускорение, то 20-30% а это меня не устраивало.

P.P.S Если бы мне надо было ускорить выполнение на 2 порядка, то я бы смотрел именно на пакетную обработку, хотя в процедуре проведения сложная логика создания проводок, около 15 insert-ов и select-ов вообще более 30, но только пакетная обработка возможно позволила бы решить такую задачу.

OutcastTo Estets

Вы затронули интересную сторону оптимизации. Не могли бы Вы поподробнее с нею ознакомить (пакетная обработка).
Просто в своей программе мы используем АПИ разработчика БД (около 800 таблиц - биллинг)
Возможно ли в пакетной обработке использовать эти же процедуры АПИ?
Самим же писать низкоуровневую логику обработки запросов...

Если использовать АПИ разработчика, то на мой взгляд проще всего перенести курсор в сервер, на этом можно достаточно сильно оптимизировать время выполнения.

Все остальное уже требует влезание в код разработчика, или написание паралельного кода.Например у нас в процедуре проведения документа проверялся пользователь и его права на выполнение данной операции, хоть это занимало и мало времени, но если умножить время на 10 000 операций то получалось огого. Соответственно проверку прав пользователя вынесли в процедуру с курсором, которая выполняется один раз и вызывает в цикле процедуры проведения уже без проверки.

А вот массовая обработка требует именно "Самим же писать низкоуровневую логику", на свой страх и риск. Например есть процедура которая записывает запись в лог и вызывается для каждого документа.
Если она отрабатывает 0.1 сек то 10 000 * 0.1 = 1.5 мин. А если заменить ее на
То независимо от кодичества документов 1 или 100 000 выполнятся это будет примерно 1 сек.

Если требуется расчеты то ожно почитать советы ASCRUS в "Проектировании БД" о предварительных расчетах агрегатных сумм именно для разрыва линейной зависимости времени расчетов от количества документов.

Но все это достаточно спецефично, и дать общий совет не зная вашей задачи вряд ли у кого получится.

2 Outcast:

Как результаты тестирования?