Как такое может быть?! Быстродействие.

111

То ли лыжи не едут, то ли... на пенсию пора :roll:

Делаю выборку из достаточно большой таблицы – размер порядка 100 млн.записей.
Это инфосистема, с квантом времени день, соответственно ограничиваю по SPTAG (дата).
Разумеется, в условии выборки присутствуют также все остальные ключевые поля.
Также используется агрегатная функция SUM для нескольких полей (понятно, с GROUP BY).

Когда делаю выборку по одному дню, скоростью выполнения радует.
Отрабатывает буквально в течении секунды. При том, что выбирает приличный объем данных (2-5 тысяч записей, каждая из них - агрегированная по нескольким полям).
По всем дням порядок количеств записей одинаков (2-5 тысяч, как написал выше), по всем дням в отдельности время выполнения не больше 1 секунды.
Логично предположить, что за месяц выборка должна бы занимать не больше 30 секунд.

ФИК!
Если попытаться сделать выборку за период хотя бы всего за 2 дня (BETWEEN ‘20070903’ AND ‘20070904’) – все подвисает, и очень надолго (хотя если последовательно запустить по каждому из дней – получится не больше 2 секунд).
Понятно, что раз такая петрушка - можно сделать выборку по месяцу не цельную, а разбить ее на 30 (31) частей по каждому из дней месяца.

Но хочется разобраться. КАК ТАКОЕ МОЖЕТ БЫТЬ?!
:shock:

111

Еще.
Может быть, кто-нибудь объяснит, почему в ALV Grid'e (CL_GUI_ALV_GRID через метод set_table_for_first_display) суммарная строка может упорно рисоваться после массива суммируемых строк (т.е. внизу), а не перед ними (т.е. вверху).

Несмотря на то, что
LVC_S_LAYO-TOTALS_BEF = 'X' .

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

John Doe

111 написал(а):

... почему в ALV Grid'e (CL_GUI_ALV_GRID через метод set_table_for_first_display) суммарная строка может упорно рисоваться после массива суммируемых строк (т.е. внизу), а не перед ними (т.е. вверху).
Несмотря на то, что
LVC_S_LAYO-TOTALS_BEF = 'X' .

Я могу предположить что это либо "злобный глюк", либо при вызове set_table_for_first_display в параметре не передается (либо передается, но не та) структурка LVC_S_LAYO. Проверьте точно вызов, иногда когда в программе несколько гридов и/или при копи-пастинге забываешь все подправить до нужного состояния. Моё резюме: скорее всего просто ошибка в коде.

ЗЫ А по первому вопросу - можно код выборки посмотреть?

Jelena

111 написал(а):

Но хочется разобраться.

Надо бы добраться до Execution plan для каждого варианта. Это можно сделать через ST05 или ST04.

И на всякий случай проверьте еще раз свой код и его соответствие индексу в каждой среде (если используете разные). У нас один раз в одной info structure каким-то образом порядок полей оказался разный в DEV и QAS.

dump

On ORACLE databases, a WHERE condition with BETWEEN is evaluated together with the costs for reading 5 % of all index blocks and table blocks, regardless of the size of the BETWEEN interval. If the BETWEEN interval is sufficiently small, then you can replace WHERE <field> BETWEEN <value 1> AND <value 2> by WHERE <field> IN (<value 1> ,... , <value n>), or alternatively by WHERE <field> IN <range_tab>.

vga

111 написал(а):

Еще.
Может быть, кто-нибудь объяснит, почему в ALV Grid'e (CL_GUI_ALV_GRID через метод set_table_for_first_display) суммарная строка может упорно рисоваться после массива суммируемых строк (т.е. внизу), а не перед ними (т.е. вверху).

Несмотря на то, что
LVC_S_LAYO-TOTALS_BEF = 'X' .

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

Там случайно дефолтовый layout не цепляется?

John Doe

vga написал(а):

Там случайно дефолтовый layout не цепляется?

+1. При вызове disvariant используется?

111

Цитата:

Дефолтовый вариант цепляется.

Но то, что в варианте не настраивается - разве может сохраняться при сохранении варианта?

Млин, и правда :evil:

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

111

dump написал(а):

On ORACLE databases, a WHERE condition with BETWEEN is evaluated together with the costs for reading 5 % of all index blocks and table blocks, regardless of the size of the BETWEEN interval. If the BETWEEN interval is sufficiently small, then you can replace WHERE <field> BETWEEN <value 1> AND <value 2> by WHERE <field> IN (<value 1> ,... , <value n>), or alternatively by WHERE <field> IN <range_tab>.

Ага, вот это кажется оно, спасибо.

На самом деле, для ограничения по датам используется ranges . Когда Options = BT, оно преобразуется в BETWEEN в SQL .
Млин, это что ж получается? :roll:

Для выборок из всех больших таблиц, анализировать Ranges и, если там BT - раскатывать в отдельные значения?!
Млин. :roll:

Самое странное - почему же раньше ни с чем подобным не сталкивался? Та же MSEG больше на порядок.

Snegurenok

дык а betwen в ранж засунуть не судьба ?

I BT Low High

ArmAnn

111 написал(а):

Ага, вот это кажется оно, спасибо.

На самом деле, для ограничения по датам используется ranges . Когда Options = BT, оно преобразуется в BETWEEN в SQL .
Млин, это что ж получается? :roll:

