Thiago Zavaschi R2 www.zavaschi.com

10May/131

Analysis Services Internals – Formula e Storage Engines (e como funciona o cache?)

Olá pessoal!

O tópico de hoje é para servir de base a todos que desejam conhecer um pouco mais de como o servidor do Analysis Services (SSAS) trabalha por trás dos panos.

Existem diversos mecanismos internos que são responsáveis / interagem no processamento de uma query que é enviada ao servidor de análise (o processo detalhado de execução de uma query vou abordar em um tópico futuro específico): XMLA Listener, Formula Engine, Storage Engine e assim por diante.

Esse post abordará sobre o que é e para que servem a Formula e a Storage Engine.

27Jul/122

SSIS Package Configuration (XML File) – Trocando a Connection String entre Servidores

Olá!

Uma dúvida comum que sempre surge quando vou atender um caso de SQL Server Integration Services (SSIS) é:

Ok Thiago desenvolvi 100 (leia-se muitos) pacotes no SSIS, porém toda a vez que vou fazer o deploy destes pacotes em homologação e produção eu tenho que ficar mudando as connection strings. Como proceder?”

O SSIS tem um mecanismo para ajudar neste sentido chamado SSIS Package Configuration, onde é possível salvar a suas configurações em um arquivo XML, variável de ambiente ou até mesmo em uma tabela do SQL Server que contenha os valores.

No artigo de hoje vou abordar apenas a configuração através de arquivo XML.

Mas então, como fazer?

Desenvolva seu pacote normalmente. Utilizando os Data Sources de desenvolvimento e associando os respectivos Connection Managers a eles da forma que for necessária ao seu fluxo.

Agora o que precisamos fazer é criar um arquivo de configuração XML que conterá os dados que os data sources utilizarão ao invés do que você configurou previamente.

Esta configuração você fará para o primeiro pacote e depois reutilizará o mesmo arquivo de configuração para os demais pacotes.

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!

24Apr/125

Gestão de Memória no Reporting Services

Olá pessoal :)

Uma dúvida muito comum que recebo é: posso por o meu servidor de relatórios (Reporting Services) no mesmo servidor de base de dados (database engine). A resposta é: claro que pode…. tecnicamente, mas dependendo da demanda, não é uma boa estratégia quando o objetivo é performance.

O foco aqui será a questão da gestão da memória RAM, mas o fato de usar o mesmo servidor também tem impacto na parte de processamento (vamos deixar isso para um post futuro abordando arquitetura :) ).

É fato que a engine relacional do SQL Server utiliza toda a memória disponível para ele, seja com cache de dados, planos e etc. A questão é que o Reporting Services também tenta fazer isso. E a velha máxima persiste: dois corpos não podem ocupar o mesmo local no espaço ao mesmo tempo.

Ok.. ok… traduzindo: a mesma porção de memória não pode ser ocupada por dois processos ao mesmo tempo.

19Apr/122

SQL Server Reporting Services – Trace Log e HTTP Log

Olá!

Assim como a engine do SQL Server e muitos outros produtos (Microsoft ou não), estes possuem um log de trace sobre o que acontece com o aplicativo/serviço, não acontece diferente no Reporting Services.

Os arquivos de trace log do Reporting Services variam de acordo com a versão do SQL Server. Até o SQL Server 2005 (onde ainda tinhamos dependência do IIS para o SSRS) haviam 4 tipos de arquivos de log que por padrão são limitados a 32MB por arquivo e são automaticamente deletados após 14 dias. Estes arquivos são texto plano, então qualquer editor de texto consegue abrir.

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.

4Apr/120

Alterando o local de armazenamento dos snapshots do Reporting Services (SSRS)

Olá pessoal!

O Reporting Services (SSRS) possui diversos recursos associados a gestão, entrega e administração dos relatórios criados nele, não é apenas uma engine para renderização dos mesmos.

Um recurso que é muito interessante no SSRS é a capacidade de armazenar snapshots de relatórios para posterior consulta de uma informação baseada em dados de um tempo passado (“frozen in time data”).

