TheRonCronix

На вскидку FIRST_VALUE.
Что нужно понять - как хочется выстроить зависимость между строками: как разбить на группы и какое значение взять в каждой из групп. Ведь таблица - это по-умолчанию неупорядоченое множество.

1. Может быть bloating таблицы из-за изменений/удалений/втавок. Давно ли делался VACUUM, настроен ли AUTOVACUUM ?
2. Для выборки малого количества строк из таблицы полезно создать b-tree index на поле, по которому происходит фильтрация.
3. Выполняется ли периодический сбор статистики на таблице командой ANALYZE ( по плану отфильтровано 3586078 строк а выбрано ~3000, а выпишете о 10 млн) ? Неверная статистика - прямой путь к неоптимальному плану выполнения.

Как вы указали listagg не подойдет из-за большой длины списка значений. По сути логика за этим такая: нет смысла показывать пользователю гигантский список значений. Обычно я делал неполный вывод с <...> в конце, если все значения не уместились в список (listagg тут не подойдет, нужна хранимка). При этом в список можно провалиться и получить уже полный список с постраничным разбиением в виде таблицы.
Если речь про автоматическую обработку приложением, то агрегация на стороне сервера, наверно, не подойдет в качестве решения. Также можно посмотреть в сторону XMLAGG или может быть уже что-то для json есть.

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

Функцией substr

Как вариант:

select distinct DocumentNodeValue, DocumentTemplateName, PatientName, d1.DocumentID, d2.DocumentID
from
(
select DocumentNodeValue, DocumentTemplateName, PatientName, d1.DocumentID, d2.DocumentID, count(*) over(partition by DocumentNodeValue) as repeatitions
from
Patient
join Course on PatientRef = PatientID
join Document d1 on CourseRef = CourseID
join Document d2 on d1.DocumentID = d2.DocumentID
join DocumentTemplate on d1.DocumentTemplateRef = DocumentTemplateID
join DocumentNode on DocumentRef = d1.DocumentID
) as tt
where tt.repeatitions > 1;

Логика такая: разбить весь массив строк на группы по значениям из DocumentNodeValue. В каждой из групп посчитать количество строк. Выдать все строки из массива с подсчитанным количеством. Взять только строки попавшие в группы, в которых насчитано более 1 строки. + distinct на ваше усмотрение.

Посчитать можно, для этого придется пройтись по всем строкам таблицы и для каждой из точек высчитать расстояние до вашей точки, а потом отсортировать. Но, если нужно выбрать лишь несколько ближайших точек или просто точки не слишком удаленные от заданной, то можно воспользоваться техникой bounding-box: представить, что вокруг точки куб или квадрат заданного размера и провести вычисление сначала в границах куба. Это позволит хоть как-то задействовать индексы.

В приведенных примерах никакой разницы нет.

Посмотрите про подключение volume (аргумент -v вроде бы при запуске командой docker run). Иначе данные у вас удалятся по завршении контейнера.
А путь в образе к приложению может отличаться от стандартного, к которому вы привыкли.

Как вариант, если известен размер всех переменных сразу, выделять на них всех память единоразово. И освобождать соответсвенно так же. Или, если известна максимальная длина массива, то выделять опять же n*max_len за один раз.

Даю идею (синтаксис не проверял):

select mod(rn, N) part_number,
t1.*
from
(
select t.*,
row_number() over() rn
from table as t
) as t1

N - кол-во частей, table - ваша таблица.

В oracle есть b-tree индексы, bitmap-индексы, и еще спецефические (fulltext search помоему, индекс на структурированный xml и может быть еще что-то).
b-tree это сбалансированное дерево высотой обычно не более 5 уровней с логарифмической скоростью доступа. Такой индекс хорош для поиска специфической строки в большой таблице или выборки небольшого объема данных с хорошей селективностью (не слишком много строк в таблице с искомым значением) из таблицы. Область применения - OLTP нагрузки и в DWH тоже полезен.
bitmap-индекс представляет собой таблицу, у которой в заголовках столбцов искомые значения, взятые из индексируемых столбцов индексируемой таблицы, а каждая строка представляет битовую маску: если значение в индексируемой таблице есть, то 1, иначе 0. Каждая строка в битмап-таблице соответсвует одной строке в индексируемой таблице. Такой индекс используется в основном в DWH для поиска по условиям вида (t.col1 = 'A' or t.col2 = 'B') and t.col3 = 'C'. Из такого условия легко собрать битовую маску и пройтись по битмап-индексу.
Можно также заметить, что если бы мы искали по b-tree индексу с условием or нам бы пришлось искать два раза. В то же время, b-tree позволяет искать по условию с неравенством t.col1 > 123 and t.col2 < 234, т.к. дерево отсортировано.

СУБД рассчитаны на то, чтобы не зависеть от клиентского приложения. В большинстве случаев, если не пул соединений используется, то под каждого клиента создается свой процесс. Можно легко завесить свой клиентский процесс, но не чужие. Однако, можно попробовать замедлить работу СУБД, влияя на разделяемые ресуры, например, вытеснить из кэша разобранные запросы путем генерации множетсва отличающихся запросов. Не факт, что сработает. Или блокировать доступ к таблице или процедуре путем ее перекомпиляции. Чтобы СУБД реально зависла, для этого нужен баг в СУБД. Но такие ситуации очень индивидуальны. На моей практике был только один такой случай, когда запрос ронял всю СУБД.
Темой атак на СУБД я не занимался, но вопрос задали интересный.

Детекция аномалий в логах аудита на предмет несанкционированного доступа.

В цикле от 1 до 5:
{
Выбирите индекс с случайным значением от 0 до shops.length-1.
Выберите значение из shops по этому индексу и сохраните/выведите куда-либо кда вам надо.
Удалите выбранный элемент из shops.
}

Идея следующая.
1. Обычно, полигон, если он не выпуклый, разбивают на выпуклые (на треугольники, проще говоря). Далее, любой полигон может быть представлен как пересечение трех и более полуплоскостей (смотря соклько сторон у вашего полигона).
2. Вы можете вычислить отношение точки к направленному вектору, т.е. с какой стороны полуплоскости лежит точка: слева или справа, с учетом напрвления вектора, делящего плоскость на две полуплоскости. Т.к. полигон это пересечение полуплоскостей, то определить, попадает ли в него точка, можно убедившись, что точка лежит во всех полуплоскостях образующих полигон.
3. Согласно вышесказанному, мы можем написать функцию, которая определяет, что точка лежит справа от вектора, образующего полуплоскость. Мы представим грани полигона векторами и будем обходить полигон по часовой стрелке, так что "справа от вектора" - это всегда полуплоскость, которая "внутри полигона". Пройдясь по всем граням-векторам и убедившись, что точка лежит "справа" от них всех, мы сделаем вывод, что точка лежит внутри полигона.
4. Отношение "справа/слева" вычисляется векторным произведением (если мне помять не изменяет).