Текущее время: Пн, июл 14 2025, 07:02

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 18 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Игнорирование буфера/кэша БД при select
СообщениеДобавлено: Пн, мар 18 2019, 18:17 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1613
Лучше прочитать 912620 - FAQ: Oracle indexes прежде чем придумывать

_________________
я твой сап эфай внедрял
BAdI-позитив
Взять немножечко абопу, сунь туда кошачью *опу, RFC лапки, БТ старой бабки, на медленном базиснике переносить, тестовое окружение материть, снимать SAT пенку, биться головой о стенку, охапка тайм-шитов, отчет готов!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Игнорирование буфера/кэша БД при select
СообщениеДобавлено: Чт, мар 21 2019, 07:58 
Специалист
Специалист

Зарегистрирован:
Пн, мар 12 2012, 09:38
Сообщения: 170
superbizon написала:
в хинте с 1000 не погорячились ли?
По идее раз два первых поля из первичного ключа в деле, то primary key должен использоваться, а не Z1.

Структура запроса с FAE и хинтом не особо отличается от структуры такого же запроса с ренджом. (По плану выполнения - вообще не отличается)
Если посмотреть аналогичный запрос сформированный по ренджу, то там SAP разбивает это условие на блоки, соединенные через OR, в итоге получается запрос вида:
Code:
Select "FIELD"
FROM "TABLE"
WHERE "CLIENT "=:A0 AND ( "GUID" IN ( A1,...,A1000 ) OR "GUID" IN ( A1001,...,A2000 ) OR … )

Т.е. рендж нам подкладывает свинью, вставляя OR в казалось бы единое ограничение. К тому же указание большего количества SAP игнорирует, останавливаясь на тысяче(из ноты - the technical maximum blocking factor is calculated for each statement, so that no database system limits are exceeded).
Получается, что если будет указываться 1к+ значений в ограничении - выгоднее делать выборку через FAE, т.к. это и от возможного дампа убережет(при "раздутом" рендже), и по факту может быть быстрее.
Может кто более детально объяснит, в чем может быть опасность указания в FAE значений больше дефолтных 5? Т.к. на форумах и в нотах много где пишут что указывать числа, отличные от дефолтных нужно с осторожностью, но по трассировке ничего опасного я не вижу.

Касательно сабжа, решил подойти с другой стороны, т.к. крутить эту таблицу можно долго, но достигнуть действительно быстрой выборки будет тяжеловато. Да и не совсем подходит её структура для необходимой нам логики. Пока целевой вариант - добавить 2 поля в таблицу с данными объектов(дав осмысленные названия), и при переводе в один из статусов сохранять дату перевода в соответствующее поле, а уже потом по ним просто выбирать. В итоге у каждого объекта там будут находится всегда последние даты перевода в статус. Старые записи обновить через доп. утилиту.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Игнорирование буфера/кэша БД при select
СообщениеДобавлено: Пт, мар 22 2019, 07:03 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Пт, сен 07 2007, 07:53
Сообщения: 1398
Saperx написал(а):
Касательно же плана запроса выше, то я пока не вижу явных мест для оптимизации
Code:
select hist~objnr, hist~stat, hist~udate
from crm_jcds
for all entries in lt_objects
WHERE  hist~objnr = lt_objects-objnr
    AND hist~stat IN ( 'E0001', 'E0002' )
    AND hist~udate IN so_date[]
    AND hist~inact = ''
    %_HINTS ORACLE '&MAX_IN_BLOCKING_FACTOR 1000&'.


А нельзя пересмотреть сам подход к запросу и вовсе избавиться от all entries in lt_objects? У вас ведь скорее всего где-то чуть выше есть запрос, который который сформировал этот самый lt_objects. Значит можно проблемный запрос превратить в JOIN, где в качестве второй таблицы указать данные выборки, которые которые сформировали lt_objects.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 18 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Yandex [Bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB