Автор Тема: Оптимизация ABAP-а  (Прочитано 283337 раз)

0 Пользователей и 2 Гостей просматривают эту тему.

Оффлайн №1

  • Administrator
  • Jr. Member
  • *****
  • Сообщений: 636
  • Репутация: +23/-0
  • Пол: Мужской
  • Судьбы я вызов принимаю прямым пожатием руки
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #25 : Июль 02, 2008, 09:52:12 am »
You are not allowed to view links. Register or Login
А номерок ноты? А то я что-то не нашел, о разных исправлениях ошибок есть... а саму программку где тянуть не находиться...
Ну может убрали. Поищи на ftp у сапов транспорт K900427.XB4  (EILENBERGER    CI Downport 3.Version) - 2003 год.
У себя не нашел - после апгрейда все старые вычистил из transdir. Осталось только в истории импорта
« Последнее редактирование: Июль 02, 2008, 09:58:37 am от №1 »
Мой You are not allowed to view links. Register or Login

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #26 : Июль 07, 2008, 10:34:00 am »
COMMIT WORK - Однако при массовых вставках не надо использовать эту конструкцию после каждой вставки новой записи. Опять же на надо заливать все и делать один общий COMMIT. Оптимальным обычно является фиксация обновления/вставки через 500-1000 обработанных записей. К сожалению это правило часто не работает с функциями BAPI, которые не являются повторно входимыми, поэтому там ничего не поделаешь, но после каждого вызова функции нужно делать COMMIT. Опять же если можно сделать фиксацию на несколько разных вызовов BAPI, то нужно пользоваться такой возможностью.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #27 : Август 01, 2008, 11:20:05 am »
В продолжении темы о COMMIT WORK и BAPI, в общем есть такая функция BAPI_FIXEDASSET_CHANGE - Изменение карточек ОС, написано ничего так, позволяет выполнять COMMIT после обработки нескольких карточек, так вот надо было изменить порядка ~20 000 записей, в программке случайно сбился счетчик и в итоге COMMIT вызвался только после обновления всех записей. К чему это привело, ну во-первых, каждая следующая запись карточки ОС, обновлялась все медленнее и медленнее, так как рос лог транзакции. В общей сумме оно выросло до 400 Мб и тут пришел COMMIT, ну конца этого процесса я не дождался, так как 3 часа висения на этой строчке и было принято решение, а ну его нафиг. В общем подрихтовали программку, COMMIT через 200 записей и в итоге ~20 000 карточек проскочило минут за 40.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #28 : Август 06, 2008, 12:08:54 pm »
И еще в продолжении COMMIT WORK-а, в общем при массовой обработке объектов базы или проводке документов возникает иногда ситуация, что нужно или подождать пока объект станет доступен для последующей обработки или пока документ появится в базе данных. Делать задержку в секундах после каждого COMMIT-а, не только не гуманно, но и желательно отрывать руки за такой код, так как один документ + задержка в секунду, это еще куда не шло, но 500 000 объектов + 1 секудна, это месяц работы программы, хотя без этой задержки, записи к примеру льются со скоростью 15-20 объектов в секунду. Поэтому как общая рекомендация после обновления для проверки существования объекта использовать или объекты блокирования объекта или модули чтения таблицы блокировок из примера: You are not allowed to view links. Register or Login, Во втором случае, проверяем есть ли наш объект в записях блокирования и если есть то ждем, если нет, тогда можем считать что объект уже прошел все обновления и существует в базе данных. А вот для использования объектов блокирования, сначала нужно посмотреть какой объект используется. Например возьмем карточки ОС. Самое просто это зайти в изменения любой карточки ОС, а после этого в другом окне запустить транзакцию SM12. Если у вас больше ничего в других окнах не открыто, то скорее всего там будет одна запись блокирования. Делаете двойной клик на этой записи и получаете детальную информацию по объекту блокирования, рисунок SM12V.png. Нас интересует объект выделенный рамкой, это и есть объект блокировки. Теперь нужно пойти в транзакцию SE11, чтобы узнать функциональные модули управления блокировкой. Вводим полученный объект блокирования, как на рисунке SE11-1.png, жмем просмотр объекта и попадаем в экран просмотра SE11-2.png и там по меню "Перейти к" - "Модули блокировки" и получаем две функции, одна для блокирования объекта основное средство, а другая для деблокирования. Ну а дальше дело техники. После вызова функции создания/обновления карточки ОС, если параметр BAPIRET2 не содержит ошибок, т.е. например создание карточки прошло успешно, то далее вставляем такой код:
Код: You are not allowed to view links. Register or Login
CALL FUNCTION 'ENQUEUE_EANLA'
     EXPORTING
          bukrs          = l_bukrs
          anln1          = l_anln1
          anln2          = l_anln2
          _wait          = 'X'
     EXCEPTIONS
          foreign_lock   = 1
          system_failure = 2
          OTHERS         = 3.
IF sy-subrc = 0.
* Запись находится в БД, блокировку можно снять и бежать дальше
  CALL FUNCTION 'DEQUEUE_EANLA'
       EXPORTING
            bukrs = l_bukrs
            anln1 = l_anln2
            anln2 = l_anln3.
ENDIF.
Т.е. система будет пытаться поставить блокировку на созданный/изменный объект, если блокировка установилась, то мы ее тут же снимаем и идем обрабатывать следующие данные, так как запись точно уже существует в БД.

Оффлайн bdmalex

  • Newbie
  • *
  • Сообщений: 79
  • Репутация: +2/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Качественная телефония по разумной цене...
Re: Оптимизация ABAP-а
« Ответ #29 : Август 21, 2008, 05:11:40 pm »
You are not allowed to view links. Register or Login
А номерок ноты? А то я что-то не нашел, о разных исправлениях ошибок есть... а саму программку где тянуть не находиться...

У меня нет 4.x....Но в блокноте записан номер ноты: You are not allowed to view links. Register or Login ...подходит ??

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #30 : Август 21, 2008, 05:35:33 pm »
You are not allowed to view links. Register or Login
...подходит ??
Подходит конечно  ;)

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #31 : Октябрь 09, 2008, 10:25:00 pm »
Не совсем может и оптимизация, но точно про ABAP будет  ;)

Сегодня тут протормозил при вставке записей в свою Z-таблицу. Короче в таблице уже есть некоторое количество данных. Вставляю программно еще парочку, первая запись вставляется, вторая нет, потом еще пара других без проблем заливаются в таблицу. Вставку делаю оператором MODIFY <tab_name>, в цикле. Тупо не мог понять почему оно не отрабатывает, при этом код ошибки 4 (вставка дублирующей записи и это при MODIFY). Короче оказалось что то ли рука дрогнула вчера поздно уже было, то ли еще чего, но вместо просто дополнительного индекса, почему-то создал уникальный индекс. На несчастье, по полю уникального индекса, как раз данные были уникальные и этот индекс создался в тот момент без вопросов,, а я как-то не обратил внимание. Короче проблемы начались утром следующего дня ::) Однако, потребовался перекур и тупо смотрение в код, с мыслью то ли лыжи не едут, то ли снега просто еще нет.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а (Хинты)
« Ответ #32 : Октябрь 23, 2008, 10:40:26 am »
В общем-то иногда нужно в запросе сказать какой индекс использовать при запросе из базы данных. Админы конечно этого сильно не любят, типа оптимизатор должен сам решать как делать выборку +  админ если что сам порулит этим процессом, а вот при жесткой привязке индекса этого уже не сделаешь. В общем на усмотрение разработчика. Пример для оракловой базы. Будет использоваться индекс "T".
Код: You are not allowed to view links. Register or Login
   SELECT * UP TO 10 ROWS FROM mara
                          WHERE MTART = 'HAWA' AND
                                MATKL = '100'
                          %_HINTS ORACLE 'index(mara"T")'.

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #33 : Ноябрь 13, 2008, 07:18:15 pm »
По поводу вложенных запросов.
 
Код: You are not allowed to view links. Register or Login
SELECT mseg~mblnr mseg~mjahr mseg~zeile mseg~bwart mseg~xauto
         mseg~matnr mseg~werks mseg~lgort mseg~insmk mseg~shkzg
         mseg~dmbtr mseg~bwtar mseg~menge mseg~bustm mkpf~budat
    INTO TABLE lt_mseg
    FROM mseg JOIN mkpf ON mkpf~mblnr = mseg~mblnr AND
                           mkpf~mjahr = mseg~mjahr
    WHERE mseg~matnr IN s_matnr
      AND mseg~werks IN s_werks
      AND mseg~lgort IN s_lgort
      AND mseg~sobkz = ' '
      AND mseg~smbln = ' '
      AND mkpf~budat IN r_date
      AND NOT EXISTS ( SELECT * FROM *mseg WHERE smbln = mseg~mblnr
                                             AND sjahr = mseg~mjahr
                                             AND smblp = mseg~zeile ).

Известно, что при больших объемах данных, вложенные запросы существенно замедляют быстродействие основного. В приведенной выше выборке вложенный запрос отсекает сторнированные позиции д-тов движений материалов. При большом числе выбираемых позиций (>1000000) данная конструкция в плане быстродействия оказалась более предпочтительней, чем обычный запрос, с последующим отсечением сторно в цикле по полученным записям. Поскольку в позции прямого документа в таблице MSEG нет ссылки на сторнирующий, то в цикле по lt_mseg исключение сторно приходится делать единичной выборкой из MSEG (SELECT SINGLE ...) и при положительном ее результате (sy-subrc = 0) - удаление позиции из вн. таблицы. Единичная выборка в цикле (даже по ключу) и переиндексация lt_mseg при удалении из нее записи оказались неприемлемыми (дамп по таймауту). Вот такой вот частный случай.     
« Последнее редактирование: Ноябрь 13, 2008, 07:19:59 pm от Dmitriy »

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #34 : Ноябрь 14, 2008, 12:06:09 pm »
Использование вспомогательных вн. таблиц с оператором READ ... BINARY SEARCH.
Необходимое и достаточное условие: устраивающий объем оперативной памяти, выделенной пользователю на сервере приложений (отсутствие дампа по переполнению).
В приведенном выше посте мы получили вн. таблицу lt_mseg с позициями д-тов движений материалов. Как оптимальнее добавить краткие наименования ЕИ материала (в эту же или итоговую таблицу)? Перед основным запросом делаем ряд доп. выборок, в нашем случае, например:
Код: You are not allowed to view links. Register or Login
* Единицы измерения
  SELECT mara~matnr t006a~mseh3 INTO TABLE gt_meins FROM mara
                       JOIN t006a ON mara~meins = t006a~msehi
                                  WHERE mara~matnr IN s_matnr
                    AND t006a~spras = sy-langu ORDER BY mara~matnr.
Затем, в цикле по lt_mseg вместо SELECT SINGLE ... мы пользуемся оператором READ TABLE gt_meins WITH KEY matnr = <fs_mseg>-matnr BINARY SEARCH (используется LOOP AT lt_mseg ASSIGNING <fs_mseg>). Т.о. быстродействие цикла можно увеличить на 10-15%, поскольку в течение несколькомиллионных итераций мы обращаемся не к серверу БД, а уже исключительно к серверу приложений.
Примечание: для корректной работы BINARY SEARCH вн. таблица (в нашем случае - gt_meins) должна быть отсортирована по ключу, который используем в операторе READ (см. help).   
« Последнее редактирование: Ноябрь 14, 2008, 12:08:11 pm от Dmitriy »

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #35 : Ноябрь 14, 2008, 12:31:11 pm »
В догонку к примечаниям: перед оператором READ ... в том же цикле по lt_mseg ЕИ и количества материалов были трансформированы в "стандартные" (из пачек в "ШТ." в данном случае) посредством соотв. ФМ.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #36 : Ноябрь 15, 2008, 08:57:49 pm »
You are not allowed to view links. Register or Login
В догонку к примечаниям: перед оператором READ ... в том же цикле по lt_mseg ЕИ и количества материалов были трансформированы в "стандартные" (из пачек в "ШТ." в данном случае) посредством соотв. ФМ.
Соответствующий ФМ описан тут: You are not allowed to view links. Register or Login  ;)

Оффлайн NachDenken

  • Newbie
  • *
  • Сообщений: 158
  • Репутация: +9/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #37 : Декабрь 08, 2008, 02:49:37 pm »
