AFAIK Ограничить можно через Oracle Database Resource Manager

но он сможет или прерывать выполнение запроса или понижать его приоритет

p.s. Что такое "TFS", который не заканчивается, - я не знаю )))
p.p.s. Попытка лечить следствия, а не причину. Нужно обсуждать какие реальные (а не выдуманные анал итиками) бизнес задачи есть, их реализовывать, создавать индексы (возможно переделывать структуру таблицы или делать matview) для реально требуемых по бизнесу запросов.

Oracle и так возврашает данные в тот момент, когда они готовы в процессе fetch'а.

Т.ч. проблема НЕ сервера, а клиента. Пусть он уже готовые/зафетченные данные показывает сразу, не ожидая получения всего результата запроса

Например Allround Automation PL/SQL Developer ровно так и работает. Показывает начало(готовые данные), а остаток запрашивает/показывает по мере нажатия кнопочек (fetch next, fetch all) пользователем. Если за минуту ничего не показывается, то значит, что за минуту ничего и не найдено

IMHO & AFAIK

p.s. пока все выглядит как надуманная проблема

Самое просто - на клиенте.

В Allround Automation PL/SQL Developer - кнопочка "Break (Shift+ESC)" иконка в виде молнии )))

Что бы не очень усердствовал и не мешал остальным - Oracle Database Resource Manager. Понижение приоритета, в т.ч. вплоть до убийства запроса на стороне сервера.

Но сама по себе Ваша постановка задачи не корректная:
1. Прервать выполнение по своему желанию и вместо корректного ответа выдать неконсистентные данные (т.е. просто "ЧУШЬ") - Oracle так не умеет, это не РосСтат. Oracle пытается выдать единственный и правильный (с его точки зрения ответ). Поговорка "есть правда, есть лож, а есть статистика" это не про него.
2. Если Вы выполняете реально осмысленную бизнес задачу и не можете дождаться ответа - то нужно эскалировать проблему выше. Менять структуру данных, технику, используемый инструмент.

Это, к сожалению, не конкретика.

Нужно понимать изначальную задачу, структура таблиц, план.

сортируется по индексу в порядке убывания
Само по себе OK, но есть "нюансы" ( C ) Чапаев
далее применяется неиндексируемое условие поиска
Т.е. индекс НЕ подходит для данной задачи/запроса.
сотне миллионов
Если доступ по индексу, то это НЕ FTS.

И тут может быть все значительно хуже.

( описываю своими словами, далеко от действительности, но аналогии думаю более-менее верные )

Данные в базе могут лежат фрагментированно. Поэтому вместо последовательной вычитки большого блока, Oracle может делать "сотню миллионов" обращений по одному блоку (в худшем случае). Соответственно производительность падает ниже плинтуса.

На одном из проектов (legacy система, Oracle CC&B, изменить структуру не могли) пришлось делать "сверх широкий" индекс, куда вставлять все поля из SELECT'а. Запрос стал выполняться ТОЛЬКО на индексе, который хранится более-менее упорядоченно, скорость возрасла на порядки (вместо 2-3 минут открытия экрана, стало < 15 секунд).

Разумеется возрос объем и должна была упасть скорость вставки в данную таблицу. Но по крайне мере система хоть как-то заработала.

Более правильный подход в нашем случае (запрос пытался вычислить текущую задолжность по account'у), был бы агригировать данные и не пытаться их расчитывать при входе на форму, но менять legacy код настолько серьезно мы не могли (не умели).

Что бы возвращались First Rows, то, насколько я понимаю, в плане не должно быть сортировки (можно попытаться избежать за счет прохода по индексу), в плане должен быть Nested Loops.

Что бы было максимально быстро, пытаться исключить доступ к таблицам. Как минимум, что бы доступа к t_log не было вообще (только Index Full Scan)

Ну и партиционирование, обработка запросов в несколько потоков.

IMHO & AFAIK

p.s. постановка задачи "ищем по like сами незнаем что, лишь бы что-то нашлось". Очень напомнило ТЗ на "секретную" систему мониторинга трафика ФСО. Когда трафик свален в таблицы, но никаких адекватных критериев поиска по ним не сформулировано. И (не знаю как называется должность) кто-то эти таблицы смотрит в PL/SQL Developer'е пытаясь "уязвимости" обнаружить )))
p.p.s. По нормальному, нужно в отдельную таблицу ключевые слова типа Навальный, Соболь и прочее выносить и триггером или job'ом сразу и проверять ))) ни оператор ни аналитик тут не нужен. Агенты ЦРУ и так всем известны.

Смотреть план запроса.

С учетом "не заканчивается до победного конца" и "в таком виде заработало" не удивлюсь, если в исходном запросе Hash Join образовался.