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

111

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

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

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

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

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

dol_vv

Очень просто.
Может.
В ST05/st01/st04 посмотреть трассировку. Вообще говоря, нужно сравнить планы запросов. Запросто может случиться, что один из селектов идет с одним планом по одному индексу, а другая выборка например, попадает на фулскан... Это как вариант.

ЗЫ А вообще, нужно смотреть код.

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

(сорри, немного криво вырезал SQL - обрезан правый край, пока не могу поправить - пытаюсь дождаться выборки за 2 дня).

Окончания выборки хотя бы за 2 дня пока ни разу не удалось дождаться :-(

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

Vadimus

Во первых можно через SM50 посмотреть рабочий процесс, какой SQL-запрос выполняется.
Во вторых через ST04->button Detail analisis menu->SQL Request там найти свой запрос и посмотреть его план выполнения: два раза на него кликнуть, появится окошко и на нем есть кнопка Display execution plan
Главное, чтобы в этом плане не было Table Full Scan

111

Мдя, чудеса.
План при выборке по периоду в 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 )

Индекс S987~VAB
MANDT
MATNR

Задействует, видимо как раз из-за разрыва ключа (выпадает VBELN).
Но насколько я понимаю, при выборке по одному дню 03.09.2007 этот индекс не задействуется, а по периоду 03.09.2007-04.09.2007, система определяет, что необходимо пройтись этим индексом рейндж сканом по всей таблице (общее количество записей в таблице - как раз порядка 57-58 миллионов) .

ЗАЧЕМ?!

:shock:

Vadimus

Мне кажется конструкция BETWEEN очень затратная по ресурсам получается...
Как предположение: она смторит все >=03.09.2007 и все <=04.09.2007... вот и получаются все записи в таблице

может BETWEEN заменить другой конструкцией...

111

Vadimus написал:

Мне кажется конструкция BETWEEN очень затратная по ресурсам получается...
Как предположение: она смторит все >=03.09.2007 и все <=04.09.2007... вот и получаются все записи в таблице

может BETWEEN заменить другой конструкцией...

Так ведь SPTAG - всего лишь пятое поле в ключе! И все ключевые поля до него указаны в условии.
По логике - определила область, где начинается SPTAG = 20070903 и заканчивается 20070904, и пошла по ней. Нафига в другие области лезть?!

Vadimus

Так он этот ключ то (S987~0) и не использует...

111

Vadimus написал:

Так он этот ключ то (S987~0) и не использует...

Вот и странно - почему?
При выборке по одному дню - использует только первичный ключ. При выборке по периоду хотя бы в 2 дня - уже цепляет какой-то левый индекс.

Vadimus

нашел ссылочку, каким образом оптимизатор смотрит на конструкции: самое оптимальное было ROWID=const (что ествественно), потом типа "Поле индекса"=const, так вот конструкция BETWEEN по полю уникального индекса и по полю неуникального индекса были на 12 и 13 месте. Соответственно оптимизатор как-то делает вывод, что смотреть по тому индексу дату не оптимально и выбирает другие пути...
Можно построить новый индекс по полю SPTAG и посмотреть, что будет. Можно разбить на два запроса, сначала по дате, а потом всё остальное...
Такое ощущение, что он банально выбирает все записи из индекса ~VAB по полю MANDT (что скорее всего есть вся таблица, если это продуктив), а потом к каждой записи примеряет все остальные условия...

Vadimus

Rules for rule-based optimizer.
Rank Where clause predicates
1 ROWID = constant
2 unique indexed column = constant
3 entire unique concatenated index = constant
4 entire cluster key = cluster key of object in same cluster
5 entire cluster key = constant
6 entire nonunique concatenated index = constant
7 nonunique index = constant
8 entire noncompressed concatenated index >= constant
9 entire compressed concatenated index >= constant
10 partial but leading columns of noncompressed concatenated index
11 partial but leading columns of compressed concatenated index
12 unique indexed column using the SQL statement BETWEEN or LIKE options
13 nonunique indexed column using the SQL statement BETWEEN or LIKE options
14 unique indexed column < or > constant
15 nonunique indexed column < or > constant
16 sort/merge
17 MAX or MIN SQL statement functions on indexed column
18 ORDER BY entire index
19 full table scans

dol_vv

Цитата:

Rules for rule-based optimizer.

- а причем здесь "руля"?

Вам указаны планы, в планах написан "costs", отсюда можно предположить, что система использует CBO. В свою очередь, CBO использует совершенно другой алгоритм. Автор топика даже не сообщил тип базы. Это "к слову".

To 111
Практически, чтобы Вам сильно не заморачиваться попробуйте:
Если СУБД Oracle
1) Дописать в запрос оракловый хинт на тот индекс, который Вам больше нравится. Для того, чтобы понять как это делается в service.sap.com -> notes поищите по ключевым словам oracle hint

например так как в первой попавшейся ноте 130480:
SELECT * FROM RESB
WHERE MATNR = '200-100' AND WERKS = '1100'
%_HINTS ORACLE 'INDEX("&TABLE&" "RESB~M" "RESB^M")'.

Сравните теперь даже не планы, а скорость выполнения запроса. Планы тоже не плохо...

2) При необходимости можно создать дополнительный индекс(ы). Если все правильно, то оптимизатор сам поймет, какой индекс ему нужно использовать.

ЗЫ На самом деле, SAP очень сильно лукавит в том плане, что сам всевозможные системные запросы часто хинтует.

ЗЫ ЗЫ Лично я делаю не так. В ST04 отслеживаю интересующий меня запрос, далее получаю его план специальными оракловыми тулзами, далее при необходимости создаю индекс(ы) и как положено, переносами запузыриваю в продуктив. Так эконимится масса времени по сравнению с трассами в ST05. Если бы я таким вот образом трассировал каждую "Z~дрянь"... мдя. :shock:

111

dol_vv написал:

Автор топика даже не сообщил тип базы. Это "к слову".

Сорри, исправляюсь, ORACLE .

Цитата:

1) Дописать в запрос оракловый хинт на тот индекс, который Вам больше нравится.
2) При необходимости можно создать дополнительный индекс(ы).

Да, уже сделал это. Только-только индекс сактивировался (все ж 60 лимонов записей), поэтому только сейчас отвечаю.
Теперь выполняется как надо.

На самом деле, мне в принципе было интересны причины такого странного поведения.

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

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

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