Есть большое сомнение, что 2 выборка по mseg в таком виде будет работать быстро, недавно как раз был случай, что такая именно конструкция работала _очень_ медленно, не смотря на то, что и индекс по сторно был, и выборка шла по номеру документа+год материала (по ключу),
спасло: дополнительные условия на mseg поля ebeln ebelp

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #38 : Декабрь 08, 2008, 03:03:09 pm »
You are not allowed to view links. Register or Login
Есть большое сомнение, что 2 выборка по mseg в таком виде будет работать быстро, недавно как раз был случай, что такая именно конструкция работала _очень_ медленно, не смотря на то, что и индекс по сторно был, и выборка шла по номеру документа+год материала (по ключу),
спасло: дополнительные условия на mseg поля ebeln ebelp
Не вопрос, замеры нам помогут. Нет под рукой системы! :(
Ну на более, чем миллион записей выборка "сыграла".
« Последнее редактирование: Январь 26, 2010, 12:20:20 am от Dmitriy »

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #39 : Декабрь 08, 2008, 03:16:23 pm »
You are not allowed to view links. Register or Login
Есть большое сомнение, что 2 выборка по mseg в таком виде будет работать быстро, недавно как раз был случай, что такая именно
Это имелось в виду конструкция с:
Код: You are not allowed to view links. Register or Login
AND NOT EXISTS ( SELECT * FROM *mseg WHERE smbln = mseg~mblnr
                                             AND sjahr = mseg~mjahr
                                             AND smblp = mseg~zeile ).

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #40 : Декабрь 08, 2008, 03:18:28 pm »
Да, похоже именно эта. MKPF join MSEG вообще темная тема, индексы нужно делать, иначе...
« Последнее редактирование: Декабрь 08, 2008, 03:21:16 pm от Dmitriy »

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #41 : Декабрь 08, 2008, 03:26:05 pm »
You are not allowed to view links. Register or Login
Да, похоже именно эта. MKPF join MSEG вообще темная тема, индексы нужно делать, иначе...
Ну например можно ораклово (ну если там оракл) таблицу вынести на отдельный раздел, на отдельном диске... и уже это добавит производительности в выборке. А вообще подселекты, вещь тоже темная и как их оптимизатор разрулит, нужно смотреть в каждом отдельном случае.

Оффлайн NachDenken

  • Newbie
  • *
  • Сообщений: 158
  • Репутация: +9/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #42 : Декабрь 08, 2008, 05:10:06 pm »
в пред случае имелось в виду двойная выборка по mseg, про оптимизацию верно, каждый своим опытным путем.
вот тут недавно было, про то, что сначало сделать выборку (select) а потом по внут таблице Read table ...binary , сама сортировать по ключам нужно, а это иногда тоже время требует, если данных много.
вот и призадумаешься, может лучше все таки _дернуть_ из базы select single по ключам чем read table

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а
« Ответ #43 : Декабрь 08, 2008, 05:34:23 pm »
You are not allowed to view links. Register or Login
вот и призадумаешься, может лучше все таки _дернуть_ из базы select single по ключам чем read table
Ну тут в каждом случае надо смотреть отдельно... если памяти хватает, то врядли READ SINGLE будет быстрее, хотя конечно если там одно и тоже читается, т.е. например для 100 записей реально будет только 10 различных чтений данных, тогда скорее всего что данные при SELECT будут браться из кэша, что возможно будет быстрее чем выборка с последующей сотрировкой... короче в каждом случае надо смотреть на данные и сервер на котором все это работает.

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #44 : Декабрь 09, 2008, 03:57:26 am »
Да и вообще, всего не предугадаешь и всего знать невозможно, оно же по крупицам собирается, с опытом приходит. Мой добрый совет: если это возможно, то лучше прийти к базисникам, познакомиться/поговорить с мужиками, глядишь и помогут, главное не стесняться. ;) Было много случаев, например, когда "перепахивали" систему, вычислили проги, которые пару раз запустили за год, и все... Базис просто инфу дал, когда попросили. С теми же индексами... (с): Опыт сын ошибок трудных. :)     

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: Оптимизация ABAP-а
« Ответ #45 : Декабрь 09, 2008, 04:07:41 am »
You are not allowed to view links. Register or Login
Есть большое сомнение, что 2 выборка по mseg в таком виде будет работать быстро, недавно как раз был случай, что такая именно конструкция работала _очень_ медленно, не смотря на то, что и индекс по сторно был, и выборка шла по номеру документа+год материала (по ключу),
спасло: дополнительные условия на mseg поля ebeln ebelp
У меня вообще долго крутился отчет, самый "энергоемкий" был, т.к. начальству хотелось "всю информацию" сначала в общем виде, а потом с детализацией в гриде. Миллионы записей - это что-то))) А со сторно разрулилось по-другому: разнесли по видам движений. На использовании упомянутой мной конструкции не настаиваю, но реально замеры показали, что она в моем случае работала быстрее. Хотя тут больше скажут MM-щики, я таки ABAP-ер и насколько понимаю, часть видов движений стандартна, но можно свои настроить. ;)  
« Последнее редактирование: Декабрь 09, 2008, 04:12:09 am от Dmitriy »

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Использование внутренних таблиц типа SORTED
« Ответ #46 : Январь 13, 2009, 03:29:33 pm »
Код: You are not allowed to view links. Register or Login
*&---------------------------------------------------------------------*
*& Report  YXXX
*&---------------------------------------------------------------------*
*& Данный отчет - тестовый, для отладки всевозможных ситуаций
*&---------------------------------------------------------------------*
REPORT yxxx.
* Для заголовков
TYPES: BEGIN OF t1,
  bukrs TYPE bukrs,
  belnr TYPE belnr_d,
  gjahr TYPE gjahr,
