Bex, проблемы производительности

evm

Всем привет.
BW 7.4 на Windows+MSSQL. Конкретно хромает производительность, особенно на сводных отчетах по нескольким кубам.
Вопросы:
1. Анализ производительности на серваке показывает, что каждый запрос использует ровно одно ядро, при полном простое остальных. Диалоговый процесс всегда работает только на одном ядре? Не существует какой-нибудь базисной/бивишной настройки, чтобы они использовал не одно, а все свободные ядра?

2. Не совсем понятно, что он там столько времени считает.
Ниже статистика на примере одного запроса. В отчете около 30 показателей по нескольким кубам.
Ид. события___Текст события___________Продолжит.___Счетчик_____Счетчик события
9000__________Диспетчер данных________93,51________0___________24
3110__________OLAP: выбор данных______0,43________0____________1
3200__________OLAP: перенос данных____0,14________2 286________1
9010__________Сумма DBTRANS___________0,00________18 197_______1
9011__________Сумма DBSEL_____________0,00________2 514 660____1

Шаг 9000 выполняется больше полутора минут. Шаг 9000 - это именно считывание данных из БД или это их дальнейшая обработка/агрегация/расчеты? Из шага 9011 видно, что считывается около 2.5 млн записей. Как-то долго для такого количества. Сократить это количество я вряд ли смогу, все агрегаты и так уже собраны.

Любые советы, где искать затык в производительности, приветствуются.

murmur

Тр. SAT и ST05 в первую очередь,
а также нота 1681396 - Query Performance

evm

После массы экспериментов, выкидывания лишних данных и т.д. - пришел к довольно простому и совершенно парадоксальному примеру.
Выглядит так, что наличие агрегата в кубе не увеличивает, а уменьшает скорость выполнения, причем в десятки раз. Я такого вообще никогда не видел до сих пор.
Похоже, что какие-то траблы с индексами, но я даже не понимаю, в какую сторону копать, т.к. все таблицы и индексы присутствуют.
Конкретный пример такой:
есть куб остатков (без некумулятивов, данные хранятся на каждую дату), называется ZST_C01.
есть на нем агрегат, называется 100089.
В F-таблице куба около 82 млн записей, в F-таблице агрегата - около 34.
Один и тот же отчет без агрегата выполняется 3-4 секунды, с агрегатом - больше минуты! Причем это все в rsrt без использования кэша.

Ниже два sql-запроса, они вообще одинаковые и отличаются на одну строку "AND F.SID_0CALMONTH = DT.SID_0CALMONTH". Я проверил - дело не в этой строке, т.е. если в запрос по агрегату добавить эту строку, то он так же тормозит.

Запрос из куба без агрегатов - выполняется 3 секунды:

Code:

select DT.SID_0CALDAY AS S____166,
       D2.SID_0PLANT AS S____352,
       DU.SID_0LOC_CURRCY AS S____454,
       DU.SID_0BASE_UOM AS S____485,
       COUNT(*) AS Z____199_SUM,
       SUM( F.[/BIC/ZSTVALN]) AS Z____489_SUM,
       SUM( F.[/BIC/ZTOTSTQTY]) AS Z____490_SUM
  FROM [/BIC/FZST_C01] F
  JOIN [/BIC/DZST_C01T] DT
    ON F.KEY_ZST_C01T = DT.DIMID
   AND F.SID_0CALMONTH = DT.SID_0CALMONTH
  JOIN [/BIC/DZST_C012] D2
    ON F.KEY_ZST_C012 = D2.DIMID
  JOIN [/BIC/DZST_C01U] DU
    ON F.KEY_ZST_C01U = DU.DIMID
  JOIN [/BIC/DZST_C01P] DP
    ON F.KEY_ZST_C01P = DP.DIMID
  JOIN [/BIC/DZST_C011] D1
    ON F.KEY_ZST_C011 = D1.DIMID
 where (((( DT.SID_0CALDAY = 20150731)) AND
       ((DT.SID_0CALMONTH = 201507 AND F.SID_0CALMONTH = 201507)) 
        AND ((DP.SID_0CHNGID = 0)) AND
       ((D1.SID_0MATL_GROUP IN (8, 9, 11))) AND
       ((DP.SID_0REQUID <= 70676))))
 GROUP BY DT.SID_0CALDAY,
         D2.SID_0PLANT,
         DU.SID_0LOC_CURRCY,
         DU.SID_0BASE_UOM
 ORDER BY S____352 OPTION(MAXDOP 2)

Запрос из агрегата - выполняется больше минуты!

Code:

