none
ROLAP - Partição em tempo real

    Pergunta

  • Olá Pessoal,

    Preciso de uma partição ROLAP em tempo real, onde os dados inseridos na base OLTP apareçam nas consultas feitas ao cubo sem a necessidade de processamento do cubo.

    Existe como fazer isso sem  utilização do Proactive Cache?

    Se sim como realizo as configurações para que meu cenário fique desta forma?

     

     

    Abraço!

     


    Juliandro Figueiró Analista de Business Intelligence - Accera Supply Chain Solutions
    terça-feira, 13 de dezembro de 2011 18:27

Todas as Respostas

  • Bom Dia,

    É plenamente possível fazer isso, mas não entendo porque alguém iria querer isso. Com a volatilidade do OLTP e a impossibilidade de se criar agregações em Real Time, a performance simplesmente seria sofrível. Você teria que varrer todos os dados necessários para apresentá-los no cubo e isso incorre em longas varreduras, bloqueios em potencial e uma concorrência desgastante. O Proactive Caching é uma forma de minimizar tal efeito e retirá-lo da solução é ter ainda mais problemas nesse cenário. Para fazê-lo, basta colocar o Storage Mode em ROLAP e não criar agregações.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    domingo, 18 de dezembro de 2011 13:41
    Moderador
  • Gustavo,

     

    isso é plenamente aceitável sim; pois, há casos de ambientes que precisam ser monitorados em "real-time" por exemplo varejo, call center, acompanhamento de cadeia de suprimentos, etc onde simplesmente não pode chegar pra pessoa que analisa as métricas e esperar um D-1.

     

    Com 3 servidores ou mais (Prod + Dev + BI e Sync via Log Shipping) é plenamente possível chegar a essa estrutura sim.

     

     

     

    domingo, 18 de dezembro de 2011 17:26
  • Juliandro,

    no caso, acho que o mais pertinente no seu cenário é você trabalhar com processamento incremental via XLMA, mais ou menos da seguinte forma:

    Servidores:

    *Prod (OLTP)

    * Dev

    * BI (OLAP)

     

    1 - Prod (OLTP) Log Shipping p/ Dev;

    2 - Load p/ BI buscando de Dev;

    3 - Processamento Incremental do BI

     

    A arquitetura geral seria essa, mas imaginando no melhor dos mundos, você teria um servidor só de Staging que no caso faria o papel do Dev, mas não é o caso.

     

    Dessa forma você poderia assegurar a parte de Staging & Load, porém você ia ter que trabalhar com partições históricas, e ai sim você através de divisões das partições você trabalharia com Processamento incremental.

     

     

    Abs!

    domingo, 18 de dezembro de 2011 17:33
  • Boa Noite Iniciante,

    Não nego a necessidade de monitoração Real Time (ainda que em um mundo analítico). É algo cada vez mais latente por sinal.

    O que questiono é a forma de se fazer, pois, não creio que plugar o Analysis no OLTP seja a melhor alternativa. A modelagem dimensional utilizada no cubo é diferente da que usamos no mundo OLTP e plugar o cubo para ver "dimensionalmente" o OLTP em Real Time não costuma ser um bom negócio.

    A arquitetura que você propõe é um das possíveis, mas honestamente ela também apresenta um DELAY mínimo, pois, o Log Shipping incorre em um Delay de no mínimo 15 minutos. Se for para ser NEAR REAL TIME de fato, eu optaria por outras estratégias (CDC incremental, mensageria, etc). Há algumas alternativas mais alto nível discutidas sobre o conceito ETL Near RealTime no clássico ETL Toolkit de Ralph Kimball.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 19 de dezembro de 2011 01:29
    Moderador
  • Boa tarde Gustavo,

    Desculpe-me não ter interagido antes.

    Entendo as questões de desempenho e os impactos em potencial, por outro lado a versão do SQL onde publicarei o cubo não possui suporte ao proactive caching e até termos a versão que aceita terei que ter uma ação alternativa para viabilizar esta função.

    Tendo em vista este cenário, já testei com sucesso a implementação do comando XMLA ClearCache, porém, não me agradou muito essa solução a idéia seria desabilitar o cache mesmo e não ficar limpando ele através de gatilhos para UPDATE, INSERT, etc.

    Existe como desabilitar o cache?

     

    obrigado pela atenção,

    Forte abraço!

     

     


    Juliandro Figueiró Analista de Business Intelligence - Accera Supply Chain Solutions
    segunda-feira, 19 de dezembro de 2011 17:28
  • Senhores,

    Por favor me ajudem com esta questão...

    Acrescento que não entendi a arquitetura proposta acima para fazer o "real-time".

     

    Ainda não achei a melhor solução


    Juliandro Figueiró Analista de Business Intelligence - Accera Supply Chain Solutions
    • Editado Juliandro segunda-feira, 23 de janeiro de 2012 10:47
    sábado, 21 de janeiro de 2012 18:36
  • Juliandro,

     

    Aqui, uma thread de opniões pessoais rs...eu estou entre o Gustavo e o Iniciante.

     

    Sinceramente, não creio que a analise em tempo real seja necessarias para 100% do seu BI, por exemplo, prestei serviço para grandes lojas de varejos de roupas, e o BI deles incluia tudo de gastos, desde o tecido comprado, até a mão de obra e a venda do produto em si, contabilizando tambem por exemplo o custo das lojas fisicas.

    O que era necessario ser analisado no BI real time: No maximo do maximo, desempenho de uma loja ou desempenho de um produto.

    Outro exemplo (CallCenter): Desenpenho de um operador, desempenho da campanha e lote (Meu trabalho atual)

    Portanto, em meu real time, não preciso de todas as informações, mesmo por que, a analise e ideia do BI é para tomada de decições a longo prazo, para curto prazo, sempre tivemos nosso famosos relatorios extraidos no Excel (Pessoal do Control Desk), então, temos relatorios padrões, que não se encaixam no BI em si, feitos sobre uma base via log shipping com latencia de 1h, e o BI D-1 sem onerar produção.

     

    Deixo aqui minha opnião tambem sobre todo o conceito: Os dados do BI que voce vai precisa em realtime, dificilmente serão 100% de seu BI, eu não preciso saber em real time o aluguel de uma maquina de um operador, mesmo por que este não é alterado o tempo todo, para os dados que necessitam, ao meu ver, a melhor opção seria um log shipping por exemplo para outro servidor, e um novo cubo, contendo apenas operações diarias.


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    segunda-feira, 23 de janeiro de 2012 10:54
    Moderador
  • Certo Fabrizzio,

    O que vou precisar em "Real-time" no meu BI é somente um pequeno pedaço dele só uma partição que já criei só preciso deixar ela em "real-time".

    Tipo, a necessidade está definida, tenho que fazer! :)...

    O problema é que estou me quebrando no como fazer...

    Já levantei algumas possibilidades que funcionaram bem até mas gostaria de saber se é a melhor forma....

    Fiz testes da seguinte forma:

     

    - Uma JOB que executa um comando XMLA clear cache

    - Uma outra JOB que roda de 2 em dois minutos que excuta uma procedure

    - esta procedure verifica se houve alguma inserção (top 1 por data de inserção < que dois minutos atrás)

    - se houve inserção então executa JOB do clear cache

    - se não houve inserção então faz nada...

     

    O Que você acha desse cenário?

    abraço

     

     

     

     


    Juliandro Figueiró Analista de Business Intelligence - Accera Supply Chain Solutions
    segunda-feira, 23 de janeiro de 2012 11:16
  • Juliandro, bom dia!

     

    Aqui em nosso ambiente utilizamos esse tipo de solução abordada por você, porém nós atualizamos todo o banco em uma rotina que trabalha de acordo com o data version de uma coluna timestamp. Se você não tivesse um alto número de transações isso poderia sim ser aplicado. 

     

    Porém, eu recomendo entretanto que você veja a sua PROC para que não haja perda de desempenho!

     

    Abs !

    segunda-feira, 23 de janeiro de 2012 11:21
  • Juliandro,

     

    A ideia de limpar o cache do SSAS não acho ruim, o problema é que forcara o Analysis a reconstruir, no seu caso, o cubo, a ideia em si é boa de pode ser utilizada, mas não em produção, eu ainda sim colocaria um logshipping e faria neste servidor a busca dos dados, assim voce tera 3 ganhos:

    - Uma solução de alta disponibilidade para aquela base (Caso ja tenha, tera mais uma =) )

    - Não tera uma procedure rodando um job rodando a cada 2 min em seu ambiente de produção

    - Não fara o SSAS ir diretamente em produção, onerando assim a performance do mesmo


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    segunda-feira, 23 de janeiro de 2012 11:23
    Moderador
  • Fabrizzio,

     

    Vou estudar o Logshipping que não conheço, tens alguma referência para me indicar que auxiliará na implementação?

     

    abraço!!!


    Juliandro Figueiró Analista de Business Intelligence - Accera Supply Chain Solutions
    segunda-feira, 23 de janeiro de 2012 11:34
  • Juliandro,

     

    O log shipping é bem simples...Segue:

    http://technet.microsoft.com/en-us/library/cc917705.aspx

    http://www.mssqltips.com/sqlservertip/1158/sql-server-log-shipping/


    Fabrizzio A. Caputo
    MCT
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCITP SQL Server 2008 Developer
    Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    segunda-feira, 23 de janeiro de 2012 11:35
    Moderador
  • Senhores,

    A solução para se ter uma partição em tempo real quando a versão do SQL Server não possui suporte ao Clear Caching é disparar um comando XMLA contra o SSAS para realizar a limpeza do cache, desta forma teremos os dados atualizados sem a necessidade de processar o cubo.

    obs: o StorageMode da partição deve estar definido como ROLAP.

    No cenário que implementamos aqui,a aplicação front-end dispara este comando no momento que é aberto o relatório (cubo), portanto, temos os dados atualizados até o momento da abertura.

    segue abaixo o comando para efetuar  a limpeza do cache e com isso forçar o SSAS a buscar os dados na base OLTP novamente.

    <ClearCache xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
      <Object>
        <DatabaseID>id da base OLAP</DatabaseID>
        <CubeID>id do cubo</CubeID>

       <PartitonID>id da partição</PartitonID>

      </Object>
    </ClearCache>

    espero que isso ajude quem passar pelo mesmo problema que eu :)

    abraço!


    Juliandro Figueiró - Analista de Business Intelligence

    quarta-feira, 4 de abril de 2012 14:27