Текущее время: Сб, июл 19 2025, 05:16

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


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


ВНИМАНИЕ!

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



Начать новую тему Ответить на тему  [ Сообщений: 39 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Вт, мар 24 2009, 11:58 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Лично я использую FOR ALL ENTRIES, только если во внутренней таблице есть первичный ключ.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Вт, мар 24 2009, 15:09 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Удав написал(а):
Лично я использую FOR ALL ENTRIES, только если во внутренней таблице есть первичный ключ.

...И только с кластерными таблицами. :) С прозрачными лучше SQL.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Вт, июн 30 2009, 05:41 
Старший специалист
Старший специалист

Зарегистрирован:
Пт, авг 24 2007, 11:29
Сообщения: 350
Здравствуйте коллеги.

1. Что-то не очень понял про ограничение длины запроса, если можно по подробнее опишите.
2. Есть проблема: при включении в запрос ranges c 5000 записей EQ и 1500 записей BT, программа вылетает в Дамп, как бы по подробней узнать в чем может быть причина, и как решить эту проблему.

Заранее спасибо!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Вт, июн 30 2009, 07:15 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
1.Читайте стр.1. :twisted:
Есть ограничение на общую длину SQL-запроса к БД.
Для Oracle max длина запроса - 64 КБ.
2.Посмотрите внимательно, что написано в дампе. И переходите к п.1

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Вт, июн 30 2009, 09:43 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
slim написал(а):
Здравствуйте коллеги.

1. Что-то не очень понял про ограничение длины запроса, если можно по подробнее опишите.
2. Есть проблема: при включении в запрос ranges c 5000 записей EQ и 1500 записей BT, программа вылетает в Дамп, как бы по подробней узнать в чем может быть причина, и как решить эту проблему.

Заранее спасибо!


SAP переводит запросы к нормальной SQL-форме, т.е. значения из range описываются в виде строки условий, разделенных OR. Соотвественно для ваших 5000 записей EQ строиться строка из 5000 условий через OR, и т.д. Отсюда и ограничение длины запроса.
При использовании FOR ALL ENTRIES сапа сама разбивает ваши запросы на множество sql-запросов.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 05:50 
Старший специалист
Старший специалист

Зарегистрирован:
Пт, авг 24 2007, 11:29
Сообщения: 350
Parazit написал:
SAP переводит запросы к нормальной SQL-форме, т.е. значения из range описываются в виде строки условий, разделенных OR. Соотвественно для ваших 5000 записей EQ строиться строка из 5000 условий через OR, и т.д. Отсюда и ограничение длины запроса.
При использовании FOR ALL ENTRIES сапа сама разбивает ваши запросы на множество sql-запросов.


Большое спасибо за ответы.
Проблемка в том, что FOR ALL ENTRIES одновременно с JOIN не работает, а мой запрос очень большой, что-то не хочется разбивать его на кучу маленьких, может есть другие пути решения?
+ меня очень интересует быстродействие данной программы т.к. таких запросов в ней не один и FOR ALL ENTRIES, мне кажется, будет работать долше чем JOIN.

Code:
* ДОСТАЕМ ДАННЫЕ ПО ТАБЛИЦЕ ANLA
  SELECT A~BUKRS A~ORD42 A~EIGKZ A~ANLKL A~ANLN1 A~TXT50 A~TXA50 A~ANLN2 A~INVNR A~AKTIV A~DEAKT A~ORD41 A~URWRT A~VMGLI A~ANLAR
         A~ANLUE A~GDLGRP A~UMWKZ A~ORD43
* ТЕКСТЫ
         B~BUTXT C~TXK50 D~ORDTX AS ORD1TX E~ORDTX AS ORD2TX F~ORDTX AS ORD3TX G~ANLUE_TXT H~GDLGRP_TXT I~TXT50 AS UMWKZ_TXT
* ANLZ
         J~STORT J~BDATU J~ADATU K~KTEXT AS STORT_TXT

    INTO CORRESPONDING FIELDS OF TABLE OUT_TAB FROM ANLA AS A
* НАИМЕНОВАНИЕ БЕ
    LEFT JOIN T001 AS B ON
          B~BUKRS = A~BUKRS
* НАИМЕНОВАНИЕ КЛАССА ОС
    LEFT JOIN ANKT AS C ON
          C~ANLKL = A~ANLKL AND C~SPRAS = SY-LANGU
* НАИМЕНОВАНИЕ АМОРТИЗАЦИОННАЯ ГРУППА
    LEFT JOIN T087T AS D ON
          D~ORD4X = A~ORD41 AND D~ORDNR = '1' AND D~SPRAS = SY-LANGU
* НАИМЕНОВАНИЕ ПОДРАЗДЕЛЕНИЯ
    LEFT JOIN T087T AS E ON
          E~ORD4X = A~ORD42 AND E~ORDNR = '2' AND E~SPRAS = SY-LANGU
