ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / MDX Performance
7 сообщений из 7, страница 1 из 1
MDX Performance
    #39950623
Oleon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleon
Участник
Странное поведение запроса.

Код: 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
23.04.2020, 17:17
| Ответить | Цитировать | Написать  
MDX Performance
    #39950774
ShIgor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ShIgor
Участник
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, 02:43
| Ответить | Цитировать | Написать  
MDX Performance
    #39950931
Oleon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleon
Участник
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, 12:41
| Ответить | Цитировать | Написать  
MDX Performance
    #39951001
ShIgor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ShIgor
Участник
Oleon,

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

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

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

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

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

Код: 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
25.04.2020, 20:36
| Ответить | Цитировать | Написать  
7 сообщений из 7, страница 1 из 1
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / MDX Performance
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=49&fpage=8&tid=1857333]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 37ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 50ms
get tp. blocked users:
 2ms
others: 228ms
total:  359ms
созд. / загр.: 359ms
x
x
Закрыть


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