В чем причина медлительности и ускорения вывода представления БД, которое занимало 6 секунд, внезапно заняв 1,5 секунды?

#java #sql #oracle #wildfly #database-view

#java #sql #Oracle #wildfly #database-view

Вопрос:

У меня есть представление Oracle со следующим условием:

 CREATE OR REPLACE FORCE EDITIONABLE VIEW .....
.
.
select *  from 
(select t1.*,(select t.enddate from (select enddate,empid,
  ROW_NUMBER() OVER (PARTITION BY empid ORDER BY enddate desc) as seqnum
  from employee t2
  where t2.empid=t1.empid) t
   where seqnum=1)  As enddate_1 from (select * from
(select WED.*,ROW_NUMBER() OVER (PARTITION BY empid ORDER BY startdate desc) as seqnum from 
(select t1.*,COUNT(*) OVER (PARTITION BY empid) WDECOUNT from employee t1) WED
where WDECOUNT=1 or WED.startdate <= sysdate)) t1 WHERE seqnum=1);

Это представление используется 20 или 30 интеграциями Java на сервере Wildfly для извлечения данных сотрудника.

С последних 7 дней создания потребовалось 6 секунд, чтобы вернуть 50 записей, и теперь внезапно для извлечения тех же записей требуется 1,5 (никаких изменений в view sql не внесено).

Проверил историю oracle и не нашел ни одной команды очистки кэша или каких-либо блокировок.

Каковы, по вашему мнению, вероятности внезапного увеличения производительности?

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

Я вообще не знаю о oracle, выполнена ли какая-либо индексация (не найдена в истории) или ресурсы предоставлены или около того. Если кто-то может помочь и с точки зрения Oracle)

Запрос Oracle, который я использовал для проверки истории:

 SELECT v.FIRST_LOAD_TIME, CPU_TIME, ELAPSED_TIME, PARSING_SCHEMA_NAME, MODULE, V.* FROM V$SQL V 
where PARSING_SCHEMA_NAME = 'MAHTERJEEDATA' order by v.FIRST_LOAD_TIME desc;

Oracle Database 12c Release 12.1.0.1.0 — 64-разрядная версия

1. Не выполняйте перекрестную отправку — dba.stackexchange.com/questions/274056 / …

2. Если у вас есть лицензия на использование ASH и AWR (dba_hist_ views и v $ active_session_history), вы можете проверить, изменился ли план. Это всегда первое, что я проверяю.

Ответ №1:

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

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

Проверьте план выполнения представления за последние 7 дней с помощью AWR

 SELECT * FROM table(DBMS_XPLAN.DISPLAY_AWR('your_sql_id'));

Возможно, теперь вы получаете два разных плана, хранящихся в AWR для одного и того же SQL.

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