Thiago Zavaschi R2 www.zavaschi.com

5Jul/120

SQL Server Analysis Services – Query Log 2000 x 2005+

Olá pessoal,

Estando no time de suporte premier da Microsoft recebo muitos chamados de clientes que desejam migrar seu Analysis Services do 2000 para versões mais recentes como o 2008 R2 e 2012.

Uma dúvida comum é sobre as diferenças entre a versão 2000 e as demais.

Hoje falaremos das principais diferenças do query log do SSAS 2000 para os SSAS posteriores.

O SSAS possui capacidade de logar informações sobre as queries que são disparadas contra o servidor (não estou falando do Profiler (traces) e nem do Flight Recorder (que também é um trace)) conhecido como query log.

O SSAS não armazena evetivamente a query executada, porém armazena informações sobre quais atributos e measures foram utilizadas, que mais tarde pode ser utilizada pelo wizard de otimização baseado em uso.

O SSAS 2005 (e os posteriores) não loga as queries na tabela de log de queries por padrão. Para fazer o log você deve explicitamente ativar esse recurso nas propriedades do SSAS.

A partir do SSAS 2005 não é possível utilizar o Access como repositório para o log de queries. Obrigatoriamente você terá de usar uma database do SQL Server para isso.

O SQL Server não precisa residir no mesmo computados que o SSAS.

O Analysis Services não utiliza mais o registro do windows para armazenar suas propriedades. Todas as propriedades do servidor SSAS que controlam o comportamento do query log são acessíveis através do Management Studio ou através da modificação do arquivo de configuração do SSAS.

O formato (campos e tipos de dados) da tabela de log mudou. Se você utiliza para algum outro fim, você precisará ajustar seus scripts personalizados.

Para maiores informações sobre como configurar o query log do SSAS segue o link (em inglês):

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

Obrigado!

12Apr/124

Análise de Performance no Reporting Services (SSRS)

Olá pessoal,

O servidor de relatórios contido na suíte do SQL Server é muito usado e há uma série de características sobre ele que não usamos ou que desconhecemos que existe.

Hoje vou comentar sobre um dos pontos iniciais a se olhar quando são identificados problemas relacionados a performance no SSRS e indicar um direcionamento para a análise.

O primeiro ponto que podemos olhar é o Execution Log que nos provê dados relacionados às execuções de relatórios no servidor.

20Mar/122

Performance no SQL Server Analysis Services (SSAS)

É muito comum existirem dúvidas por parte dos profissionais que trabalham com a plataforma de dados ao saírem do mundo relacional para o mundo multidimensional. Em geral, estas dúvidas giram em torno de “como” fazer, já que é um paradigma “novo”.

Após algum tempo de projeto e execução de testes com carga em produção, ou mesmo com as bases multidimensionais (a.k.a. cubos, lembrando que uma base pode conter mais de um cubo) indo para produção é que surgem outros tipos de dúvidas, principalmente ligadas a desempenho.

Primeiro ponto é que ao “tunarmos” nosso servidor de análise devemos reparar que é dois “tempos” que necessitam de otimização: tempo de processamento do cubo e tempo de resposta da query.

As otimizações necessárias para ambos os casos são bem diferentes. Os pontos de atenção são:

Projeto da estruturação física do cubo: Podemos fazer grandes avanços na otimização de query, mas em geral um bom projeto do cubo segundo as definições do Kimball é o que dará ganhos muitos bons quanto ao desempenho.

Otimização da query (query tuning): A interação (requisão) com o servidor OLAP é feita através de queries MDX (multidimensional expressions), enviadas por ferramentas clientes (reporting services, excel, etc.). O tempo de demora da consulta é o que impacta diretamente o tempo de resposta para o usuário ter acesso à informação. Neste cenário o que podemos utilizar a nosso favor é a reescrita de queries MDX, agregações, cache, entre outros.

Otimização do tempo de processamento: Processar um cubo é a operação de atualização dos dados em uma base do SSAS. Ou seja, o usuário NÃO é impactado no tempo de resposta, mas sim na demora em obter dados atualizados. Aqui há uma série de ações que podem ser tomadas, inclusive tuning no relacional (consulta sobre o data warehouse – fontes de dados).

Bom pessoal, o post hoje era para mostrar os pontos de atenção quando vamos otimizar uma base de dados do SSAS.

Maiores informações podem ser encontradas (em inglês) no guia: SQL Server Analysis Services 2008 R2 Performance Guide, escrito pelo time do SQLCAT.

Grande abraço!