Справедливое замечание, из соображений бережливости (экономии ЦПУ?).

С другой стороны, Оракл придумал/внедрил целую библиотеку для того, чтоб PL/SQL мог общаться с веб сайтами.
https://docs.oracle.com/database/121/ARPLS/u_http.htm#ARPLS70954

Если использование встроенных функций оракла для доступа к интернету считается плохим тоном, как принято это делать, учитывая что задача должна инициироваться по SQL запросу? подать сигнал на на обновление внешнему (не-Оракл) скрипту через виртуальную колонку?

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

В 22196853 я изложил как я понимаю исполнение параллельных подзапросов в Оракле (когда они включены, для педантов :))
Для человека с практическим опытом было бы легко указать ошибку, тем самым улучшив не только мое понимание, но один из немногочисленных русскоязычных ресурсов по SQL.

Если вы здесь с другой целью, то с какой?

Андрей Панфилов,

Спасибо, я понял про внешние таблицы, я такую недавно использовал чтобы прочитать директорию на сервере,
но потом все-таки переделал на "родную" джава-функцию, для простоты. Директорию читать из Оракла наверное можно, это как одну картофелину в S-классе перевезти.

Я в целом понял что если задача посложнее, и для Оракла непрофильная, то лучше ее разгрузить в другое место (возможно, и другой хост через ssh), и общаться через external table, как в вашем примере. Почитаю, в какой сессии исполняются действию для таких таблиц.

xtender,

Увы, параллельное исполнение мне пока недоступно (версия 11.2).

Документация доступна. Давайте, вы мне немного поможете там, где можно обойтись без терминов.




Мое понимание параллельности подзапросов было такое:
- оракл запускает несколько запросов одновременно. Для примера, три подзапроса А,Б,В все начались в пределах 10-миллисекунд.
- Подзапрос А продолжался 10 секунд, подзапрос Б 5 секунд, подзапрос В - 7 секунд. Порядок завершения: Б,В,А
- учитывая что задана сортировка через order by, результаты Б и В будут сидеть в памяти пока запрос А не завершится.
- когда запрос А завершится, результат будет отсортирован и выдан в порядке А,Б,В (это исходное условие).
- Параллелизм позволяет такую задачу решить за 10 секунд, вместо 22 секунд при последовательном исполнении.

Идентичная параллельная задача на другом языке. Исполняется параллельно, соответствует описанию выше. Терминов не требует, хотя при желании можно долго и нудно рассказывать про методы синхронизации исполнения на уровне 0 для многоядерных процессоров :)




Подзапросы стартанули "одновременно" (очередно, но в пределах малого промежутка времени), самый долгий занял 10 секунд, поэтому весь запрос занял 10 секунд, но строки вернулись не в порядке запуска запросов, а в каком-то другом. Скорее всего в порядке завершения запросов, но и это Оракл вроде не гарантирует.

Где-то есть ошибка? Если есть, скажите, пожалуйста, в какой строчке.

Я ранее упомянул, что нашел-таки решение без "бейсика", но оно не изящнее, хоть и отвечает всем моим требованиям.

Прошу не пинать, это в товарный код не идет, упражнение для моего образования - на что способен SQL

Это как раз один из сценариев, для которых Оракл ввел параллелизм в 12й версии.
Подробнее об этом можно прочитать здесь:
https://docs.oracle.com/database/121/VLDBG/GUID-1F4C90F9-3EF5-423A-B55B-2593FB3F1433.htm

Если вы только присоединяетесь к теме: до разрешения параллелизма Оракл гарантировал результат UNION ALL в том же порядке, как селекты написаны в коде запроса - это удобно тогда, когда нет удобного ключа сортировки.
При параллельном исполнении селектов порядок нарушался, и для его восстановления требуется order by.
Вопрос темы заключался в том, как избежать ручной нумерации строк а-ля бэйсик (10, 20, 30, 35, ..).

В PL/SQL есть встроенное макро $$PLSQL_LINE, которое дает номер строки исходника, и оно для этой цели просто идеально.
Я извернулся и написал свою функцию QueryLine() которая возвращает номер строки, но она требует GUID, что не так элегантно.
Зато теперь результаты параллельных селектов возвращаются в том же порядке, что написаны, и если мне нужно передвинуть строчки вверх-вниз в огромном селекте, мне не нужно помнить каждый раз менять ручную нумерацию.

Так вот же :)



Решение с гуидами не требует ручной перенумерации (параллельные подзапросы вернутся в порядке как записаны, и строчки можно свободно двигать внутри UNION ALL), но выглядит громоздко, не говоря уже о внутренностях функции QueryLine, которая ковыряется в блобах исходного кода.

Сугубо прикладную - улучшить понимание нового для меня языка и его возможностей.
Поэтому примеры не затасканные из учебника, а необычные, требующие живого мышления.
В рабочем коде все будет скучно и просто, с комментариями и без экзотики.

Браузер в Оракле? Нечем рендерить, поэтому вряд ли, да и задача большая, не для примера.
А вот забацать простой стрим крипто на SQL - это стОящий челлендж. Но поскольку
вряд ли крипто специалисты будут тут слоняться, это прикол для другого форума.

Солнышко светит, травка растет. Кто легче характером, тот дольше живет :)

Спасибо, посмотрю.