web-dev-qa-db-fra.com

Le filtrage de MDX Crossjoin sur différentes hiérarchies de la même dimension est très lent

J'ai une requête MDX qui a été écrite par un novice MDX qui est excessivement lente (la requête, qui n'est pas le Novice MDX). Et je suis aussi un novice MDX. Voici la requête:

SELECT
NON EMPTY
(
    [Measures].[Status]
)
ON COLUMNS,
NON EMPTY
(
    Filter
    ( 
        Crossjoin
        (
            {
                [Value1].[Value1].[Value1A],
                [Value1].[Value1].[Value1B]
            },
            [Value2].[Value2A].[Value2A],
            [Value3].[Value3].[Value3].ALLMEMBERS,
            [Value4].[Value4].[Value4].ALLMEMBERS,
            [Value5].[Value5].[Value5],
            [Value2].[Value2B].[Value2C],
            [Value6].[Value6].[Value6],
            [Value7].[Value7A].[Value7A]
        ),
        (
            [Measures].[Status]
        ) > 0
    )
)
ON ROWS
FROM [Cube]
WHERE
(
    [Value7].[Value7].[Value7A],
    [Value8].[Value8].[Value8A],
    [Value9].[Value9].[Value9A]
)
CELL PROPERTIES VALUE

J'ai très peu connaissance de MDX, mais à travers une erreur d'essai et d'erreur, j'ai constaté que l'élimination des deux [Value1].[Value1] Entrées à partir du Crossjoin rend le retour de la requête rapidement. Ou, enlever à la fois le [Value2].[Value2A] et [Value5] Les entrées le rend également rentrant rapidement. Mais, évidemment, cela change la requête, donc n'est pas la solution, mais peut-être qu'il fournit des indices quant à l'endroit où je devrais regarder en termes d'index ou de tels cas s'il y a quelque chose comme celui-ci dans les services d'analyse SQL (je suis plus familier avec Bases de données SQL Server)?

Une chose que j'ai essayée est de mettre & avant [Value1A] et [Value1B]. Cela a amené la requête à revenir très rapidement sans résultat. Malheureusement, je ne sais pas si cela est correct car la requête sans ce changement prend trop de temps pour pouvoir voir s'il y a des résultats. Je ne sais pas quelle différence & est censé faire, mais est-ce la réponse évidente ou change-t-elle la requête pour être différente? Il est également possible que l'auteur original de cette requête ait eu l'aide & De toute façon, mais jamais à tester la requête avec un ensemble de données réel.

Toute aide serait grandement appréciée.

2
Neo

J'ai trouvé une réponse ici Cela a aidé ma situation et la requête revient maintenant très rapidement. Il apparaît que la clause HAVING est une meilleure solution que d'utiliser la fonction Filter tant que le jeu de données est raisonnablement petit. Cependant, j'ai remarqué que l'élimination NON EMPTY du deuxième axe (ON ROWS) Le fait que cela soit toujours lent, même en utilisant la clause HAVING. Je suis peut-être toujours nécessaire de résoudre ce problème aussi. Mais au moins le premier problème est résolu.

0
Neo

Essaye ça:

SELECT
    [Measures].[Status]
ON COLUMNS,
NONEMPTY
({
                [RiskType].[RiskType].[MemberValue123],
                [RiskType].[RiskType].[MemberValue456]
            }*
            [Trade].[TradeType].[TradeType]*
            [Expiry].[Expiry].[Expiry].ALLMEMBERS*
            [Tenor].[Tenor].[Tenor].ALLMEMBERS*
            [YieldCurveCurrency].[YieldCurveCurrency].[YieldCurveCurrency]*
            [Trade].[TradeBook].[XYZ1]*
            [Index].[Index].[Index]*
            [EffectiveStrike].[Effective Strike Name].[Effective Strike Name]
,
            [Measures].[Status]
)
ON ROWS
FROM [RePro]
WHERE
(
    [RiskSet].[RiskSet].[ABC],
    [Portfolio].[Portfolio].[XYZ],
    [RunDate].[RunDate].[17 Sep 2013]
)
0
user31779