Oracle apex интерактивный отчет

Обновлено: 04.07.2024

Сегодня нашей компании исполняется 28 лет, и в честь этого приятного события мы решили поделиться с вами новым материалом.

Благодарим за помощь с переводом нашего постоянного автора Юрия Пономарева OBIEESupport.

Автор статьи – Мишель Скэмин, основатель и управляющий партнер компании, предоставляющей сервис Reading Rewards. В далеком 2009 году Мишель страдала от того, что ее сыновья 8 и 9 лет слишком мало читали. Книги просто не могли конкурировать с компьютером и видеоиграми, поэтому Мишель со своим мужем решили разработать систему, в которой дети зарабатывали время на компьютерные игры, читая книжки.

Будучи IT-консультантом и разработчиком веб-приложений, Мишель разработала софт, позволяющий детям фиксировать время чтения и просмотра телевизора, а родителям – отслеживать это время. Это и стало началом сервиса Reading Rewards.

А теперь, собственно, статья.

Итак, вы выбрали потрясающее приложение Oracle APEX за рекордную быстроту — писать много не придется. И, как гласит старая поговорка, чему быть – того не миновать!

В 2010 году я создала приложение, чтобы попытаться увлечь моих двух маленьких сыновей чтением. Признаюсь, в то время я не думала о производительности, и в нем было несколько сочных «select count(*) from huge table» вроде как стратегически разбросанных по всему коду.

Эй, мои мальчики на самом деле читали не так уж много, так что эти таблицы были довольно маленькими в то время…



Статистика из Google Analytics

Кроме того, что весь этот интерес был для меня очень волнительным, я была совсем не готова к такому количеству переходов. У меня были проблемы с производительностью. Нужно просто признать, что я стала заядлым студентом Oracle APEX performance tuning и думала, что просто поделюсь некоторыми вещами, которые я узнала за эти годы.

Как определить узкое место?

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

Как только вы почувствуете, что ваша базовая инфраструктура находится в хорошем состоянии и не виновата, возможно, пришло время обратить ваше внимание на само приложение, имея в виду ваш фронтенд (Javascript и CSS) и бэкенд (SQL и PL/SQL).

1. Фронтенд: порядок файлов имеет значение

Прежде всего, если вы включаете пользовательские компоненты CSS и JS, убедитесь, что ваш CSS находится в верхней части страницы, а JavaScript — в нижней.

Это гарантирует, что ваши пользователи, по крайней мере, получат компоненты пользовательского интерфейса, даже если некоторые файлы бизнес-логики еще не загружены.

2. Просмотр монитора активности

Это всегда отличное место для начала работы. Если все кажется медленным, и вы не знаете, где искать, монитор активности в среде разработки APEX может дать ценную информацию.



Ссылка на монитор активности из консоли разработки APEX

Каждый просмотр страницы в вашем рабочем пространстве и приложениях регистрируется, включая информацию о пользователе, дате/метке времени, приложении, page_id и, самое главное, о времени работы приложения.

Мой любимый отчет просмотра страниц — «По взвешенной производительности страниц».




Пример представления из монитора активности APEX

Обратите пристальное внимание на любые страницы, которые имеют большое количество Cобытий страницы (имеется в виду, часто посещаемых), и высокое значение среднего времени работы приложения. Я, кажется, помню, как Джоэл Калман однажды сказал, что все, что выше 0,5 секунды, должно быть пересмотрено. Конечно, это довольно грубое обобщение и, может (не) относиться к вашему конкретному случаю использования APEX.

Монитор активности позволяет легко работать с IR, но если вам нужно немного больше деталей и вы хотите запускать отчеты в разных рабочих пространствах, вы можете использовать следующий запрос в SQL Developer, чтобы сделать его максимально детализированным:

Итак, вы, возможно, нашли медленную страницу. И что теперь?

Запуск отчета тогда даст результат:


Одна вещь, которая мне нравится в этой функции, — это не обязательно то, что она определяет, какие регионы требуют много времени для запуска (я могла получить это из моего окна отладки, см. ниже), но она предлагает информацию конечным пользователям.

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

