none
Mdx Query for Very Large Dimensions RRS feed

  • Pergunta

  • Hi,

    I'm having problems with a some dimensions that are huge, more than 100Millin rows, so the asstore file blows up because of the limitation.
    I've developed a solution to build dimensions and cubes dinamically, but now I have for about 200 cubes and 1000 dimensions. I'm testing but i don't know if the cache will give me a good reply to this arquitecture.
    If it doesn't work i've seen this post  http://www.windows-tech.info/15/c4494062b86c7dd6.php that gave other solution.
    I have two problems: One is that all the queries must be able to responde in less than 4 seconds for the first request and the others in miliseconds. This is possible with a cache warmup(I don't know if with this number of metadata).
    My second problem is that when I try to run this query:

    with

     

    set test as

    LinkMember

     

    (

    [MOLAP_DIM].[DIMID].

    currentmember,

    [ROLAP_DIM].[DIMID]

    )

     

    select

     

    [Measures].[PV]on columns,

    {test}

     

    properties [ROLAP_DIM].[DESC].[DESC] on 1

    from

     

    MyCube

    Gives Me this error:

    [ROLAP_DIM].[DESC].[DESC] dimension attribute was not found

    What am i doing wrong?
    Do you think that the cache will give me a good performance? 



    Thanks.

    quarta-feira, 21 de outubro de 2009 23:11

Todas as Respostas

  • Shif,

    Do you speak portuguese?
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    sexta-feira, 23 de outubro de 2009 00:42
  • Sim. Ok. Desculpa, estou habituado aos foruns em Inglês.

    Não sei se deu para entender o problema.

    Tenho de ter respostas do primeiro pedido a todas as querys em 3 ou 4 segundos.
    Tenho 5 dimensões que são enormes e que podem crescer exponencialmente para vários milhões de registos, e contêm strings muito grandes. O AS tem a limitação de 4gb para o file asstore (se não estou em erro é este o ficheiro), por isso quando corro as dimensões rebentam devido a essa limitação.

    Uma das alternativas que criei e para ter uma melhior performance (em MOLAP) foi dividir essas dimensões em várias e criar vários cubos. Agora tenho esta quantidade enorme de cubos e de dimensões (200 cubos e 1000 dimensões) e com tendência a crescer, sem escalar a arquitectura. Como tenho de ter respostas em 3 ou 4 segundos tenho de fazer um warmup da cache e correr essas querys antes, mas estou com algum receio (ainda estou em fase de testes) que a cache não aguente ou não tenha uma boa performance para este numero de metadata (Para além do problema da sincronização que tenho de fazer, embora apenas crie uma partição por dia para cada cubo e ao fim de dois dias faço o Merge para a partição Mensal).

    Uma das alternativas que vi nos foruns foi em vez de ter este numero enorme de cubos e dimensões ter as dimensões em Rolap, tendo a chave (inteiro) como Molap numa dimensão identica e depois fazer o linkmember para a dimensão Rolap através da chave http://www.windows-tech.info/15/c4494062b86c7dd6.php.
    Outro aspecto que não sei é se vou conseguir ter uma boa performance e como se comporta a cache com as dimensões ROlap, mesmo após o primeiro pedido.

    Tentei correr a query que coloquei anteriormente (Desculpa a formatação não ser a melhor!), mas dá-me erro porque diz que [ROLAP_DIM].[DESC].[DESC] não é uma propriedade dos atributos da dimensão.
    O que eu preciso na query é ter por exemplo todas as descrições da dimensão Rolap , [ROLAP_DIM].[URLDesc].[URLDesc] e os valores da métrica para essas descrições.,mas deve ter o comportamento da dimensão MOLAP.

    Outro dos problemas que é ter este número de metadata é que tenho de criar uma outra base de dados apenas para estes cubos, perdendo a possibilidade de ter em scalable shared database a outra base de dados que tenho.

    Sei que é muita informação ao mesmo tempo :) .

    Obrigado

    sexta-feira, 23 de outubro de 2009 09:32