Там есть NULL'и в данных.. Я проверил... =)

Всё в лучших традициях

Простой тест на пустом Oracle XE:

create table search_test
as
select a.*
    , object_name || owner || object_type || status text1
    , status || object_type || owner || object_name text2
from all_objects a;

— добиваем побольше данных
insert into search_test
select * from search_test
union all select * from search_test
union all select * from search_test
union all select * from search_test
union all select * from search_test
union all select * from search_test
union all select * from search_test;

alter table search_test modify text1 not null;
alter table search_test modify text2 not null;

create index search_test_text_i on search_test upper(text1 || ' - ' || text2);

Без not null:
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2794085565
----------------------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |     1 |    71 |   380   (1)| 00:00:05 |
|   1 |  SORT AGGREGATE    |             |     1 |    71 |            |          |
|*  2 |   TABLE ACCESS FULL| SEARCH_TEST |  2904 |   201K|   380   (1)| 00:00:05 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  2 - filter(UPPER("TEXT1"||' - '||"TEXT2") LIKE '%V$SQL%')

C not null:
SQL> explain plan for
 2  
 2  select count(*)
 3  from search_test t
 4  where upper(text1 || ' - ' || text2) like '%V$SQL%'
 5  /

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2842646172
--------------------------------------------------------------------------------------------
| Id  | Operation             | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                    |     1 |    71 |   183   (1)| 00:00:03 |
|   1 |  SORT AGGREGATE       |                    |     1 |    71 |            |          |
|*  2 |   INDEX FAST FULL SCAN| SEARCH_TEST_TEXT_I |  2904 |   201K|   183   (1)| 00:00:03 |
--------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  2 - filter(UPPER("TEXT1"||' - '||"TEXT2") LIKE '%V$SQL%')

Замените на пробелы, "гулять так гулять"

А вообще потрясите  вендора, чтобы адекватный задаче инструмент использовал
Или миритесь с фулл сканами и тащите таблицу в keep pool или на SSD

В in memory сразу :3

Да, она влезает в память. И итак на SSD. Там всего 15к строк так-то в этой конкретной. Но за счёт того, что таких запросов дохрена, даже при таких размерах создаётся приличный поток логического чтения...

CPU не перегружены ?
Время отклика у пользователей нормальное ?
Если да, то нет особо смысла заморачиваться, просто у вас пару MB "горячих" данных в базе, вот и "греются" логические чтения
Но если никому не мешают, то проблема чисто теоретическая

ну такое себе, добавят там ещё какую ни будь херобору и где то будет не хватать кеша, логическое чтение превратиться в физическое в другом месте

это не сильно прям решает проблему

15k строк - этой какой-то мелкий справочник, погоды в buffer_cache не сделает, ну занимает несколько MB, ну висит в топе LRU, но такими объёмами никого на диск не вытеснишь

ну так вынеси их в питон и там шароебь :)

Я не разраб, мазафака ты глухая.. 🤫

ну так херли ты тогда своими кривыми рученками туда полез?

пусть разрабы и епутся. выкати им тикет

и пусть решают

Я постоянно лазаю своими кривыми ручонками, и оптимизируют то, что можно оптимизировать с нашей стороны..

дай угадаю. потому что твои кривые рученки стоят дешевле чем купить нормальный продукт с нормальной поддержкой?
ну тогда страдай че