select DT.SID_0CALDAY  AS  S____166 ,
       D2.SID_0PLANT  AS  S____352 ,
       DU.SID_0LOC_CURRCY  AS  S____454 ,
       DU.SID_0BASE_UOM  AS  S____485 ,
       COUNT(*) AS  Z____199_SUM ,
       SUM( F.[/BIC/ZSTVALN]) AS  Z____489_SUM ,
       SUM( F.[/BIC/ZTOTSTQTY]) AS  Z____490_SUM 
  FROM [/BIC/F100089]  F 
  JOIN [/BIC/DZST_C01T]   DT 
    ON  F.KEY_ZST_C01T  =  DT.DIMID 
  JOIN [/BIC/DZST_C012]   D2 
    ON  F.KEY_ZST_C012  =  D2.DIMID 
  JOIN [/BIC/DZST_C01U]   DU 
    ON  F.KEY_ZST_C01U  =  DU.DIMID 
  JOIN [/BIC/D100089P]   DP 
    ON  F.KEY_100089P  =  DP.DIMID 
  JOIN [/BIC/D1000891]   D1 
    ON  F.KEY_1000891  =  D1.DIMID 
 where (((( DT.SID_0CALDAY  = 20150731)) AND
       (( DT.SID_0CALMONTH  = 201507 AND  F.SID_0CALMONTH
         = 201507)) AND (( DP.SID_0CHNGID  = 0)) AND
       (( D1.SID_0MATL_GROUP  IN (8, 9, 11))) AND
       (( DP.SID_0REQUID  <= 70676))))
 GROUP BY  DT.SID_0CALDAY ,
           D2.SID_0PLANT ,
           DU.SID_0LOC_CURRCY ,
           DU.SID_0BASE_UOM 
 ORDER BY  S____352  OPTION(MAXDOP 2)

Какие вообще есть варианты в такой ситуации? Что проверять?

murmur

Вы бы лучше планы выполнения запросов выложили, которые в ST05 получите - один для куба, а другой для агрегата. Надо смотреть именно планы, где стоимость операций и порядок соединения, а не просто SQL-текст. В ST05 можно и актуальность статистики проверить - там прямо даты показаны, когда она последний раз обновлялась (по крайней мере для Oracle это справедливо)

evm

Да, насчет планов - это резонно. Я их смотрел, не в ST05, а в выполнении запросов в DB02, они были абсолютно одинаковые, только разные F-таблицы подставлялись. В ST05 то же самое.
На самом деле, проблема решилась просто переактивацией и перезаполнением агрегатов.
И вот планы выполнения запроса до и после этой переактивации реально разные.

Если интересно:
До: http://my.jetscreenshot.com/demo/20150811-alnc-122kb
После: http://my.jetscreenshot.com/demo/201508 ... -253kb.jpg

Причем я специально проверил - индексы видны как созданные и активные, что через сап, что в консоли управления MSSQL. После переактивации никаких отличий в них я не нашел ни там ни там. Мистика какая-то.
Что с ними было и при каких условиях они в следующий раз перестанут работать (внешне изображая, что они есть) - непонятно.

murmur

Надо было еще и статистику смотреть, возможно ее просто требовалось обновить. Да и создавать агрегат при соотношении записей в кубе и агрегате - 82 к 34 затея, сама по себе, сомнительная. Еще такая вот любопытная нота есть 1951490 - SQL Server Column-Store for SAP BW Aggregates

evm

Смотрел я статистику, она была собрана месяц назад. Это куб исторических данных, туда данные в этот момент и заливались. Я ее принудительно обновил, но ничего не поменялось.
Да и вообще все эти танцы со статистикой - это борьба за проценты, максимум за десятки процентов. Но если производительность в 30 раз ниже, чем должна быть, то статистика тут не причем, тут что-то гораздо более глобальное. Имхо, разумеется.
А про размер агрегата - да, это так, но это лучше чем ничего. Для того, чтобы собрать компактные агрегаты, нужно чтобы пользователи были готовы смотреть данные в разных местах и по четко определенным разверткам. А это далеко не всегда возможно. Плюс это не единственный агрегат, а самый большой, есть и другие более узкие.
За ноту спасибо, почитаю.

murmur

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

evm

Хорошо, а про какую статистику речь и в какие моменты ее надо заполнять?
Насколько я понимаю, есть несколько ее типов:
1 - это то, что видно в администрировании куба, там где индексы. Она же заполняется процессом в цепочке. Это статистика по таблицам, индексам и т.д.
2 - это контентовские потоки и кубы, которые фиксируют запуск отчетов, время их выполнения и т.д.
Речь про первый вариант?
Если да, то эта статистика должна собираться после загрузки данных? Т.е. если в куб один раз залили исторические данные, собирали эту статистику и больше данные туда не грузятся, то потом ее нужно как-то периодически обновлять?

murmur

Да, речь про первый вариант. Если данные в куб не загружались, то статистика измениться не должна была (если ее, конечно, не вычистили преднамеренно на уровне БД). Но статистика могла потерять свою актуальность, например, если на кубе был агрегат, в него был включен навигационный атрибут, то тогда при прогоне изменения атрибутов признака будет происходить изменение агрегата и статистика таблиц агрегата, в принципе, должна меняться, то есть может стать неактуальной, хотя данные в куб не загружались

Bex, проблемы производительности

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