4. Запустите страницу в режиме отладки

Еще лучше, запустите его в Debug LEVEL9, чтобы получить доступ к плану выполнения вашего отчета.

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

5. Остерегайтесь вызова v(”)

Если вы нашли плохо выполняющийся отчет, вы можете проверить, использовали ли вы нотацию v (”), когда вы могли бы использовать переменную bind.


В большой таблице разница между двумя операторами может быть огромной, потому что v (”) на самом деле является вызовом функции. Это означает, что вы не будете использовать преимущества каких-либо индексов, и запрос приведет к полному сканированию таблицы.

Совет: если вам нужно сослаться на состояние сеанса APEX в представлении (где вы не можете использовать переменные привязки), рассмотрите возможность использования скалярного подзапроса, который может отработать почти так же хорошо, как ваша переменная привязки. Смотрите:


Спасибо Джону Скотту за то, что он предложил это на одном из мероприятий, на котором я была.

6. Избегайте подстановки строк в запросах, если это возможно

Остерегайтесь строк подстановки в запросах.

Рассмотрим, например, ситуацию, когда вам может потребоваться оператор decode или case в запросе, чтобы определить, на какую страницу вы хотите ветвиться:


Использование переменной привязки :SESSION, а не строки подстановки &SESSION. может иметь огромное значение и сэкономить Oracle много времени на парсинг. Версия переменной bind позволяет Oracle повторно использовать запрос.


Если вам интересно узнать больше об этом, посмотрите замечательное видео Хорхе Римбласа о строках подстановки, переменных привязки и ссылках APEX.

7. Используйте декларативные параметры в ваших условиях, когда это возможно

При использовании условий на компонентах страницы всегда используйте декларативные параметры, когда это возможно. Они будут гораздо эффективнее.

8. Используйте настройки разбиения отчетов на страницы рационально

В больших отчетах выбранные параметры разбиения на страницы могут оказать существенное влияние. Несмотря на то, что с версии 18.1 APEX значительно улучшил обработку разбиения на страницы (почитайте этот замечательный пост Карстена Чарски), параметр «диапазон строк от X до Y из Z» в одном из них вы можете отключить, если у вас возникли проблемы с производительностью в очень большом отчете.

9. Избегайте HTML в запросах и используйте HTML выражение

Когда это возможно, используйте атрибут выражения HTML для столбцов отчета, чтобы включить в него любые HTML/CSS-атрибуты, которые могут понадобиться.

10. Воспользуйтесь преимуществами кэширования регионов

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

Нужно ли обновлять данные при каждом отдельном просмотре страницы? Подумайте об отчетах панели мониторинга, в частности, данных о продажах и т. д. Даже транзакционные данные, полученные 1 минуту назад, могут быть достаточно полными во многих случаях.

Если это так, вы можете воспользоваться параметром кэширования региона.


Параметры кэша сервера в регионах APEX.

По умолчанию кэширование отключено, но если вы включите его, вы можете выбрать параметр таймаута кэша, начиная всего с 10 секунд. Даже 10 секунд помогут производительности панели мониторинга, которая используется большим количеством пользователей! И очевидно, что увеличение этого параметра поможет еще больше.

Осторожно, если у вас есть конфиденциальные данные, которые зависят от пользователя, вы можете выбрать параметры «кэш по пользователю» или даже «кэш по сеансу».



Доступные настройки при включении кэширования регионов

Если вы решите включить кэширование, вы можете сообщать своим пользователям о последнем обновлении данных. Если это так, вы можете использовать функцию APEX_UTIL.CACHE_GET_DATE_OF_REGION_CACHE.

11. Переместите PL / SQL в пакеты

Убедитесь, что вы переместили код в пакеты. Они уже скомпилированы в базе данных, а значит, будет меньше накладных расходов на динамический анализ.

Ваши страничные процессы должны быть просто вызовами пакетов, когда это возможно.

Стивен Фойерштейн написал очень подробную статью о написании PL/SQL для Oracle Application Express, которую вы, возможно, захотите почитать. Ей уже несколько лет, но она все еще актуальна!

12. Запустите Advisor!

