CftClub.ru
Клуб специалистов ЦФТ-Банк

HELP. Оптимизация запроса.

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Разработка в PL/PLUS. Оптимизация запросов Oracle
Предыдущая тема :: Следующая тема  
Автор Сообщение
lil007
Участник


Вступление в Клуб: 12.01.2023
СообщениеСр Янв 24, 2024 07:15   HELP. Оптимизация запроса. Ответить с цитатой
Полезность: Нет оценки
Добрый день.
Подскажите, есть проблема что у пользователя долго открывается вьюха.

Мне сказали, что можно по ID сессии как-то подрубится, через девелопер к сессии и посмотреть план запроса (это если я правильно постановку вопроса понял).

Как это сделать?
Volod
Эксперт


Вступление в Клуб: 19.09.2007
СообщениеСр Янв 24, 2024 09:51    Ответить с цитатой
Полезность: Нет оценки
Если проблема только у одного юзера - м.б. настройка Количество строк в запросе - любят юзеры большое кол-во строк настраивать
lil007
Участник


Вступление в Клуб: 12.01.2023
СообщениеСр Янв 24, 2024 20:24    Ответить с цитатой
Полезность: Нет оценки
Volod пишет:
Если проблема только у одного юзера - м.б. настройка Количество строк в запросе - любят юзеры большое кол-во строк настраивать


Если и так. Вопрос темы не раскрыт.
Volod
Эксперт


Вступление в Клуб: 19.09.2007
СообщениеЧт Янв 25, 2024 09:47    Ответить с цитатой
Полезность: Нет оценки
Select sql_id from v$sql
where sql_fulltext like '%Z#MAIN_DOCUM%';

Select * from v$sql_plan where sql_id='7ffjqc8yd0073'
Эмиралька
Эксперт


Вступление в Клуб: 09.11.2015
СообщениеВс Янв 28, 2024 10:51   Re: HELP. Оптимизация запроса. Ответить с цитатой
Полезность: Нет оценки
lil007 пишет:
Добрый день.
Подскажите, есть проблема что у пользователя долго открывается вьюха.

Мне сказали, что можно по ID сессии как-то подрубится, через девелопер к сессии и посмотреть план запроса (это если я правильно постановку вопроса понял).

Как это сделать?


Зачем так сложно.
План запроса смотрится при наличии самого запроса.
Пользователь заходит в предсталвение. Жмёт кнопку SQL. Вы смотрите текст запроса и значения bind-переменных. Затем смотрите план.
Либо: пользователь ждёт, вы находите сессию пользователя в сис.вьюшне v$session, начинаете снимать с этой сессии трейс, командуете пользователю зайти во вьюшку, когда зайдёт - выключаете трассировку, разбираете, смотрите.
pabrz
Участник со стажем


Вступление в Клуб: 27.09.2022
СообщениеЧт Фев 01, 2024 04:31    Ответить с цитатой
Полезность: Нет оценки
Обратите внимание на фильтры.

Последняя опция коллег из ЦФТ на эту тему была связана с тем, что при обращении к представлению через фильтр заполнялась служебная таблица.
По каждому пользователю.
Каждый раз.

Почему это делается?
Потому что блок where теперь не умеет в функции.

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

Решение, мягко говоря, спорное. Smile Посмотрите свой случай на подобный феномен.
Эмиралька
Эксперт


Вступление в Клуб: 09.11.2015
СообщениеПт Фев 02, 2024 14:03    Ответить с цитатой
Полезность: Нет оценки
pabrz пишет:
Обратите внимание на фильтры.

Последняя опция коллег из ЦФТ на эту тему была связана с тем, что при обращении к представлению через фильтр заполнялась служебная таблица.
По каждому пользователю.
Каждый раз.

Почему это делается?
Потому что блок where теперь не умеет в функции.

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

Решение, мягко говоря, спорное. Smile Посмотрите свой случай на подобный феномен.


Конечно, спорное. а как вы выкручиваетесь? а то у меня ещё дофига представлений переделывать...
pabrz
Участник со стажем