* Здесь еще какие-нибудь наши поля
* ................,
  END OF t1.
* Для позиций
TYPES: BEGIN OF t2,
  bukrs TYPE bukrs,
  belnr TYPE belnr_d,
  gjahr TYPE gjahr,
  buzei TYPE buzei,
  buzid TYPE buzid,
* Здесь еще какие-нибудь наши поля
* ................,
  sgtxt TYPE sgtxt,
  END OF t2.
* Таб. заг., ее в нашем случае можно было бы объявить произвольно
DATA: gt_h TYPE SORTED TABLE OF t1
      WITH UNIQUE KEY bukrs belnr gjahr. " Заголовки
* Таб. позиций, объявляем именно так
DATA: gt_p TYPE SORTED TABLE OF t2
      WITH UNIQUE KEY bukrs belnr gjahr buzei. " Позиции
* Рабочую область таблицы позиций объявляем так для иллюстрации примера
* классического использования оператора ASSIGN, можно найти в примерах:
* SE80-)>Среда-)>Примеры-)>Примеры производительности-)>Internal tables
* -)>Using the Assigning Comand. Для таблицы заголовков можно было бы
* обойтись обычной Work area:
* DATA: gs_h LIKE LINE OF gt_h.
FIELD-SYMBOLS: <gs_h> LIKE LINE OF gt_h,
               <gs_p> LIKE LINE OF gt_p.
*&---------------------------------------------------------------------*
START-OF-SELECTION.

  PERFORM selection. " Выбор данных

  PERFORM processing. " Обработка данных

END-OF-SELECTION.

* Далее - процедура изменения FI-документов в БД

*&---------------------------------------------------------------------*
*&      Form  SELECTION
*&---------------------------------------------------------------------*
FORM selection.
* Выбор из БД
ENDFORM.                    " SELECTION
*&---------------------------------------------------------------------*
*&      Form  PROCESSING
*&---------------------------------------------------------------------*
FORM processing.

  LOOP AT gt_h INTO <gs_h>.
* { Здесь какая-либо обработка
* ..........................
* Конец обработки }
    LOOP AT gt_p ASSIGNING <gs_p> WHERE bukrs = <gs_h>-bukrs
                                                      AND belnr = <gs_h>-belnr
                                                      AND gjahr = <gs_h>-gjahr.
* { Здесь какая-либо обработка
* ..........................
* Конец обработки }
      IF <gs_p>-buzid NE space. " Позиция контрагента
* Замена текста позиции (MODIFY строки вн.табл.)
        <gs_p>-sgtxt = 'Добавлено из старой системы'.
      ENDIF.
    ENDLOOP.
  ENDLOOP.

ENDFORM.                    " PROCESSING
В данном случае, при использовании вложенного цикла, происходит уменьшение числа итераций засчет соответствующего объявления вн. таблицы позиций. В противном случае, не смотря на условие WHERE, происходит полный перебор всех записей таблицы gt_p.
« Последнее редактирование: Январь 13, 2009, 05:11:32 pm от Dmitriy »

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Re: Оптимизация ABAP-а (Грабли с SELECT)
« Ответ #47 : Январь 22, 2009, 10:41:06 pm »
В общем не совсем оптимизация, но скажем так грабли с небольшой ручкой, проявились на системе 4.6 операционка HP-UX версии 11.31, база Oracle версия 10.хх с хвостиком, на системе где Oracle 9.xx с хвостиком такого эффекта не наблюдалось, так что скорее всего это похоже грабли от оракловой базы. И так что и как было.