Por padrão os snapshots ficam armazenados em uma base de dados do SSRS. O Reporting Services possui duas databases cujos nomes e principais funções são:

  • ReportServer: Responsável por armazenar partes da configuração do SSRS (outras partes são armazenadas em arquivos de configuração), metadados e definições de relatórios, configurações de segurança, dados de agendamento e entrega de relatórios, etc. É nesta database que se os snapshots são armazenados por padrão.
  • ReportServerTempDB: Base de dados utilizada para armazenamento do cache, processamento intermediário, etc. A perda dos dados desta database não deve afetar o funcionamento normal do SSRS. O que pode impactar os usuários é: lentidão até ter um novo cache armazenado (se configurado), e um erro dizendo que a conexão se perdeu (rsExecutionNotFound). Algo importante de lembrar é que o SSRS não faz a reconstrução desta base de dados. Então pode ser interessante ter um script para reconstrução da mesma à mão. :)

Muitas das vezes, vulgo 100%, não deseja-se perder estas informações. Uma alternativa para quem quer armazenar estas informações de snapshot em outro local é armazená-los no file system (observação: foi utilizado o SSRS do 2008 no exemplo).

Para isso são necessários dois passos:

1) No arquivo de configuração RSReportServer.config coloque como “True” os parâmetros: WebServiceUseFileShareStorage e WindowsServiceUseFileShareStorage.

2) Configure o parâmetro FileShareStorageLocation para um caminho completo, exemplo: “C:\SSRSSnapshots”. O caminho padrão é: “C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\RSTempFiles”.

É isso. :)

[]s!

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!

31May/113

SQL Server e SQL Azure – Licenciamento + Billing

Então pessoal, como estão?

Sei que estou postando fortemente sobre Business Intelligence, mas hoje gostaria de iniciar algo diferente.

Se eu fosse elencar as dúvidas que recebo mais frequentemente dos clientes e parceiros, com certeza seria licenciamento em primeiro lugar.

A plataforma de dados da Microsoft é o SQL Server e o seu braço na nuvem é o SQL Azure. Por isso vou dividir esse conjunto de posts da seguinte forma (vou adicionar os links a esse post conforme os posts seguintes saírem), mas não necessariamente nesta mesma ordem.

  • SQL Server, Analysis Services, Integration Services, preciso de uma licença para cada um?
  • SQL Server com Cluster, Mirror e Log Shipping, o que preciso licenciar?
  • SQL Server virtualizado e ambientes híbridos: Virtualizado + não-virtualizado.
  • SQL Azure – Espaço, transferência? Como funciona e quanto custa?

A ideia dos posts é não é entrar na precificação (com excessão do SQL Azure), pois há várias modalidades contratuais e esses aspectos de contratos e programas de relacionamento com a Microsoft eu não irei abordar.

Gostaria de um feedback de vocês que leem o blog (nos comentários) sobre esta sequência de posts. Isso é muito importante! Aceito sugestões!!

Abraços,
Thiago Zavaschi

20Jan/113

Permissão para ver a estrutura, mas sem os dados!

Recentemente o Carlos Barini (http://twitter.com/cabarini) me perguntou se era possível liberar para um user ver a estrutura de uma tabela, mas não ter a permissão de leitura na tabela.

É possível sim, claro que a configuração do permissionamento pode ser adaptado para cada caso. No exemplo aqui vou concentrar nesse caso perguntado.

Vamos criar um login e um user na database “demo”.

USE [master]
GO
CREATE LOGIN [usuario] WITH PASSWORD=N'123', DEFAULT_DATABASE=[demo], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE [demo]
GO
CREATE USER [usuario] FOR LOGIN [usuario]
GO

Vamos usar a mesma tabela de empregados que usamos no artigo anterior.

O usuário “usuario” tem permissão de select na tabela. O que podemos fazer é simplesmente:

1) Remover a permissão de select no objeto.

2) GRANT na permissão de VIEW DEFINITION:

DENY SELECT ON [dbo].[Empregado] TO [usuario]

GRANT VIEW DEFINITION ON [dbo].[Empregado] TO [usuario]

E teremos ao executar o select:

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object 'Empregado', database 'demo', schema 'dbo'.

Mas ao tentar ver a estrutura:

image

Espero que te ajude Carlos!

Grande abraço,
Thiago Zavaschi