Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / MDX Performance / 7 сообщений из 7, страница 1 из 1
23.04.2020, 17:17
    #39950623
Oleon
Oleon
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MDX Performance
Странное поведение запроса.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
WITH 
SET LastYearMonth AS 
	STRTOSET("[Dim Time].[Year-Quater-Month-Date].&[2020-04-09T00:00:00]:[Dim Time].[Year-Quater-Month-Date].&[2020-04-22T00:00:00]")

--Revenue
MEMBER FactRevenue AS SUM(
	[Dim Time].[Year-Quater-Month-Date].PARENT.FIRSTCHILD:[Dim Time].[Year-Quater-Month-Date].CURRENTMEMBER
	,[Measures].[Revenue]
	)

SELECT 
	{
	FactRevenue
	}ON 0
	,{LastYearMonth} ON 1
FROM
	[fxCube]



Если для LastYearToMonth указать период больше 14-ти дней, то начинает сканировать все группы мер. Если меньше, то остается в текущей группе мер.

Получается так:
c 1-го по 14-е - быстро
с 1-го по 15-е медленно (сканирование всех групп мер)
с 2-го по 15-е быстро
с 9-го по 22-е быстро

В Группе мер 10 партиций по годам и текущая партицая за второй квартал 2020-го в каждой указан Slice и одна партиция на 10 лет c 2000 по 2010 в ней нет Slice. Последняя с 1-го апреля.

Есть ли какое-то ограничение на 14-ть дней? Из-за чего это может быть? куда можно покопать?

Спасибо
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.04.2020, 02:43
    #39950774
ShIgor
ShIgor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MDX Performance
Oleon,

Я с этим поведением встречаюсь уже давно, но объяснения тоже нигде пока не видел..
Возникает оно либо на пользовательских, либо на parent-child иерархиях.
Эффект который заставляет сканировать все партиции "срабатывает" при выборке >=50% членов уровня.
Для уровня месяц, это будет 5 членов - быстро, 6 и более - медленно. Для недели 3 члена - быстро, 4 и более - медленно.
Возможно есть еще и числовой, а не % порог, т.к. на измерениях не дат видел такое же поведение на 28 и выше членов.
С бОльшиим количеством членов не тестировал.
Исчезает после того как хотя бы один запрос после процессинга выполнится на этом уровне до конца. не обязательно охватывать всех членов на уровне, но половину надо точно (возможно кэш).
Обойти просто: использовать в определении сета атрибутную иерархию (у Вас скорее всего '[Dim Time].[Date].&[2020-04-09T00:00:00]:[Dim Time].[Date].&[2020-04-22T00:00:00]"). Для вычисляемого члена в этом случае сработает autoexists.
Отсутствие/наличие предрасчитанных агрегатов на атрибутах, которые составляют уровни, на эту ситуацию не влияет. Возможно это связано с отказом разработчиков от создания индексов на агрегатах (настройка AggIndexBuildEnabled=0, не путайте с индексами на партициях).

 
для любителей покопать поглубже
в профайлере при этом можно увидеть такие картины
для запроса с выборкой до 50% членов
<Subcube>
...
D:7(Дата) [1 * * + * * * * *] => ((All)):[All] (Год):* (Месяц):* (Дата):+ (Неделя):* (МесяцГода):* (ДеньНедели):* (Сегодня):* (НеделяГода):*
...
+ 73 (4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034)
</Subcube>
где 73 это индекс атрибута Дата, а в скобках индексы попавших в выборку элементов

и для запроса с выборкой >= 50% членов
<Subcube>
...
D:7(Дата) [1 13 134 * * * * * *] => ((All)):[All] (Год):[2020] (Месяц):[Апр 2020] (Дата):* (Неделя):* (МесяцГода):* (ДеньНедели):* (Сегодня):* (НеделяГода):*
...
</Subcube>
где 13 - индекс года, 134 индекс месяца, что соответствует году 2020 и месяцу Апр 2020 в моей базе
дальше читает все партиции несколько раз
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.04.2020, 12:41
    #39950931
Oleon
Oleon
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MDX Performance
Shlgor, спасибо!

Переделал вот так и стало работать быстро.
С флагом пока не экспериментировал.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
WITH 
SET LastYearMonth AS 
	STRTOSET("[Dim Time].[Date].&[2020-04-01T00:00:00]:[Dim Time].[Date].&[2020-04-22T00:00:00]")

--Revenue
MEMBER FactRevenue AS SUM(
	[Dim Time].[Date].&[2020-04-01T00:00:00]:[Dim Time].[Date].CURRENTMEMBER
	,[Measures].[Revenue]
	)


SELECT 
	{
	FactRevenue
	}ON 0
	,{LastYearMonth} ON 1
FROM
	[fxCube]
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.04.2020, 14:14
    #39951001
ShIgor
ShIgor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MDX Performance
Oleon,

MEMBER FactRevenue можно было оставить как есть.. было бы универсально.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.04.2020, 18:18
    #39951133
Oleon
Oleon
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MDX Performance
Класс! Спасибо!

Еще вопрос, пользуаясь возможностью.

До того, как не получалось ускорить отчет мы патались сделать кеширование, но при этом нужно, чтобы пользователи подключались к отчету под одним и тем же логином.
А возможно ли кешировать стандартными средствами, долгий запрос для куба, чтобы все под своим логином могли его использовать?

Отчет построен в репортинге, который дергает данные из куба.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.04.2020, 18:36
    #39951139
ShIgor
ShIgor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MDX Performance
Oleon,

Кэш хранится для каждой роли отдельно, если каждый пользователь у Вас в отдельной роли, значит для каждого пользователя необходимо запускать прогрев кэша. Средства стандартные. Просто если ролей много, то будет долго.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.04.2020, 20:36
    #39951466
Oleon
Oleon
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MDX Performance
У нас в кубе одна роль и права бьются по элементам измерения, в зависимости от имени пользователя. примерно так

Код: sql
1.
2.
3.
4.
5.
([Dim BU Structure].[Branch Key].MEMBERS,
                               
 (strtotuple("[Dim Admins].[Admins View].[" + Mid(UserName, InStr(UserName, "\") + 1) + "]")
                                
, [Measures].[Branch Access]) = 1



Так же, подобный подход, по правам на меры. Если прав нет, то мера видна, но значение не показывается.

Наверное, это как-то влияет на то, что кеш не используется, так как все кто запускает отчет ждут долго, но если я под своим логином запускаю отчет второй раз, то отчет отрабатывает быстро.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / MDX Performance / 7 сообщений из 7, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 195ms
Закрыть
start [/forum/topic.php?fid=49&mobile=1&tid=1857333]:
 0ms
get settings:
 10ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 65ms
get topic data:
 14ms
get forum data:
 3ms
get page messages:
 69ms
get tp. blocked users:
 2ms
others: 12ms
total:  195ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]