Я нечасто вижу людей, использующих эту замечательную функцию, но это то, что мы все должны делать регулярно. Я каждый раз удивляюсь тому, что еще он находит.

13. Используйте параметры сборки для отключения и включения компонентов

Хорошо, вы перепробовали ВСЕ ЭТИ ВЕЩИ, но все еще застряли непонятно на чем. Если вы собираетесь «перекроить свою страницу заново», то следует рассмотреть возможность использования параметров сборки для различных компонентов вашей страницы.

Не ставьте бессрочные условия на компоненты, иначе вы потеряете все свои драгоценные условия! К тому же, бессрочные компоненты имеют неприятную особенность жить в ваших приложениях вечно…

Создайте новый параметр сборки, используя Status: Exclude.

Примените его поочередно к различным компонентам вашей страницы. Запускайте свою страницу с каждым изменением и смотрите, будет ли она работать лучше. Если ваша страница вдруг работает быстрее, вы, возможно, нашли виновников.

14. Разберитесь в том, как различные настройки IR могут повлиять на производительность APEX

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

Как упоминалось ранее, лучше всего начать с использования режима отладки LEVEL9 и настроить отдельный реальный запрос. Изучите план выполнения, исследуйте индексы, настраивайте там, где это возможно. Помните, что каждое представление (таблица, группировка, диаграмма, сводка) — это отдельный запрос, который может потребовать настройки. Затем он снова изменяется при использовании фильтра поиска или фильтра заголовка столбца!

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

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

Наконец, если вы обнаружите, что ваш IR все еще слишком медленный, вы можете рассмотреть 2 альтернативы:

  1. Конвейерные табличные функции (select * from table (my_rpt_pipelined)) — > они могут работать намного лучше в сложных запросах.
  2. Создание отчета по коллекции (APEX_COLLECTION)

15. Трассировка

Когда все остальное не удается, вы можете добавить "&p_trace=YES " в конец вашего URL-адреса, чтобы создать файл трассировки, который вы сможете проанализировать с помощью утилиты TKPROF.

Дополнительную информацию о трассировке SQL можно найти здесь.


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


1- Введение

В данной статье я покажу вам как работать с Oracle Application Express (Oracle APEX) 5.x:

Вы можете посмотреть руководство по установке и конфигурации Oracle APEX по ссылке:

2- Создать Workspace

Для начала, вм нужно войти в систему управления Oracle APEX чтобы объявить Workspace. Workspace будет прикреплен с SCHEME в database. Workspace содержит Приложения (включая систему форм, отчетов, ..), управляет user тех кто участвует в программировании, или user которые являются пользователями.





Вы можете выбрать SCHEMA имеющийся в Database, здесь я создаю SCHEMA с названием DEV, пароль dev123.


В предыдущем шаге вы создали SCHEMA с названием DEVэто означает создан 1 user database и называетеся DEV.

В этом шаге вам нужно объявить User управляющего Workspace, это не user database, это user управляющий этот APEX Workspace, и имеет право создавать приложения, создавать другие APEX user выполняющие роль программиста, или пользователя приложения, .




Ваш Workspace создан. Вы можете посмотреть список имеющихся Workspace и менять если хотите.

Одним из самых мощных инструментов визуализации данных в Oracle APEX является Interactive Report. Он предоставляет богатые возможности поиска, фильтрации, сортировки и вычисления итогов. Но есть ряд задач, часто возникающих в разработке бизнес-приложений, которые вызывают сложности. В нескольких постах я хочу предложить простой выход из положения.

Первым рассмотрим тривиальный вопрос — вывод итогов по всем данным на каждой странице отчета. При использовании встроенных итогов в IR, итоги выводятся на самой последней странице, если страниц несколько. В реальных приложениях очень часто итоги как раз и будут целью фильтрации и отображения данных — пользователю нужно сначала увидеть общую сумму, а потом уже, если она устраивает, смотреть детализацию. Если после применения фильтра пользователю приходится «отмотать» сначала 10-20 страничек, либо грузить ооочень длинную таблицу — пользователь звереет.

