Всем горячий хабрапривет!
Сегодня нашей компании исполняется 28 лет, и в честь этого приятного события мы решили поделиться с вами новым материалом.
Благодарим за помощь с переводом нашего постоянного автора Юрия Пономарева OBIEESupport.
Автор статьи – Мишель Скэмин, основатель и управляющий партнер компании, предоставляющей сервис Reading Rewards. В далеком 2009 году Мишель страдала от того, что ее сыновья 8 и 9 лет слишком мало читали. Книги просто не могли конкурировать с компьютером и видеоиграми, поэтому Мишель со своим мужем решили разработать систему, в которой дети зарабатывали время на компьютерные игры, читая книжки.
Будучи IT-консультантом и разработчиком веб-приложений, Мишель разработала софт, позволяющий детям фиксировать время чтения и просмотра телевизора, а родителям – отслеживать это время. Это и стало началом сервиса Reading Rewards.
А теперь, собственно, статья.
Итак, вы выбрали потрясающее приложение Oracle APEX за рекордную быстроту — писать много не придется. И, как гласит старая поговорка, чему быть – того не миновать!
В 2010 году я создала приложение, чтобы попытаться увлечь моих двух маленьких сыновей чтением. Признаюсь, в то время я не думала о производительности, и в нем было несколько сочных «select count(*) from huge table» вроде как стратегически разбросанных по всему коду.
Эй, мои мальчики на самом деле читали не так уж много, так что эти таблицы были довольно маленькими в то время…
Давайте просто скажем, что я была довольно наивна, когда выпустила приложение на публику, и никак не ожидала, что нагрузка на него составит тысячи пользователей ежедневно, генерируя 150 000 просмотров страниц в день.
Статистика из Google Analytics
Кроме того, что весь этот интерес был для меня очень волнительным, я была совсем не готова к такому количеству переходов. У меня были проблемы с производительностью. Нужно просто признать, что я стала заядлым студентом Oracle APEX performance tuning и думала, что просто поделюсь некоторыми вещами, которые я узнала за эти годы.
Есть много вещей, на которые вы захотите обратить внимание при оценке производительности вашего приложения. Вы захотите рассмотреть проблемы, связанные с нею, браузере. Сетевые проблемы. Конфигурация ORDS. Конфигурацию базы данных, включая возможные отсутствующие индексы. Есть ли какие-либо блокировки базы данных в игре? Ожидания?
Как только вы почувствуете, что ваша базовая инфраструктура находится в хорошем состоянии и не виновата, возможно, пришло время обратить ваше внимание на само приложение, имея в виду ваш фронтенд (Javascript и CSS) и бэкенд (SQL и PL/SQL).
Прежде всего, если вы включаете пользовательские компоненты CSS и JS, убедитесь, что ваш CSS находится в верхней части страницы, а JavaScript — в нижней.
Это гарантирует, что ваши пользователи, по крайней мере, получат компоненты пользовательского интерфейса, даже если некоторые файлы бизнес-логики еще не загружены.
Это всегда отличное место для начала работы. Если все кажется медленным, и вы не знаете, где искать, монитор активности в среде разработки APEX может дать ценную информацию.
Ссылка на монитор активности из консоли разработки APEX
Каждый просмотр страницы в вашем рабочем пространстве и приложениях регистрируется, включая информацию о пользователе, дате/метке времени, приложении, page_id и, самое главное, о времени работы приложения.
Мой любимый отчет просмотра страниц — «По взвешенной производительности страниц».
Пример представления из монитора активности APEX
Обратите пристальное внимание на любые страницы, которые имеют большое количество Cобытий страницы (имеется в виду, часто посещаемых), и высокое значение среднего времени работы приложения. Я, кажется, помню, как Джоэл Калман однажды сказал, что все, что выше 0,5 секунды, должно быть пересмотрено. Конечно, это довольно грубое обобщение и, может (не) относиться к вашему конкретному случаю использования APEX.
Монитор активности позволяет легко работать с IR, но если вам нужно немного больше деталей и вы хотите запускать отчеты в разных рабочих пространствах, вы можете использовать следующий запрос в SQL Developer, чтобы сделать его максимально детализированным:
Итак, вы, возможно, нашли медленную страницу. И что теперь?
Ну, вы можете использовать переменную подстановки #TIMING# в нижнем колонтитуле ваших регионов отчета, если хотите получить и отобразить их истекшее время. Это может помочь вам определить наиболее медленные области отчета на странице, на которые вы можете обратить свое внимание. Это особенно полезно на страницах панели мониторинга, где у вас может быть много работы.
Использование строки подстановки #TIMING# в нижнем колонтитуле отчета
Запуск отчета тогда даст результат:
Одна вещь, которая мне нравится в этой функции, — это не обязательно то, что она определяет, какие регионы требуют много времени для запуска (я могла получить это из моего окна отладки, см. ниже), но она предлагает информацию конечным пользователям.
Часто я обнаруживаю, что они будут запрашивать данные, которые, как я знаю, будут визуализироваться целую вечность. По крайней мере, это дает им некоторое представление о том, что может происходить и почему им пришлось ждать свою страницу немного дольше, чем ожидалось.
Еще лучше, запустите его в Debug LEVEL9, чтобы получить доступ к плану выполнения вашего отчета.
Окно отладки покажет вам все, что происходит на вашей странице, и покажет время выполнения для каждого компонента. LEVEL9 будет генерировать тонны строк, но вы можете сортировать их по убыванию затраченного времени, чтобы показать, что на вашей странице занимает больше всего времени для визуализации.
Если вы нашли плохо выполняющийся отчет, вы можете проверить, использовали ли вы нотацию v (”), когда вы могли бы использовать переменную bind.
или
В большой таблице разница между двумя операторами может быть огромной, потому что v (”) на самом деле является вызовом функции. Это означает, что вы не будете использовать преимущества каких-либо индексов, и запрос приведет к полному сканированию таблицы.
Совет: если вам нужно сослаться на состояние сеанса APEX в представлении (где вы не можете использовать переменные привязки), рассмотрите возможность использования скалярного подзапроса, который может отработать почти так же хорошо, как ваша переменная привязки. Смотрите:
Спасибо Джону Скотту за то, что он предложил это на одном из мероприятий, на котором я была.
Остерегайтесь строк подстановки в запросах.
Рассмотрим, например, ситуацию, когда вам может потребоваться оператор decode или case в запросе, чтобы определить, на какую страницу вы хотите ветвиться:
Использование переменной привязки :SESSION, а не строки подстановки &SESSION. может иметь огромное значение и сэкономить Oracle много времени на парсинг. Версия переменной bind позволяет Oracle повторно использовать запрос.
Если вам интересно узнать больше об этом, посмотрите замечательное видео Хорхе Римбласа о строках подстановки, переменных привязки и ссылках APEX.
При использовании условий на компонентах страницы всегда используйте декларативные параметры, когда это возможно. Они будут гораздо эффективнее.
В больших отчетах выбранные параметры разбиения на страницы могут оказать существенное влияние. Несмотря на то, что с версии 18.1 APEX значительно улучшил обработку разбиения на страницы (почитайте этот замечательный пост Карстена Чарски), параметр «диапазон строк от X до Y из Z» в одном из них вы можете отключить, если у вас возникли проблемы с производительностью в очень большом отчете.
Когда это возможно, используйте атрибут выражения HTML для столбцов отчета, чтобы включить в него любые HTML/CSS-атрибуты, которые могут понадобиться.
Таким образом, вы определили действительно медленную область отчета, которую вы настроили как можно лучше.
Нужно ли обновлять данные при каждом отдельном просмотре страницы? Подумайте об отчетах панели мониторинга, в частности, данных о продажах и т. д. Даже транзакционные данные, полученные 1 минуту назад, могут быть достаточно полными во многих случаях.
Если это так, вы можете воспользоваться параметром кэширования региона.
Параметры кэша сервера в регионах APEX.
По умолчанию кэширование отключено, но если вы включите его, вы можете выбрать параметр таймаута кэша, начиная всего с 10 секунд. Даже 10 секунд помогут производительности панели мониторинга, которая используется большим количеством пользователей! И очевидно, что увеличение этого параметра поможет еще больше.
Осторожно, если у вас есть конфиденциальные данные, которые зависят от пользователя, вы можете выбрать параметры «кэш по пользователю» или даже «кэш по сеансу».
Доступные настройки при включении кэширования регионов
Если вы решите включить кэширование, вы можете сообщать своим пользователям о последнем обновлении данных. Если это так, вы можете использовать функцию APEX_UTIL.CACHE_GET_DATE_OF_REGION_CACHE.
Убедитесь, что вы переместили код в пакеты. Они уже скомпилированы в базе данных, а значит, будет меньше накладных расходов на динамический анализ.
Ваши страничные процессы должны быть просто вызовами пакетов, когда это возможно.
Стивен Фойерштейн написал очень подробную статью о написании PL/SQL для Oracle Application Express, которую вы, возможно, захотите почитать. Ей уже несколько лет, но она все еще актуальна!
Я нечасто вижу людей, использующих эту замечательную функцию, но это то, что мы все должны делать регулярно. Я каждый раз удивляюсь тому, что еще он находит.
Хорошо, вы перепробовали ВСЕ ЭТИ ВЕЩИ, но все еще застряли непонятно на чем. Если вы собираетесь «перекроить свою страницу заново», то следует рассмотреть возможность использования параметров сборки для различных компонентов вашей страницы.
Не ставьте бессрочные условия на компоненты, иначе вы потеряете все свои драгоценные условия! К тому же, бессрочные компоненты имеют неприятную особенность жить в ваших приложениях вечно…
Создайте новый параметр сборки, используя Status: Exclude.
Примените его поочередно к различным компонентам вашей страницы. Запускайте свою страницу с каждым изменением и смотрите, будет ли она работать лучше. Если ваша страница вдруг работает быстрее, вы, возможно, нашли виновников.
С плохо выполняемым интерактивным отчетом различные настройки, параметры или фильтры, применяемые вашими пользователями, могут усилить плохую работу (да, это действительно так).
Как упоминалось ранее, лучше всего начать с использования режима отладки LEVEL9 и настроить отдельный реальный запрос. Изучите план выполнения, исследуйте индексы, настраивайте там, где это возможно. Помните, что каждое представление (таблица, группировка, диаграмма, сводка) — это отдельный запрос, который может потребовать настройки. Затем он снова изменяется при использовании фильтра поиска или фильтра заголовка столбца!
Ваша настройка MaxRowCount также вступает в игру, и стоит попытаться сделать ее как можно меньше. На это нет правильного ответа, и вам, возможно, придется играть с разными числами, прежде чем вы получите что-то, что работает для ваших пользователей.
В принципе, рассмотрите возможность удаления или изменения некоторых сценариев поведения, заданных по умолчанию. У разработчиков есть много средств управления, когда речь заходит о том, какие функции включены для пользователей. Стоит попробовать различные настройки, и не забудьте проконсультироваться с вашими пользователями, чтобы убедиться, что вы полностью поняли их требования.
Наконец, если вы обнаружите, что ваш IR все еще слишком медленный, вы можете рассмотреть 2 альтернативы:
Спасибо Карен Каннелл за эти суперполезные советы по IR.
Когда все остальное не удается, вы можете добавить "&p_trace=YES " в конец вашего URL-адреса, чтобы создать файл трассировки, который вы сможете проанализировать с помощью утилиты TKPROF.
Дополнительную информацию о трассировке SQL можно найти здесь.
Все еще застряли? Я всегда поражаюсь отзывчивости сообщества Oracle APEX. Протяните руку помощи, попросите помощи на различных форумах или в твиттере, кто-то обязательно укажет вам правильное направление. Я получила бесчисленное количество ответов на призывы о помощи. Ты найдешь ответ! Просто помните: это не APEX, это, чаще всего, ты, ты сам :-)
Сегодня нашей компании исполняется 28 лет, и в честь этого приятного события мы решили поделиться с вами новым материалом.
Благодарим за помощь с переводом нашего постоянного автора Юрия Пономарева OBIEESupport.
Автор статьи – Мишель Скэмин, основатель и управляющий партнер компании, предоставляющей сервис Reading Rewards. В далеком 2009 году Мишель страдала от того, что ее сыновья 8 и 9 лет слишком мало читали. Книги просто не могли конкурировать с компьютером и видеоиграми, поэтому Мишель со своим мужем решили разработать систему, в которой дети зарабатывали время на компьютерные игры, читая книжки.
Будучи IT-консультантом и разработчиком веб-приложений, Мишель разработала софт, позволяющий детям фиксировать время чтения и просмотра телевизора, а родителям – отслеживать это время. Это и стало началом сервиса Reading Rewards.
А теперь, собственно, статья.
Итак, вы выбрали потрясающее приложение Oracle APEX за рекордную быстроту — писать много не придется. И, как гласит старая поговорка, чему быть – того не миновать!
В 2010 году я создала приложение, чтобы попытаться увлечь моих двух маленьких сыновей чтением. Признаюсь, в то время я не думала о производительности, и в нем было несколько сочных «select count(*) from huge table» вроде как стратегически разбросанных по всему коду.
Эй, мои мальчики на самом деле читали не так уж много, так что эти таблицы были довольно маленькими в то время…
Давайте просто скажем, что я была довольно наивна, когда выпустила приложение на публику, и никак не ожидала, что нагрузка на него составит тысячи пользователей ежедневно, генерируя 150 000 просмотров страниц в день.
Статистика из 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, чтобы сделать его максимально детализированным:
select workspace
, application_name
, application_id, page_id
, count(*) total_page_events
, avg(elapsed_time) avg_elapsed_time
, sum(elapsed_time) elapsed_time
from apex_workspace_activity_log
where view_date between to_date('201911190900','RRRRMMDDHH24MISS') and to_date('201911191200','RRRRMMDDHH24MISS')
group by workspace, application_name, application_id, page_id
order by 6, 7 asc
3. #TIMING# переменная подстановки
Итак, вы, возможно, нашли медленную страницу. И что теперь?
Ну, вы можете использовать переменную подстановки #TIMING# в нижнем колонтитуле ваших регионов отчета, если хотите получить и отобразить их истекшее время. Это может помочь вам определить наиболее медленные области отчета на странице, на которые вы можете обратить свое внимание. Это особенно полезно на страницах панели мониторинга, где у вас может быть много работы.
Использование строки подстановки #TIMING# в нижнем колонтитуле отчета
Запуск отчета тогда даст результат:
Одна вещь, которая мне нравится в этой функции, — это не обязательно то, что она определяет, какие регионы требуют много времени для запуска (я могла получить это из моего окна отладки, см. ниже), но она предлагает информацию конечным пользователям.
Часто я обнаруживаю, что они будут запрашивать данные, которые, как я знаю, будут визуализироваться целую вечность. По крайней мере, это дает им некоторое представление о том, что может происходить и почему им пришлось ждать свою страницу немного дольше, чем ожидалось.
4. Запустите страницу в режиме отладки
Еще лучше, запустите его в Debug LEVEL9, чтобы получить доступ к плану выполнения вашего отчета.
Окно отладки покажет вам все, что происходит на вашей странице, и покажет время выполнения для каждого компонента. LEVEL9 будет генерировать тонны строк, но вы можете сортировать их по убыванию затраченного времени, чтобы показать, что на вашей странице занимает больше всего времени для визуализации.
5. Остерегайтесь вызова v(”)
Если вы нашли плохо выполняющийся отчет, вы можете проверить, использовали ли вы нотацию v (”), когда вы могли бы использовать переменную bind.
select task_name
from tasks
where assigned_to=:APP_USER
или
select task_name
from tasks
where assigned_to=v('APP_USER')
В большой таблице разница между двумя операторами может быть огромной, потому что v (”) на самом деле является вызовом функции. Это означает, что вы не будете использовать преимущества каких-либо индексов, и запрос приведет к полному сканированию таблицы.
Совет: если вам нужно сослаться на состояние сеанса APEX в представлении (где вы не можете использовать переменные привязки), рассмотрите возможность использования скалярного подзапроса, который может отработать почти так же хорошо, как ваша переменная привязки. Смотрите:
select task_name
from tasks
where assigned_to = (select v('APP_USER') from dual)Спасибо Джону Скотту за то, что он предложил это на одном из мероприятий, на котором я была.
6. Избегайте подстановки строк в запросах, если это возможно
Остерегайтесь строк подстановки в запросах.
Рассмотрим, например, ситуацию, когда вам может потребоваться оператор decode или case в запросе, чтобы определить, на какую страницу вы хотите ветвиться:
select case when dept_no=20 then
'f?p=&APP_ID.:3:&SESSION.::::P3_DEPTNO:'||deptno
else
'f?p=&APP_ID.:2:&SESSION.::::P2_DEPTNO:'||deptno
end as link
, deptno
, dname
from deptИспользование переменной привязки :SESSION, а не строки подстановки &SESSION. может иметь огромное значение и сэкономить Oracle много времени на парсинг. Версия переменной bind позволяет Oracle повторно использовать запрос.
select case when dept_no=20 then
'f?p=&APP_ID.:3:'|| :SESSION ||'::::P3_DEPTNO:'||deptno
else
'f?p=&APP_ID.:2:'|| :SESSION ||'::::P2_DEPTNO:'||deptno
end as link
, deptno
, dname
from deptЕсли вам интересно узнать больше об этом, посмотрите замечательное видео Хорхе Римбласа о строках подстановки, переменных привязки и ссылках 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 альтернативы:
- Конвейерные табличные функции (select * from table (my_rpt_pipelined)) — > они могут работать намного лучше в сложных запросах.
- Создание отчета по коллекции (APEX_COLLECTION)
Спасибо Карен Каннелл за эти суперполезные советы по IR.
15. Трассировка
Когда все остальное не удается, вы можете добавить "&p_trace=YES " в конец вашего URL-адреса, чтобы создать файл трассировки, который вы сможете проанализировать с помощью утилиты TKPROF.
Дополнительную информацию о трассировке SQL можно найти здесь.
Все еще застряли? Я всегда поражаюсь отзывчивости сообщества Oracle APEX. Протяните руку помощи, попросите помощи на различных форумах или в твиттере, кто-то обязательно укажет вам правильное направление. Я получила бесчисленное количество ответов на призывы о помощи. Ты найдешь ответ! Просто помните: это не APEX, это, чаще всего, ты, ты сам :-)