* НАИМЕНОВАНИЕ НАПРАВЛЕНИЯ ПОСТУПЛЕНИЯ
    LEFT JOIN T087T AS F ON
          F~ORD4X = A~ORD43 AND F~ORDNR = '3' AND F~SPRAS = SY-LANGU
* НАИМЕНОВАНИЕ ОКОФ
    LEFT JOIN T087V AS G ON
          G~ANLUE = A~ANLUE AND G~SPRAS = SY-LANGU
* НАИМЕНОВАНИЕ ШНА
    LEFT JOIN T087S AS H ON
          H~GDLGRP = A~GDLGRP AND H~SPRAS = SY-LANGU
* НАИМЕНОВАНИЕ ЛЬГОТ
    LEFT JOIN T087L AS I ON
          I~UMWKZ = A~UMWKZ AND I~SPRAS = SY-LANGU
* ДОСТАЕМ ДАННЫЕ ПО ТАБЛИЦЕ ANLZ
    JOIN ANLZ AS J ON
          J~ANLN1 = A~ANLN1 AND J~ANLN2 = A~ANLN2 AND
          J~BUKRS = A~BUKRS AND J~BDATU >= DATE_ACT
* НАИМЕНОВАНИЕ МЕСТОРАСПОЛОЖЕНИЯ
    LEFT JOIN T499S AS K ON
          K~STAND = J~STORT AND K~WERKS = J~WERKS
    WHERE A~ANLKL IN ANLKL AND A~BUKRS IN BUKRS AND
          A~ANLN1 IN ANLN1 AND A~ANLN2 IN ANLN2 AND
          A~ORD41 IN ORD41 AND A~ORD42 IN ORD42 AND
          A~ORD43 IN ORD43 AND A~EIGKZ IN EIGKZ AND
          A~VMGLI IN VMGLI AND A~ANLUE IN ANLUE AND
          A~GDLGRP IN GDLGRP AND A~UMWKZ IN UMWKZ AND
          A~INVNR IN INVNR AND
          A~INVNR IN INV_NUM AND
          (USL_DAT) AND
          A~ANLN1 IN RT_ANLN1 AND A~ANLN2 IN RT_ANLN2 AND
          J~WERKS IN WERKS AND J~STORT IN STORT.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 07:26 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Все LEFT JOIN с таблицами T* лучше заменить на SELECT SINGLE в цикле после SELECT.
Дело в том, что многие настроечные таблицы буферизированы на уровне сервера приложений (см. SE12 - Технические параметры), поэтому чтение из них по отдельности займет меньшее время, чем JOIN на уровне БД.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 07:38 
Старший специалист
Старший специалист

Зарегистрирован:
Пт, авг 24 2007, 11:29
Сообщения: 350
Удав написал(а):
Все LEFT JOIN с таблицами T* лучше заменить на SELECT SINGLE в цикле после SELECT.
Дело в том, что многие настроечные таблицы буферизированы на уровне сервера приложений (см. SE12 - Технические параметры), поэтому чтение из них по отдельности займет меньшее время, чем JOIN на уровне БД.


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

Если переделывать это все через FOR ALL ENTRIES, придется еще и сортировать мои таблички, а потом еще и read table делать, думаю, что это работать будет гораздо дольше, чем JOIN, но наверно так и придется переделать свою программу.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 09:08 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Пн, окт 11 2004, 20:32
Сообщения: 2470
Пол: Мужской
slim написал(а):
Предыдущая версия этой программы так и работала, как вы предлагаете, но она генерирует очень большое количество запросов к БД из-за этого сервер БД начинает тормозить(соответственно таких программ было много). В следствии этого было принято решение переделать программу по принципу оптимизация запросов к БД.

Думаете один такой большой запрос будет выполняться быстрее чем много маленьких? Зря Удава не слушаете...
Вы программу через SE30 гоняли?

Цитата:
Если переделывать это все через FOR ALL ENTRIES, придется еще и сортировать мои таблички, а потом еще и read table делать, думаю, что это работать будет гораздо дольше, чем JOIN, но наверно так и придется переделать свою программу.

самое лучшее для вас - это сделать несколько вариантов и погонять через SE30

_________________
- Может ли настоящий мастер кунг-фу получить по морде?
- Настоящий мастер может все!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 09:19 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Ср, ноя 03 2004, 14:51
Сообщения: 1912
Откуда: КраснАдар
Пол: Мужской
А что мешает настроечные таблички сразу скопом взять в программу? Надеюсь, что в них не будет больше пары сотен записей (с учетом языка входа) и много места они не займут. И читать их потом в цикле по основной таблице.
Думается, что чуть побыстрей будет, чем много таблиц в джойне.