1. Есть своя Z-табличка, есть свои программки, которые туда чего-то пишут, а другие чего-то читают. В какой-то момент надо было добавить поле, тип поля NUMC. Добавил поле, к примеру R_FILE TYPE MY_DATA, где в словаре определено как MY_DATA(5) TYPE n. Ясное дело таблицу переактивировал, через утилиту базы данных сделал адаптацию с сохранением значений.
2. Написал программку, которая для некоторых записей из таблички заполнила новое поле R_FILE нужными значениями.
3. Перенес все это дело в продуктивную систему, там тоже для части полей заполнил данные в новое поле.

А вот дальше началось интересное, запрос вида:
SELECT * INTO lt_my_table FROM my_table
WHERE R_FILE = space.
На выходе получаю SY-SUBRC = 4.
==========
SELECT * INTO lt_my_table FROM my_table
WHERE R_FILE = 0.
На выходе получаю SY-SUBRC = 4.
==========
SELECT * INTO lt_my_table FROM my_table
WHERE R_FILE = '0'.
На выходе получаю SY-SUBRC = 4.
==========
SELECT * INTO lt_my_table FROM my_table
WHERE R_FILE = '00000'.
На выходе получаю SY-SUBRC = 4.

Короче, выбрать пустые записи, которые просто запросом SELECT * INTO lt_my_table FROM my_table выбираются кучей и при просмотре показываются как '0' или как '00000', выбрать никак не получается при прямом указании значения, хотя теоретически по равно space, должно было бы выбраться. При этом если сделать:

SELECT * FROM my_table.
  IF my_table-r_file = space.
*  Сюда заходит и именно вот те самые пустые записи типа находятся
*  причем можно было бы написать IF my_table-r_file = '0', и тоже заходит
  ENDIF.
ENDSELECT.

Короче, пришлось сделать вторую программку вида:
SELECT * FROM my_table.
  IF my_table-r_file = space.
    my_table-r_file = '0'.
    MODIFY my_table.
  ENDIF.
ENDSELECT.
COMMIT WORK.

После чего все типа заработало... кстати, самое интересное, что на версии Oracle 9 с хвостиком (система разработки), такого эффекта не наблюдается, ну правда сюда поле не транспортом попало, но в принципе это похоже не важно, так как адаптация таблицы, через утилиту базы данных делалась по аналогии с продуктивом. Причем если записи вставлять после добавления этого нового поля, то такие записи находятся запросом равно space или равно ноль, без проблем.

В общем вот такая вот грабелька попалась, т.е. состояние добавленного поля в таблицу для уже существующих записей для поля типа NUMC (другие не проверял) вообще какое-то не определенное в базе данных, причем после считывания оно корректно конвертируется в space/0 и уже при проверке в IF все корректно, но вот выбрать такие поля SELECT-от ну никак не получается, а ощущения, типа SE16 просмотреть все... вот она запись, ставишь на селекционном экране поле равно пустому значению, а она говорит нет значений для показа и некоторое время чувствуешь себя типа а где это я, а как это я  ???

Оффлайн Паганель

  • Я НЕ ЗАНИМАЮСЬ SAP
  • Administrator
  • Full Member
  • *****
  • Сообщений: 1 367
  • Репутация: +20/-0
  • Пол: Мужской
  • https://noteifyapp.com
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • MacPlus Software
Re: Оптимизация ABAP-а
« Ответ #48 : Январь 22, 2009, 10:47:58 pm »
а не проходит where r_file is null ?
You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login

Оффлайн Паганель

  • Я НЕ ЗАНИМАЮСЬ SAP
  • Administrator
  • Full Member
  • *****
  • Сообщений: 1 367
  • Репутация: +20/-0
  • Пол: Мужской
  • https://noteifyapp.com
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • MacPlus Software
Re: Оптимизация ABAP-а
« Ответ #49 : Январь 22, 2009, 10:50:04 pm »
 как по мне так правильно выбирать .... хотя сам помню когда-то сидел пытался выбрать по условию что поле типа дата пустое ..... самое интересное, сюда не написал .... а теперь не помню ....
кажись писал WHERE docdate = '' ....
You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login

Sapforum.Biz

Re: Оптимизация ABAP-а
« Ответ #49 : Январь 22, 2009, 10:50:04 pm »