Для выборок из всех больших таблиц, анализировать Ranges и, если там BT - раскатывать в отдельные значения?!
Млин. :roll:

Самое странное - почему же раньше ни с чем подобным не сталкивался? Та же MSEG больше на порядок.

А планы запросов то смотрели? Какие индексы подхватываются, заодно глянуть как давно статистика по ним собиралась... может там собака порылась

111

Snegurenok написал(а):

дык а betwen в ранж засунуть не судьба ?

I BT Low High

Цитата:

На самом деле, для ограничения по датам используется ranges . Когда Options = BT, оно преобразуется в BETWEEN в SQL .

vga

Без селекта и плана выполнения запроса для обоих случаев - пальцем в небо тыкать :cry:

N/A

Цитата:

Логично предположить, что за месяц выборка

Если нужна выборка именно за месяц, можно ограничить выбор

Code:

where SPTAG like 'YYYYMM%'

111

Планы выполнения смотрел, но если честно, ничего не понял.

Code:

    
  SELECT  sptag
          matnr
          pkunag AS kunag
          valdt
     SUM( fkimg ) AS menge
     SUM( netwr )
     SUM( kzwi6 ) AS sebest
    FROM s987
                  INTO TABLE ltd_s987
   WHERE ssour = space
     AND vrsio = '000'
     AND spmon = '000000'
     AND sptag IN s_date
     AND spwoc = '000000'
     AND spbup = '000000'
     AND werks IN s_werks
     AND bukrs EQ '1000'
     AND vkorg = '1000'
     AND vtweg IN ('10', '20')
     AND fkart = 'FP'
     AND pkunag IN ltr_kunag
  GROUP BY sptag
           matnr
           pkunag
           valdt
             .

Ключ S987:

Code:

  
MANDT
SSOUR
VRSIO
SPMON
SPTAG
SPWOC
SPBUP
WERKS
BUKRS
VKORG
VTWEG
VBELN
FKART
PKUNAG
MATNR
POSNR

План запроса при выборке за один день:

Code:

SELECT
  "SPTAG" , "MATNR" , "PKUNAG" "KUNAG" , "VALDT" , SUM
  SUM( "NETWR" ) , SUM( "KZWI6" ) "SEBEST"
FROM
  "S987"
WHERE
  "MANDT" = :A0 AND "SSOUR" = :A1 AND "VRSIO" = :A2 AN
  "SPWOC" = :A4 AND "SPBUP" = :A5 AND "SPTAG" = :A6 AN
  "WERKS" = :A8 AND "VKORG" = :A9 AND "VTWEG" IN ( :A1
  :A12 AND "PKUNAG" IN ( :A13 , :A14 )
GROUP BY
  "SPTAG" , "MATNR" , "PKUNAG" , "VALDT"

SELECT STATEMENT ( Estimated Costs = 48 , Estimated #Rows = 1 )

       4 SORT GROUP BY
         ( Estim. Costs = 48 , Estim. #Rows = 1 )

           3 INLIST ITERATOR

               2 TABLE ACCESS BY INDEX ROWID S987
                 ( Estim. Costs = 2 , Estim. #Rows = 1 )

                   1 INDEX RANGE SCAN S987~0
                     ( Estim. Costs = 13 , Estim. #Rows = 1 )
                     Search Columns: 12

Это быстрая выборка, по одному дню, 03.09.2007 (выполняется за полсекунды).

Ниже выборка за период 03.09.2007 - 04.09.2007 .
Крутится уже часа 2 .

Code:

SELECT
  "SPTAG" , "MATNR" , "PKUNAG" "KUNAG" , "VALDT" , SUM( "FKIMG" ) "MENGE" , SUM( "NETWR" ) ,
  SUM( "KZWI6" ) "SEBEST"
FROM
  "S987"
WHERE
  "MANDT" = :A0 AND "SSOUR" = :A1 AND "VRSIO" = :A2 AND "SPMON" = :A3 AND "SPWOC" = :A4 AND "SPBUP"
  = :A5 AND "SPTAG" BETWEEN :A6 AND :A7 AND "BUKRS" = :A8 AND "WERKS" = :A9 AND "VKORG" = :A10 AND
  "VTWEG" IN ( :A11 , :A12 ) AND "FKART" = :A13 AND "PKUNAG" IN ( :A14 , :A15 )
GROUP BY
  "SPTAG" , "MATNR" , "PKUNAG" , "VALDT"#


Execution Plan

Explain from v$sql_plan: Address: 000000118A870EB0 Hash_value:  1499377273 Child_number:  0




 SELECT STATEMENT ( Estimated Costs = 130 , Estimated #Rows = 0 )

        4 SORT GROUP BY
          ( Estim. Costs = 130 , Estim. #Rows = 2 )

            3 FILTER

                2 TABLE ACCESS BY INDEX ROWID S987
                  ( Estim. Costs = 83 , Estim. #Rows = 2 )

                    1 INDEX RANGE SCAN S987~VAB
                      ( Estim. Costs = 26 , Estim. #Rows = 57.695.716 )

Ничего не понимаю.
До поля SPTAG в условии идет сплошной ключ.
Только у полей FKART, PKUNAG разрыв ключа в 1 поле (VBELN ну участвует в выборке и условии).

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

Как такое может быть?! Быстродействие.

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