Добрый день, Коллеги

Вопрос новичка. Видел обсуждение проблем подобных моей в.т.ч на этом форуме, но решения для себя пока не нашел. Если что-то посмотреть ,пожалуйста не кидайте тапками ))

Требуется создать IR, фильтрация ряда заголовков которого осуществляется выбором значений из LOV . Последний делает выборку из табицы с сотрудниками (10k-20k записей) и отпрабатыввает достаточно долго (~30 сек).

Сам запрос



Колонки в условии запроса проиндексированы. Притом cost sql-запроса LOV 280 и БД отрабатывать его должна быстро, учитывая , что бд крутится на достаточно производительном железном сервере.

скрин debug-а приложен

Проблема актуальна для Apex5.0.1+ORDS+Tomcat7+RHEL , для Apex4.2+PL/SQL Gateway+OEL
Замечено, что включение на томкате компрессии трафика уменьшает время отработки тяжелых LOV на 20-30%. Увеличение или уменьшение объема возвращаемых данных (меньше кол-во строк, возвращать логин, а не фио), пропорционально уменьшают время отрабатывания

Может быть вы знаете варианты, как заставить LOV выводить список сотрудников за приемлемое время (не более нескольких секунд)? Или чтоб он начинал искать после пары введенных букв?

Это может только означать, что в основном запросе у вас уже выводится ФИО, тогда зачем использовать ЛОВ?
Совершенно верно. В таблице, по которой строится отчет, более миллиона записей. Понятно, что колличество выводимых строк должно усекаться.
Если искать по значениям в столбце, то это
а) может быть долго
б) установлено ограничение на кол-во выводимых в отчет строк. Если не вешать на столбец отчета лов, то , судя по дебаг-логам, в условие запроса дописывается


, а это значит, что я скорее всего не увижу всех значений


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

blkangel,

Благодарю за советы
С производительностью самих sql-запросов сложностей нет. FULL_NAME is not null - это даже излишнее, безумянных людей ведь нет )
Кроме того, быстро работает отовсюду (при запросах из локально запущенного Toad, при перекачке данных с помощью Pentaho)

авторМожет стоит сделать деструктив, и вынести фильтр по сотрудникам как отдельный элемент.
Возможно, к этому и придет. Просто тормоза из-за объема данных проявляются и в др. местах (напр. выгрузка в xls используя плагин Interactive Report to MSExcel ). Надеялся, что есть возможность поправить все разом

Petro123,
авторкак и где он у тебя исп-тся. дай скрин.
Сорри, не понял скрин чего надо сделать? "исп-тся" - имеется в виду испортился?

Курдль,

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

Есть таблица с заявками (инциденты, Trouble tickets , обращения - кому как удобнее). Соотв. у заявок есть атрибуты "инициатор", "исполнитель" и.т.д.
Очень часто хотят делать выгрузки заявок, например, по исполнителю за год. Или по любому другому набору условий, возвращающим относительно небольшое кол-во записей. Т.е. пытаюсь сделать не систему отчетов расчетом KPI , агрегатов и проч. , а простой , но удобный для простого пользователя интерфейс для работы с сырыми данными.

Petro123,
На столбце инициатор висит лов , выполняющий



Несмотря на то, что кост этого запроса на порядок больше, чем у приведенного в 1м сообщении, в гуи он работает быстрее за счет того, что возвращается 10к, а не 20к строк.

Курдль,

авторExcel? :)
Кстати , иногда просят выгрузить табличку с сотней тысяч строк, а юзеры уже сами играют :(. От этого и хочу уйти

авторгде данные о сотрудниках содержатся только в миллионной таблице с инцидентам.
Смотри , в приведенном примере есть 2 таблицы HD_Tasks (заявки, млн строк), S_People (сотрудники 20к строк)
Создаю IR который делает выборку из HD_Tasks
Создаю LOV который смотрит на S_People и прикрепляю его к колонкам IR , в которых фигурируют сотрудники. Проблема в том, что сотрудников заведено много и штатный LOV достаточно медленно работает с их списком

авторМы множество постов обсуждаем подход к выборке данных, а на модель никто даже не удосужился взглянуть.
Я недавно на форуме. Не подскажешь, как найти обсуждение?

Petro123,
Petro123если без LOV а сразу JOIN?
Оставить тип колонки "plain text" , а тип фильтрации "Use Define List of velues ..." и вставить туда запрос из LOV ?
Попробовал -так же медленно...

Petro123,

Похоже, мы не понимаем друг дружку ((
Petro123Но никогда в голову не приходило хотеть увидеть все из БД.

Допустим, надо увидеть заявки определенного человека. Из-за ограничения кол-ва строк (вывожу 1k из 1млн) ни одна из его заявок не попала в текущее отображение отчета. Это значит , если не вешать LOV и для фильтрации использовать текущие значения (Filter type = Default based on column type), то я никогда не увижу ФИО этого сотрудника в списке выбора для фильтрации.
Выход , как его вижу - отображать весь список сотрудников

смог ли я прояснить ситуацию?

Petro123,
Petro123select2
Видел этот плагин - выглядит симпатично. Возможно на него придется переделать фильтрацию. Но, как сказал blkangel , выносить фильтр по каждому атрибуту в отдельный элемент интерфейса - это диструктив.

Кстати, не подскажете , чем отличаются атрибуты столбцов
Вроде делают одно и то же, но запросы к базе , на основании которых строятся IR, получаются принципиально разные