Вступление в Клуб: 27.09.2022
СообщениеПн Фев 05, 2024 01:33    Ответить с цитатой
Полезность: Нет оценки
Пока в большинстве случаев так и делаем: рефакторинг функций и перевод в sql. Иногда для сокращение объема через макросы, но это только визуальное сокращение - де факто объем будет тот же, так что всегда есть шанс перешагнуть лимит объема текста представления.
Есть еще мысль делать представление с колонками-функциями, а потом второе селектом из нее, но не пробовал пока, есть ненулевой шанс, что не сработает, то же самое касается функциональных реквизитов.

Куда больше жаль сложные конструкции, вроде трехмерных представлений (инструкция model), которые, очевидно, перестанут поддерживаться полностью. Postgree в них не умеет. Вот их заменить просто нечем.
pabrz
Участник со стажем


Вступление в Клуб: 27.09.2022
СообщениеВт Май 28, 2024 04:49    Ответить с цитатой
Полезность: 1
Таки появилось что добавить по этой теме.
Я тут намедни подобный вопрос решал, и он чудесно решается теми самыми конвеерными функциями, про которые недавно в соседней теме говорили. На удивление, примеров в коде от ЦФТ на эту тему вы с большой вероятностью не найдете. Smile

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

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

Дальше все довольно просто:

Мы делаем внутренний record со всеми колонками, которые будем считать в конвеере+ID объекта, для связи потом в основном селекте представления.

А дальше просто цепляем конвеер в представлении обычным join. В результате чего автоматически накладываем фильтр на представление ( в конвеере фильтрация как раз и делается) и просто вытаскиваем все нужные нам поля в готовом виде.

Господа из ЦФТ идею тоже одобрили.

Ограничения и минусы:
1. Оптимизация. Как я уже говорил, конвееру надо жевать максимум записей. Насколько шустро тут отработает DBI вопрос открытый, ибо согласно комментариям ЦФТ - там обычный BIND.
2. Надзапросы нельзя. Т.е. над полученным селектом с конвеером сверху накручивать второй селект уже нельзя. В остальном все вполне прилично.

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

Таким образом на выходе мы получаем вьюху вида
Код:

type main is
      select A1(
         A1.[BBB] : C_BBB,
         PipLine.C_CCC : C_CCC,
         PipLine.C_DDD : C_DDD,
         PipLine.C_EEE : C_EEE,
                        A1.[KKK] : C_KKK

      )
      in ::[AAA]
      join (::[AAA].[LIB].Get_PIPE : PipLine) on a1 = PipLine.ID
      order by A1.[MMM];
Эмиралька
Эксперт


Вступление в Клуб: 09.11.2015
СообщениеВт Май 28, 2024 15:20    Ответить с цитатой
Полезность: Нет оценки
pabrz пишет:
Таки появилось что добавить по этой теме...
Код:

...
      join (::[AAA].[LIB].Get_PIPE : PipLine) on a1 = PipLine.ID
      order by A1.[MMM];


В конвеер передать параметром значения полей из запроса, конечно, нельзя?
pabrz
Участник со стажем


Вступление в Клуб: 27.09.2022
СообщениеСр Май 29, 2024 03:29    Ответить с цитатой
Полезность: Нет оценки
Да вроде можно. Не ясно правда как это в перспективе на скорость работы повлияет, особенно в DBI. Коллега мой туда вообще ID записи из основного селекта передает в качестве параметра Smile. В этом примере - то самое a1(%id).

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

Конвееру всегда проще набрать свой пакет записей, чем построчно от селекта принимать. Пока нам оптимальным видится передача конвееру ключевых параметров для фильтрации (которые зададим на начальном этапе через операцию фильтра), а не полей запроса.
Т.е. конвееер - сам по итогу и является блоком where по совместительству.

Технически - вариант с полями работоспособен. Архитектурно - есть вопросы.

ЗЫ. В моем примере у представления есть фильтр, в котором юзер задает временные интервалы для запроса и т.п., и фильтр эти данные уже передает в библиотеку с конвеером. А селект сам по себе работает уже с результатом всей этой конструкции.
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Разработка в PL/PLUS. Оптимизация запросов Oracle Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах