Столкнулся со странной проблемой, когда разбирался почему тормозит IR отчёт.
Возможно, даже проблема, не связана с apex'ом. Итак апекс 5.1.4.00.08, ords 17.4.1.353.06.48
(standalone + nginx), oracle EE 12.2.0.1. Запустил в апексе дебаг, который показал мне следующую
странную строчку:



Т.е. якобы на бинд переменной APXWS_MAX_ROW_CNT он потратил 12 секунд, когда запрос в plsql девелопере
выполняется за 4 секунды. Это мне показалось очень странным. Дальше из представления apex_application_page_regions
выдернул текст запроса, затем с помощью apex_ir.get_report получил коллекцию с переменными и их значениями.

И вот теперь САМОЕ интересное: решил через dbms_sql выполнить данный запрос, обернув сверху надзапросом с
агрегатной функцией sum, просто чтобы была в итоге одна запись и запрос также повис на теже 12 секунд на fetch_rows.

Когда переписал запрос без dbms_sql на execute immediate без using с указанием явных литералов, то он выполнился
как и ожидалось за 2-3 секунды.

Есть у кого-нибудь идеи, что почему такое происходит и как исправить?

Nickname,

Само собой я отфетчил все записи

Сегодня опять добрался до данного вопроса.

И действительно посмотрев на планы запросов увидел, что в случае с
использованием DBMS_SQL план запроса немного отличается - я получаю
full к одной таблице. Запрос делается из представления с кучей юнионов по
дате.

Запрос мой в апексе выглядит следующим образом:



и тут интересно вот что, в плане такого запроса я получаю FULL к одной
из таблиц представления и соответственно запрос выполняется долго.
Если вместо переменной :P3_DATE явно указать значение, например,
написать

, то дата проталкивается внутрь и по всем таблицам представления используются
индексы по дате.

Вот как-то так, теперь думаю как лучше решить данную проблему.

Теперь, я понимаю, что тема не по апексу в итоге вышла.

Но вот что я в итоге нарыл. Про хинты индекс я их сразу воткнул, как только увидел full к таблице.

Но теперь проблема более или менее сузилась: в представлении был юнион с другой вьюшкой, которая
всё портила. Проблемная вьюшка сделана на инмемори таблице с анпивотом и группировками. Путём
экспериментов выяснилось, что если запрос к этой таблице делать через dbms_sql, где я биндил один
обязательный параметр - дату и несколько необязательных, то запрос выполняется очень долго около
11 сек против 1-2с в обычном случае. Так вот когда я биндю одну обязательную переменную, то запрос
выполняется быстро, но как только появляется хоть одна другая переменная - запрос выполняется долго.

Кто что может подсказать куда копать?

Дальше больше теперь нашёл проблему ещё более чётко.

Во фразе where используется думаю, знакомая многим апексоводам конструкция, наподобии


, так вот если писать не так, а так


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


а затем уже внутри него ограничивать остальные столбцы.

Или инмемори так не работают как я ожидал? Какие будут предложения?