Оптимальным выходом является отображение итогов на каждой странице, но IR не предоставляет такой возможности. Значит, сделаем это сами.

Подробно расскажу, что нам для этого потребуется (на примере для APEX версий <4.2).

1. Начнем с того, что для подсчета итогов нам потребуется запрос. Получить его можно с помощью замечательного пакета APEX_IR_PKG (для версий 4.2 и выше можно воспользоваться встроенным пакетом APEX_IR).

добавить инструкцию для обнуления переменной lv_search

Версию пакета с исправленным багом можно скачать здесь.

2. Теперь мы можем создать процесс, который будет подсчитывать итоги на основе текущего запроса, по которому отображаются данные в IR. Процесс, разумеется, создаем в AJAX Callbacks, on-Demand:

Oracle Apex IR summary

Oracle Apex IR summary

Oracle Apex IR summary

3. Осталась мелочь — после каждого обновления IR асинхронно дергать процесс и выводить сумму в нужное место. Создаем Dynamic Action на Refresh отчета:

Oracle Apex IR summary

Oracle Apex IR summary

Oracle Apex IR summary

Oracle Apex IR summary

Ну вот и все. Теперь в IR на каждой странице будут отображаться итоги.
Пример того, как описанный метод работает, можно посмотреть на демо-странице.

Разумеется, все это можно завернуть в настраиваемый Dynamic Action Plugin (как и было сделано мной в реальном проекте). Вопрос с адаптацией при изменении набора колонок я так же оставлю на «самостоятельное изучение», потому как он решается не сложно, за счет того же пакета APEX_IR_PKG/APEX_IR.
Расширенную версию, на основе плагина, можно увидеть на соседней странице.

Сгенерировал простейший интерактивный отчет на основе запроса

select id,name,name,dat from ttt

Можете использовать Interactive Grid, у него эти возможности уже есть.

Ну или, например, примерно:

В свойствах интерактивного отчета прописываете static id: test
В свойствах последнего столбца добавляете ид, который нужен, в html expression:

в свойствах страницы:

Execute when Page Loads

в свойство css > inline:

Не слетало при фильтрах=. Весь код выше. Для submit-та нужно еще дописать выделение при загрузке из item. Тогда немного лучше переписать, примерно ниже.

+ Поставить галку, чтобы нельзя было прятать этот столбец

Последнюю версию кода не проверял, но должен работать, если надо потом проверю.
Можете дописать еще к css:

Если что, смотрите яваскрипт ошибки.

Проблемы:
1. При нажатии на другую строчку отметка с первой строчки не пропадает( В итоге все строчки отчета "закрашиваются" (

т.е. если нажать на ту же строчку, выделение должно сохраниться ?
Попробуйте:

Именно Tabular Form, не Interactive Grid ?
Проверьте, чтобы шаблон региона был стандартный, не no template
+ проверьте, что у Tabular Form включен Partial Page Refresh.

Если это IG, почему-то для него стандартный код с apexrefresh не работает (баг ?)
тогда замените строчку

Шаблон региона стандартный - Report
Включен Partial Page Refresh.

Для Tabular работают обе команды. Посмотрите в интрументах браузера, вкладка сеть, при выполнении этих команд в консоли появляется ли новая строчка с запросом к серверу. Иногда, бывает, что refresh работает, но это не заметно. Если запрос к серверу есть, тогда проблема на стороне Page Items to Submit и SQL.

автор
У меня есть подозрение что Page Items to Submit могли заполнить неверно, или static id заполнили какой-то другой неправильный идентификатор.

Просто это поле item выбранное из списка.
static id - тоже примитивный.
Эта страница разрабатывалась еще в 4.2.1 , может в этом дело
Пока добавил жесткий submit после каждого клика - выглядит хуже зато работает.
Попробую на чистых 5.1.1 страницах сначала.
Кстати наше бажок

Если запрос на сервер идет, значит дело в sql: запрос возвращает те же данные. Это может быть, например, следствием того, что не перечислен нужный item в page item to submit, или он null.

По поводу gt(0), там может быть html разным в зависимости от того, включена ли внутренняя опция fixed header, так что зависит от этого.

Читайте также: