Текущее время: Ср, июл 30 2025, 21:37

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


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


ВНИМАНИЕ!

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



Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Оптимизация запроса
СообщениеДобавлено: Пт, дек 12 2008, 17:10 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Пн, июн 25 2007, 17:37
Сообщения: 350
Пол: Мужской
Code:
  SELECT bsis~gjahr bsis~hkont bsis~belnr bsis~budat bsis~shkzg
         bsis~dmbtr bsis~zuonr bsis~augbl bsis~augdt bsis~xnegp
         bkpf~blart bkpf~stblg bkpf~bktxt bkpf~awtyp bkpf~awkey

  INTO CORRESPONDING FIELDS OF TABLE ifull
  FROM  ( bsis INNER JOIN bkpf ON bsis~bukrs = bkpf~bukrs AND
                                  bsis~gjahr = bkpf~gjahr AND
                                  bsis~belnr = bkpf~belnr )
  WHERE bsis~bukrs eq zz_bukrs AND
        bsis~hkont in zz_hkont AND
        bsis~zuonr in zz_ZUONR AND
        bsis~budat <= zz_DATE-high.


В данном запросике мы выбираем сальдо на начало, обороты.
Больше всего интересует вот эта строка "bsis~budat <= zz_DATE-high", что получается, данный отчет с каждым годом все медленее и медленее будет работать и в один прекрасный день сдохнет!!?


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:45 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Пн, дек 08 2008, 19:17
Сообщения: 92
Откуда: Москва
Пол: Мужской
Это точно. SAP вообще в таких случаях сальдо сохраняет в вспомогательную таблицу.

_________________
В смысле осмысления бессмысленности, смысл тоже имеет определенную осмысленность.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:47 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Пн, июн 25 2007, 17:37
Сообщения: 350
Пол: Мужской
VitalkaFS написал:
Это точно. SAP вообще в таких случаях сальдо сохраняет в вспомогательную таблицу.


Какую?


Последний раз редактировалось Valeriy Пт, дек 12 2008, 17:48, всего редактировалось 1 раз.

Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:48 
Ассистент
Ассистент

Зарегистрирован:
Ср, мар 05 2008, 15:30
Сообщения: 44
делал вызовом стандартной программы fs10n, работает быстро.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 17:52 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Пн, дек 08 2008, 19:17
Сообщения: 92
Откуда: Москва
Пол: Мужской
Наврал я совсем.
На самом деле когда позиция закрывается она стирается из BSIS, тобишь в этой таблице всегда актуальная расшифровка.
Так что, с производительностью все будет ок.
А вообще таблица итоговых записей GLT0 для FI-GL без новой главной книги и FAGLFLEXT для новой главно книги.

_________________
В смысле осмысления бессмысленности, смысл тоже имеет определенную осмысленность.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 12 2008, 19:17 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
Хотелось бы на всякий случай предупредить насчет использования zz_DATE-high. Судя по high, это SELECT-OPTION или RANGE какой-то. Если это SELECT-OPTION, то результат может получиться весьма неожиданным, если пользователь выберет не "Select ranges", а "Exclude ranges", например. Да и вообще HIGH может пустым оказаться, если, конечно, специально не делать проверки на экране.

Почему-то часто об этом забывают и рассчитывают, что пользователь сделает именно такой выбор, как ожидается. Assumption is mother of all screw-ups.

Кроме того, может стоит хотя бы GJAHR как-то разумно ограничить. :?

_________________
"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important." Bertrand Russell


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Ср, дек 17 2008, 21:34 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, мар 02 2005, 20:19
Сообщения: 133
Откуда: Moscow
Если оптимизировать именно данный SELECT, то попробуйте избавиться от INTO CORRESPONDING FIELDS OF TABLE, это добавит %%30 производительности.
А вообще для сальдо и оборотов действительно есть отдельные таб.

_________________
Монарх - это серъезно (с) "Классик"


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Сб, дек 27 2008, 21:38 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Monarch написал(а):
Если оптимизировать именно данный SELECT, то попробуйте избавиться от INTO CORRESPONDING FIELDS OF TABLE, это добавит %%30 производительности.

А можно пример , при котором 30% выигрыша в производительности получается? :)

_________________
С уважением,
Удав.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вс, дек 28 2008, 16:40 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, мар 02 2005, 20:19
Сообщения: 133
Откуда: Moscow
Удав написал(а):
Monarch написал(а):
Если оптимизировать именно данный SELECT, то попробуйте избавиться от INTO CORRESPONDING FIELDS OF TABLE, это добавит %%30 производительности.

А можно пример , при котором 30% выигрыша в производительности получается? :)


Ну, специально сидеть и подбирать пример именно с 30% я, пожалуй, не буду :wink:
Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.

_________________
Монарх - это серъезно (с) "Классик"


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вс, дек 28 2008, 17:10 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Monarch написал(а):
Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.

Ну как сказать...
Посмотрите план запроса
Code:
data: begin of gs_bkpf,
        bukrs type bkpf-bukrs,
        belnr type bkpf-belnr,
        gjahr type bkpf-gjahr,
        awkey type bkpf-awkey,
        awtyp type bkpf-awtyp,
      end of gs_bkpf,
      gt_bkpf like standard table of gs_bkpf.

parameters: p_bukrs type bkpf-bukrs,
                   p_gjahr type bkpf-gjahr.
select-options: so_belnr for gs_bkpf-belnr.

field-symbols: <fs_bkpf> like gs_bkpf.
start-of-selection.
  select *
  into correcponding fields of table gt_bkpf
  from bkpf
  where bukrs = p_bukrs
    and belnr in so_belnr
    and gjahr = p_gjahr.

  loop at gt_bkpf assigning <fs_bkpf>.
    ...
  endloop.

В этом примере можно использовать "select *", так как интерфейс с БД корректно формирует запрос и указывает в обращении к БД конкретные имена полей из gs_bkpf вместо "*". :wink:
Гораздо большие тормоза в случае большого объема выбираемых данных будут в цикле по строкам таблицы с помощью loop .. into вместо loop .. assigning.

_________________
С уважением,
Удав.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Пн, дек 29 2008, 18:16 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Valeriy написал:
В данном запросике мы выбираем сальдо на начало, обороты.
Больше всего интересует вот эта строка "bsis~budat <= zz_DATE-high", что получается, данный отчет с каждым годом все медленее и медленее будет работать и в один прекрасный день сдохнет!!?

Строго говоря, в общем случае по одной таблице BSIS нельзя построить сальдо, нужно обязательно делать такой же запрос по BSAS, ибо BSIS + BSAS = BSEG.
Да, САПа для общих итогов по счетам в разрезе периодов (MONAT) использует таблицу GLT0, можно ей воспользоваться. Но если нужно получить сальдо в любом другом разрезе, например по полю ZUONR (не зря же оно у вас в селекте?!), или на дату не кратную месяцу, то придется каждый раз шерстить табличку, либо создать свою таблицу итогов в нужном разрезе, например, используя инструменты спецрегистров.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вт, дек 30 2008, 10:31 
Специалист
Специалист

Зарегистрирован:
Чт, окт 26 2006, 16:44
Сообщения: 149
Откуда: Москва
Monarch написал(а):
Ну, специально сидеть и подбирать пример именно с 30% я, пожалуй, не буду :wink:
Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.


Расскажите, пожалуйста, откуда вы взяли, что эту форму запроса лучше избегать. Кусок из документации приведите или хоть как-то обоснуйте. Достаточно даже не на 30%, а 10%... Я лично заявляю, что никакой разницы в производительности не будет.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вт, дек 30 2008, 11:38 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
vakito написал(а):
Monarch написал(а):
Ну, специально сидеть и подбирать пример именно с 30% я, пожалуй, не буду :wink:
Но согласитесь, что INTO CORRESPONDING FIELDS OF TABLE лучше избегать по возможности.


Расскажите, пожалуйста, откуда вы взяли, что эту форму запроса лучше избегать. Кусок из документации приведите или хоть как-то обоснуйте. Достаточно даже не на 30%, а 10%... Я лично заявляю, что никакой разницы в производительности не будет.


Давно это было... :)
Скорей всего имеется ввиду, что лучше не использовать конструкцию CORRESPONDING, в стародавние времена попадалась мне саповская дока на эту тему, возможно еще с версии 4.0. С тех пор где то на подкорке и записано, что лучше использовать INTO TABLE, а не INTO CORRESPONDING FIELDS OF TABLE. Допускаю, что новые версии работают более оптимально.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса
СообщениеДобавлено: Вт, дек 30 2008, 12:27 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, мар 02 2005, 20:19
Сообщения: 133
Откуда: Moscow
Parazit написал:
vakito написал(а):
Расскажите, пожалуйста, откуда вы взяли, что эту форму запроса лучше избегать. Кусок из документации приведите или хоть как-то обоснуйте. Достаточно даже не на 30%, а 10%... Я лично заявляю, что никакой разницы в производительности не будет.


Давно это было... :)
Скорей всего имеется ввиду, что лучше не использовать конструкцию CORRESPONDING, в стародавние времена попадалась мне саповская дока на эту тему, возможно еще с версии 4.0. С тех пор где то на подкорке и записано, что лучше использовать INTO TABLE, а не INTO CORRESPONDING FIELDS OF TABLE. Допускаю, что новые версии работают более оптимально.


Все точно, и именно с версии 4.0 такой стереотип у меня :wink:
Vakito, а вы можете обосновать, что разницы в работе с/ без CORRESPONDING FIELDS OF совсем нет, т.е. производительность одинакова?

_________________
Монарх - это серъезно (с) "Классик"


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация запроса  Тема решена
СообщениеДобавлено: Вт, дек 30 2008, 13:48 
Специалист
Специалист

Зарегистрирован:
Чт, окт 26 2006, 16:44
Сообщения: 149
Откуда: Москва
Monarch написал(а):
Все точно, и именно с версии 4.0 такой стереотип у меня :wink:
Vakito, а вы можете обосновать, что разницы в работе с/ без CORRESPONDING FIELDS OF совсем нет, т.е. производительность одинакова?

Два простейших запроса
Code:
DATA : BEGIN OF lt_ekko OCCURS 0,
         ebeln TYPE ekko-ebeln,
         bsart TYPE ekko-bsart,
         bsakz TYPE ekko-bsakz,
         bukrs TYPE ekko-bukrs,
         bstyp TYPE ekko-bstyp,
       END OF lt_ekko.

SELECT ebeln bsart bsakz bukrs bstyp
  FROM ekko
  INTO TABLE lt_ekko.

SELECT ebeln bukrs bstyp bsart bsakz
  FROM ekko
  INTO CORRESPONDING FIELDS OF TABLE lt_ekko.


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


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

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


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

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


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

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