2015-04-22 7 views
0

Ниже мой запрос:MDX запросы ведет крутой с вырожденным измерением на CDE приборной панели

WITH 
    SET [sp] AS 
     ([time.fin].[day].[${parDate}]:[time.fin].[day].[${partoDate}]) 

SET [factory] AS 
    {[organization].[org].[Fact1],[organization].[org].[Fact2],[organization].[org].[Fact3]} 

MEMBER [btype].[b] AS 
    AGGREGATE(IIF('${param}'='All', 
        [btype].[type].members, 
        [btype].[type].[${param}] 
     ))  

SELECT 
NON EMPTY {[factory]} ON COLUMNS, 
NON EMPTY {[sp]}ON ROWS 
FROM [cube1] 
WHERE ([btype].[b], [Measures].[qty]) 

в этом BTYPE является вырожденной размерностью. Когда я выполняю этот запрос на CDE .. иногда я получаю java.lang.nullpointerexception, поведение очень случайное. Часто он дает результат и для нагрузки по умолчанию, он всегда приводит к положительным результатам. Но для изменения диапазона дат я случайно получаю исключение.

моя структура fact_table имеет 5 нормальных размеров и 3 вырождения.

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

Это что-то делать с вырожденным понятием размерности или высокой эмиссии мощности

+0

это относительно просто 'mdx' так уверены, что ваша проблема является' mdx' – whytheq

+0

дубликат этого: http://stackoverflow.com/questions/29755017/randon-error-processing-on-pentaho- cde-dashboard-for-mdx-query-widget – whytheq

+0

Я думаю, что фактическая проблема лежит где-то в концепции вырожденных размерностей, а не в mdx. Я начал этот новый поток, потому что это была более определенная и определенная проблема, а не такая обобщенная. Вопрос mdx, о котором я упомянул, относится только к справочному –

ответ

0

Может быть, эта мера должна быть более четко:

MEMBER [btype].[b] AS 
    AGGREGATE(IIF('${param}'='All', 
        [btype].[type].members, 
        [btype].[type].[${param}] 
     )) 

Если вы измените его на следующий вы сталкиваетесь ошибку?

MEMBER [btype].[b] AS 
    Sum 
    (
     IIF 
     (
     '${param}' = 'All' 
     ,[btype].[type].MEMBERS 
     ,[btype].[type].[${param}] 
    ) 
    ,[Measures].[qty] 
    ) 
+0

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

+0

.... и используя 'Sum', а не' Aggregate' - они не совпадают: и Aggregate может иногда вести себя довольно удивительно. Пожалуйста, попробуйте заменить «Sum», чтобы проверить, является ли ваша проблема «Агрегатом». – whytheq

+0

Я рассмотрел Sum как рекурсивно добавив [Measures]. [Qty] для каждого члена [btype] .., который может увеличить итерации и ухудшить производительность. и случайным образом выбрасывает исключение. Поэтому я заменил его Aggreagate, который применяет агрегацию по умолчанию для меры на указанных членах impliciltly .. и вместе с тем я также объявил члены вырожденной размерности ([btype]) как уникальные члены в определении куба. эти два изменения значительно уменьшили частоту исключения .. а также я проверил результаты –