ЗЫ Было бы интересно сравнить быстродействие с предложением Удава.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 09:39 
Старший специалист
Старший специалист

Зарегистрирован:
Пт, авг 24 2007, 11:29
Сообщения: 350
John Doe написал:
А что мешает настроечные таблички сразу скопом взять в программу? Надеюсь, что в них не будет больше пары сотен записей (с учетом языка входа) и много места они не займут. И читать их потом в цикле по основной таблице.
Думается, что чуть побыстрей будет, чем много таблиц в джойне.

ЗЫ Было бы интересно сравнить быстродействие с предложением Удава.


Спасибо за ответы, действительно надо попробовать оба варианта. Через SE30, еще пока что не гонял.
Хочу повторить, что программу я переделываю именно для оптимизации (сокращение количества) запросов к БД. т.е. SELECT SINGLE, я думаю, мне не подходит, но проверить быстпродействие этого варианта тоже надо попробовать.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 11:22 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Удав написал(а):
Все LEFT JOIN с таблицами T* лучше заменить на SELECT SINGLE в цикле после SELECT.
Дело в том, что многие настроечные таблицы буферизированы на уровне сервера приложений (см. SE12 - Технические параметры), поэтому чтение из них по отдельности займет меньшее время, чем JOIN на уровне БД.


Удав!
Тут я не соглашусь. Чтение то может и быстрее будет, но интерпретация 5000 SQL-запросов займет больше времени, чем само чтение.
Так что, в общем случае, я за JOIN. И вообще за то, чтобы доступом к данным занимался специалист этого дела, то бишь ORACLE! :)

slim!
К приведенному выше запросу в принципе претензий нет, он вполне оптимален. Единственное - я не увидел проверки ANLA-ADATU...

Здесь нужна не оптимизация запроса, а оптимизация алгоритма. Любой запрос будет работать долго, если ему ставить ~5000 условий. Откуда эти 5000 значений? Неужели юзеры тупо набирают их в селекционном экране?! Не верю! ;)
Если они хранятся в какой то таблице, и их можно достать по простому условию, то лучше эту выборку добавить в общий Select.
А если не хранятся, то надо это организовать каким -нибудь интерфейсом.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 11:50 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Parazit написал:
Удав написал(а):
Все LEFT JOIN с таблицами T* лучше заменить на SELECT SINGLE в цикле после SELECT.
Дело в том, что многие настроечные таблицы буферизированы на уровне сервера приложений (см. SE12 - Технические параметры), поэтому чтение из них по отдельности займет меньшее время, чем JOIN на уровне БД.


Удав!
Тут я не соглашусь. Чтение то может и быстрее будет, но интерпретация 5000 SQL-запросов займет больше времени, чем само чтение.
Так что, в общем случае, я за JOIN. И вообще за то, чтобы доступом к данным занимался специалист этого дела, то бишь ORACLE! :)

А кто сказал, что будет 5000 чтений из БД для справочников?
Для буферизированных таблиц данные будут браться с сервера приложений и запроса к БД не будет, для небуферизированных таблиц можно организовать буферизацию на уровне программы.
При этом количество select single будет равно количеству уникальных значений в справочниках. :wink:

А вот соединение через left join больше, чем 3-5 таблиц может занять у интерпретатора запросов Oracle большее время, чем интерпретация большого количества простых запросов.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 11:55 
Старший специалист
Старший специалист

Зарегистрирован:
Пт, авг 24 2007, 11:29
Сообщения: 350
Parazit написал:
Здесь нужна не оптимизация запроса, а оптимизация алгоритма. Любой запрос будет работать долго, если ему ставить ~5000 условий. Откуда эти 5000 значений? Неужели юзеры тупо набирают их в селекционном экране?! Не верю! ;)
Если они хранятся в какой то таблице, и их можно достать по простому условию, то лучше эту выборку добавить в общий Select.
А если не хранятся, то надо это организовать каким -нибудь интерфейсом.


Основная задача это отчет связи FI-AA и RE-FX, ranges с 5000 записей это связи FI-AA и RE-FX, разумеется я его формирую программно.
Кол-во записей и там и там примерно 50000, на счет оптимизация алгоритма, как раз ею я сейчас и занимаюсь. :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ограничение на кол-во записей в ranges
СообщениеДобавлено: Ср, июл 01 2009, 12:10 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Как пример из SE30:
Code:
Оператор                                                    Кол-во чтений   Общее время (мкс)
Select Single TAIF5T                                               13 165    482 574
Select Single T087V                                                13 165    456 261
Select Single T087T                                                13 165    385 185
Select Single T087J                                                13 165    284 760

Обращения к БД по ST05 к этим таблицам не было.
Если еще сделать буферизацию на уровне программы, то за счет уменьшения количества чтений время будет намного меньше.

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


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

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

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